05｜开发工具与构建链

第九章 / 05。目标：根据症状选择证据面板，而不是在所有问题上只看组件树。

四个观察面回答不同问题

工具	能回答	不能单独证明
Vue DevTools	组件层级、props/state、事件、哪些组件更新	网络和浏览器布局成本
Network	请求排队、缓存、状态、资源体积与时序	响应后的 JS 为什么慢
Performance	事件、长任务、脚本、样式、布局、绘制	业务状态为何错误
Sources/source map	生产 stack 对应源码位置	原始 map 是否安全发布

开发环境可开启 Vue 性能标记：

const app = createApp(App)
if (import.meta.env.DEV) app.config.performance = true
app.mount('#app')

先在 Vue profiler 找到频繁更新组件，再到浏览器 Performance 看这些更新是否真的占主要时间。组件 render 很短而布局很长时，继续加 memo 方向就错了。

一次实际对照：给筛选按钮 handler 临时加一段同步计算并记录 start/end mark，录制 Performance 后移除这段计算再录一次。若脚本段消失而页面仍迟到，继续看请求/布局；若只有开发构建有差异，则不能直接写生产收益。Vue profiler 中某组件“更新很多次”只是线索，需要把那几次更新放回同一用户动作的时间线。

可重放诊断记录

一次记录必须写清：

构建：commit/release id，development 或 production
环境：浏览器版本、视口、CPU/网络限制
初始状态：路由、账号权限、数据种子、缓存冷热
动作：逐步输入/点击，不写“随便操作一下”
证据：请求 id、时间线时间段、组件名、stack/source map
结论：哪一层占主导；下一次只改变哪个条件

生产问题要在生产构建预览复现。HMR、开发警告和未压缩代码会改变时间线；反过来，生产压缩后的函数名没有与 release 对应的 source map，就很难定位。

source map 的发布边界

Vite 可生成 hidden source map，使产物不写公开映射注释，同时把 map 上传到受控错误平台。是否仍能从静态服务器猜到 .map URL 取决于部署规则；发布后要实际请求验证不可公开访问。map 必须与 release id 精确对应，旧 map 不能解新 bundle。

练习：从慢点击定位责任层

给定“点击筛选后 600ms 才显示”现象，设计一份重放脚本和证据表，分别判断：API 500ms、组件 render 500ms、布局 500ms 三种假设。每种写出需要查看的信号、一个能证伪它的结果和下一步；禁止先提出具体优化。

参考答案：第 9 章第 05 题。