performance.measure：深入解析，它并非“一键测速”的万能工具
首先，必须明确一个核心要点：performance.measure 并非一个能够自动完成所有性能测量的“黑盒”工具。它的本质是一个“时间差计算器”，其功能是精确计算出两个已定义标记点之间的时长。它本身并不主动采集任何原始性能数据。这意味着，你必须先使用 performance.mark 方法准确地设置起始点和结束点，然后才能调用 measure 来“套用”并计算出这个时间区间。如果缺少了前置的标记步骤，后续通过 performance.getEntriesByName 方法进行查询时，只会得到一个空的数组，无法获取任何测量结果。
为什么调用 performance.measure 总是返回空数组？
这是开发者在使用 Performance API 时最常遇到的问题之一，其根本原因通常在于标记（mark）步骤的遗漏、顺序错误或名称不匹配。浏览器不会自动为你创建性能标记，也不会在字符串匹配上提供任何模糊容错。
- 执行顺序是硬性要求：必须严格按照顺序先调用
performance.mark('start')，再调用performance.mark('end')，这个前后次序绝对不能颠倒。 - 名称必须精确匹配：传递给
performance.measure('my-load', 'start', 'end')方法的三个字符串参数必须完全一致，包括大小写、拼写以及任何可能存在的空格。 - 警惕异步代码的陷阱：如果在异步回调函数（例如
fetch请求的.then或async/await中）进行标记，务必确保回调函数确实被执行了，避免标记调用被未处理的 Promise 错误或异常逻辑所“吞没”。 - 开发者工具需要配置：Chrome DevTools 的 Performance 性能面板默认不会显示用户自定义的 measure 条目。你需要手动勾选面板中的 “User Timing” 轨道，才能可视化地看到你创建的测量区间。
performance.measure 与 performance.now() 应该如何选择？
选择哪种方法取决于你的具体使用场景。直接使用 performance.now() 更为轻量级和灵活，适合进行快速的、一次性的性能调试。而 performance.measure 的真正优势在于其“可被工具化和集成”——它生成的性能条目能够被专业的性能监控工具统一收集、分类和进行深度分析，这在接入 Lighthouse 自动化测试或构建 RUM（真实用户监控）系统时具有不可替代的价值。
performance.now()：适用于简单调试和快速验证。典型用法是：const t0 = performance.now(); doWork(); console.log(performance.now() - t0);。performance.measure()：适用于体系化的性能埋点和监控。例如，现代前端框架可以在每个组件的生命周期（如挂载前和挂载后）自动打标，然后统一上报所有名称符合特定模式（如/^mount-/）的 measure 条目，用于分析整体或单个组件的渲染性能。- 注意重复调用问题：
measure方法不会覆盖同名的已有性能条目。多次调用相同名称的measure会生成多个独立的 PerformanceEntry 对象。因此，在获取数据时，务必使用performance.getEntriesByName('your-measure-name')来获取全部结果集并进行统计分析，而不是想当然地只取返回数组的第一个元素[0]。
如何让 performance.measure 在生产环境中发挥真正价值？
仅仅在代码中完成打点和测量是远远不够的。如果没有后续的数据处理、上报和分析链路，这些辛苦收集的性能数据只会静静地停留在浏览器的性能缓冲区中，最终随着页面关闭而被垃圾回收机制清除。要让它们产生实际的业务价值，需要一套完整的“组合拳”策略。
立即学习“前端免费学习笔记（深入）”；
- 调整性能缓冲区大小：使用
performance.setResourceTimingBufferSize(500)来扩大资源计时条目的缓冲区容量，防止因默认限制（通常为150条）而导致的重要数据被过早丢弃。 - 监听缓冲区满事件：为
performance.onresourcetimingbufferfull事件添加监听器。一旦该事件触发，应立即通过performance.getEntriesByType('resource')取出缓冲区中的所有资源计时数据，并尽快上报到你的监控服务器。 - 建立规范的命名空间：对于自定义的 measure 测量点，强烈建议使用具有明确语义的命名空间前缀，例如
'app:component:mount'或'feature:search:debounce'。这样可以有效避免与项目中引入的第三方库所产生的标记发生命名冲突。 - 关注性能开销与节制：切忌在
scroll（滚动）、mousemove（鼠标移动）这类高频触发的事件回调函数中无节制地创建标记。performance.mark操作本身也有微小的性能开销，滥用可能导致内存不必要的增长，甚至反过来影响页面性能。
归根结底，技术层面的 API 调用并不复杂。真正的挑战在于前期的设计与决策：应该在应用程序的哪些关键业务路径和性能瓶颈处打标？打多少标记是合适的？收集上来的海量性能数据如何进行清洗、聚合和可视化分析？一个设计糟糕、语义模糊的 measure 名称，其带来的误导性和分析成本，可能比完全没有监控数据还要糟糕。
