performance.mark() 不能直接用重复字符串名打点，因为同名标记会覆盖而非追加；应使用语义化+时间戳/随机后缀的唯一命名，如'cart-submit-begin'；performance.measure()需显式传入起止mark名，任一缺失则静默失败；建议用traceId透传、try/finally确保end标记执行，并在关键路径结束后用clearMarks()按前缀清理，避免内存泄漏。
performance.mark() 为什么不能直接用字符串名打点？
因为 performance.mark() 要求标记名是合法的 DOMString，但更关键的是：**重复调用同一名字会覆盖前一次记录**，不是追加。如果你在用户点击按钮、请求发出、数据渲染三个阶段都写 performance.mark('load')，最后只能拿到最后一次的时间戳，中间过程全丢了。
实操建议：
- 用语义化+时间戳/随机后缀组合命名，比如
'click-start-1744631354823'或'api-fetch-init-uuid4' - 业务关键路径上每个 mark 应有唯一上下文含义，例如
'cart-submit-begin'、'cart-submit-api-resolved'、'cart-submit-dom-updated' - 避免空格、特殊符号（如
@、/），否则后续performance.measure()可能抛SyntaxError
如何用 performance.measure() 关联两个 mark 并提取耗时？
performance.measure() 不是自动计算差值，它依赖你显式传入起止 mark 名 —— 如果其中任一 mark 未被记录，measure 就不会生成条目，也不会报错，容易静默失效。
常见错误现象：
- 调用
performance.measure('api-latency', 'api-start', 'api-end')，但'api-end'标记因异常没执行，结果performance.getEntriesByType('measure')查不到该条目 - mark 名大小写不一致，比如写了
'Api-Start'却用'api-start'去 measure - 在异步回调里打点，但没确保 mark 已注册（例如 Promise reject 后漏打
'api-end'）
安全做法：
- 在关键路径入口统一生成唯一 ID，透传到各阶段，用于构造 mark 名，例如：
const traceId = Date.now().toString(36) + Math.random().toString(36).substr(2, 5) - 用
try/finally包裹异步逻辑，确保endmark 必然执行 - measure 后立刻检查：
const m = performance.getEntriesByName('api-latency'); if (!m.length) console.warn('Missing measure: api-latency');
如何批量导出关键路径的 measure 数据并生成可读报告？
浏览器不会自动聚合或格式化 performance.getEntriesByType('measure') 的结果。你拿到的是原始 PerformanceMeasure 对象数组，duration 字段单位是毫秒，但精度为微秒级（小数点后三位），直接 console.log() 显示不够直观。
输出建议：
- 过滤出你关心的 measure 名，例如：
performance.getEntriesByType('measure').filter(m => /^cart-.*/.test(m.name)) - 按
startTime排序，还原执行时序；用Math.round(m.duration * 100) / 100保留两位小数 - 拼接成表格字符串或对象结构，方便上报或打印：
const report = measures.map(m => ({
name: m.name,
duration: Math.round(m.duration * 100) / 100,
startTime: m.startTime.toFixed(1),
entryType: m.entryType
}));注意：performance.getEntriesByType('measure') 返回的是快照，不会包含之后新增的 measure，所以应在关键路径全部结束（如页面加载完成、用户操作流收尾）后再调用。
长期运行的 SPA 中，mark 和 measure 会内存泄漏吗？
会。所有通过 performance.mark() 和 performance.measure() 创建的条目都会保留在 PerformanceEntryBuffer 中，除非主动清理或页面卸载。在单页应用中反复进入同一页面、打大量临时 mark，可能让 buffer 持续增长，尤其在低内存设备上影响明显。
必须做的清理动作：
- 每次业务流结束后，用
performance.clearMarks(traceIdPrefix)清除本次路径相关 mark（支持传入字符串前缀） - 对应清除 measure：
performance.clearMeasures('cart-submit-latency')或批量清空：performance.clearMeasures() - 不要依赖页面刷新自动释放 —— SPA 中刷新不等于重载，history.pushState 后旧 mark 仍存在
最容易被忽略的一点：**mark 名设计必须可预测、可批量清理**。如果用随机 UUID 打点却不保存，就无法精准清除，最后只能用 performance.clearMarks() 全局清空，连带删掉其他模块的监控数据。
