综合练习

把 cpf-intro 到 cpf-perf 串起来：为 CodeRoadMap platform（或自选 Web 产品）写一份跨平台选型报告，并落地一个 最小 PWA 可安装原型。目标不是堆技术，而是 证据驱动的决策。

学习目标

• 独立完成「Web / PWA / 桌面 / 移动」四维评估
• 交付可审计的 Manifest + SW 草稿或 Lighthouse PWA 截图
• 交叉引用 html-css-essentials、react-essentials、frontend-toolchain-essentials、http-protocol-essentials

任务说明（二选一）

A. 选型报告（推荐全栈 / 产品向）

针对 platform 的 /tracks 浏览场景（或你熟悉的站点），提交 1–2 页 Markdown：

1. 用户与场景：离线要不要、要不要商店、要不要系统 API
2. 方案对比表：纯 Web、PWA、Electron/Tauri、Ionic/Flutter 各一行优缺点
3. 推荐路径 + 理由（三条以内，可引用 cpf-electron / cpf-tauri）
4. 风险：iOS PWA 限制、包体积、安全（Electron preload）
5. 度量：计划用哪些 Lighthouse 类别 / DevTools 面板验收（cpf-perf）

B. 最小 PWA 原型（推荐前端动手）

在现有 Vite + react-essentials demo 或静态页上：

• 添加 manifest.json（name、icons 192/512、standalone、theme_color）
• 注册 Service Worker：至少缓存 shell + 一条 http-protocol-essentials 风格的 GET 静态资源
• Offline 时显示 fallback 页或提示
• 跑 Lighthouse PWA 类别，截图或粘贴失败项与修复记录

可选：用 ft-vite 的 public/ 放 manifest；用 Workbox 代替手写 SW 须说明策略。

必走流程

1. git checkout -b practice/cpf-你的名字
2. 读 outline + 本 track intro，定 A 或 B
3. 若 B：先 mobile 布局自检（html-css responsive）
4. 实现 / 撰写 → DevTools Application + Lighthouse
5. 报告里链接 http-caching 与 SW 策略对应关系
6. git commit（message 清晰，如 content(cpf): practice pwa prototype）

禁止：未 HTTPS 环境宣称「生产 PWA 完成」；Electron 原型若做，必须 contextIsolation: true。

自检清单

• 我能解释 为何没选 Flutter/Ionic（或为何选）
• Manifest 与 SW scope 一致，icons 可被 DevTools 解析
• 说清 HTTP 缓存 与 Cache Storage 各缓存了啥
• 移动 viewport 与触控区域检查过（css-responsive）
• 若用 React，build 后 SW 仍能命中带 hash 资源

反思题（写进报告或 PR）

1. PWA 相对纯 Web，你为 platform 多做了哪些工作？用户感知价值是什么？
2. 若下一季要做桌面客户端，你会先 PoC Electron 还是 Tauri？一条理由。
3. Lighthouse PWA 满分是否等于「可以替代原生 App」？

与路线图

完成后回到 /roadmaps/frontend，勾选 pwas、service-workers、electron、mobile-apps、lighthouse 等相关节点。继续深化 UI 走 react-essentials 与 nextjs-essentials；深化网络走 http-protocol-essentials。

小结

跨平台不是堆壳，是场景、约束与度量的组合——PWA 往往是 Web 团队成本最低的第一步。 本 track 完结；选型报告与可安装原型是你带走的两份交付物。