performance.measure 不是万能性能测量工具，它仅计算两个 performance.mark 标记点间的时间差，需先 mark 后 measure，名称严格匹配且顺序正确，否则 getentriesbyname 查不到；适合埋点体系而非单次调试。
performance.measure 不是“测性能”的万能按钮，它只记录两个已标记时间点之间的差值，本身不采集任何真实耗时数据。你得先用 performance.mark 打点，再用 measure 套出区间——漏掉任一环节，getEntriesByName 就查不到结果。
为什么 performance.measure 总返回空数组？
最常见原因是没提前打标，或标记名拼错、大小写不一致。浏览器不会自动为你创建 mark，也不会宽容匹配。
- 必须先调用
performance.mark('start')和performance.mark('end')，顺序不能反 - 传给
performance.measure('my-load', 'start', 'end')的三个字符串必须完全一致（包括空格） - 若在异步回调里打标（比如
fetch的.then），要确认回调执行时mark确实被调用了，别被 Promise 链吞掉 - Chrome DevTools 的 Performance 面板默认不显示自定义 measure 条目，需手动勾选 “User Timing” 轨道
performance.measure 和 performance.now() 该选哪个？
直接用 performance.now() 更轻量、更可控，适合简单逻辑；measure 的价值在于可被工具统一收集和归类，尤其配合 Lighthouse 或 RUM（真实用户监控）系统时。
-
performance.now()：适合单次调试，比如const t0 = performance.now(); doWork(); console.log(performance.now() - t0) -
performance.measure()：适合埋点体系，例如框架在组件挂载前后自动打标，再统一上报所有measure名称匹配/mount-/的条目 - 注意：
measure不会覆盖同名已有条目，多次调用会生成多个 Entry，要用getEntriesByName拿全部，别只取[0]
如何让 performance.measure 在生产环境真正有用？
光打点没用，得有后续处理链路。否则数据就躺在内存里，直到页面卸载才被 GC 清掉。
- 用
performance.setResourceTimingBufferSize(500)防止资源条目被截断（默认仅 150 条） - 监听
performance.onresourcetimingbufferfull事件，触发时立即用performance.getEntriesByType('resource')取数并上报 - 对自定义 measure，建议加命名空间前缀，如
'ui:search-input:debounce'，避免和第三方库冲突 - 不要在高频回调（如
scroll、mousemove）里无节制打标，mark本身有开销，可能引发内存增长
真正难的不是调用 measure，而是决定在哪儿打标、打多少、怎么清洗和聚合。一个没设计好语义的 measure 名称，比不打点还误导人。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
