分析并优化构建产物

本阶段目标

先建立基线，再用证据选择优化手段。产物体积只是线索，最终要观察用户实际加载了哪些资源、何时加载以及是否阻塞关键交互。

建立基线

记录以下数据：

• 每个入口和异步 Chunk 的原始、gzip 与 Brotli 体积
• 首次访问列表页实际下载的 JavaScript 和 CSS
• 最大依赖、重复模块和未使用代码
• 冷构建、热构建与缓存命中后的耗时

把报告作为 CI 制品保存，并为主入口建立合理的体积预算。预算应来自真实基线和用户目标，而不是复制别人的固定数字。

执行一次有因果关系的优化

为编辑面板引入一个明显较大的依赖，然后依次比较：

1. 直接进入主包
2. 随编辑面板动态导入
3. 在用户即将打开时预取
4. 替换为更小实现或平台原生能力

每次只改变一个主要变量，记录产物图、网络瀑布和交互结果。不要为了让主包变小而制造大量细碎 Chunk；请求调度、缓存失效和运行时开销同样需要计算。

缓存验证

修改一个业务模块后重新构建，检查：

• 入口 HTML 是否使用短缓存或重新验证
• 带内容哈希资源是否适合长期不可变缓存
• 未变化依赖的文件名是否保持稳定
• Source Map 是否与发布版本一一对应

故障演练

1. 错误声明 sideEffects: false，观察必要样式或初始化逻辑是否被删除。
2. 把所有依赖拆成独立 Chunk，比较请求数量和缓存收益。
3. 只比较未压缩体积，再加入真实传输体积，观察结论是否变化。

验收标准

• 优化前后都有可重复的产物与网络基线
• 能解释最大三个 Chunk 的来源和加载时机
• 至少完成一次基于动态边界的优化，并验证错误与加载状态
• CI 能发现明显超过预算的回退
• 优化没有破坏功能、缓存或 Source Map 还原

下一篇：建立性能监控与异常监控。