performance.mark() 创建的标记需满足名称准确、已执行且未被清除等条件才能被 getEntriesByName() 获取，否则返回空数组；常见问题包括执行顺序错误、名称拼写不一致、构建工具误删、异步时序不当及 IE11 兼容性限制。
performance.mark() 为什么不能直接用 performance.getEntriesByName() 拿到结果
因为 performance.mark() 创建的标记默认不会自动出现在 getEntriesByName() 返回列表里——除非你调用时传了合法的、未被清除的名称，且该标记确实已执行。常见错误是：脚本执行顺序不对、标记名拼写不一致、或在标记前就调用了 getEntriesByName()。
更隐蔽的问题是：某些构建工具（如 Webpack + Terser）可能把 performance.mark() 当作无副作用语句给删掉了，尤其在生产环境启用压缩后。建议加个空操作兜底，比如：performance.mark('xxx'); void 0;。
- 确保标记名是字符串字面量，不要用变量拼接（否则压缩后可能被混淆）
- 避免在异步回调里打点后立刻读取，比如
setTimeout(() => { performance.mark('a'); }, 0); console.log(performance.getEntriesByName('a'));—— 这很可能返回空数组 - IE11 支持
performance.mark()，但不支持performance.clearMarks()，若需兼容，得自己维护标记名白名单
如何用 performance.mark() 测首屏时间（不是 FP/FCP）
首屏时间不是浏览器原生指标，得靠业务逻辑定义。典型做法是在首屏关键 DOM 节点插入后、或首屏图片 onload 后打点，而不是依赖 'first paint' 这类只读条目（它不可写，也不能用 mark() 覆盖）。
注意：必须在打点前调用 performance.clearMarks('first-screen')，否则多次触发（比如 SPA 路由切换）会累积多个同名标记，getEntriesByName() 返回的是数组，取 [0] 就可能拿到旧值。
立即学习“前端免费学习笔记（深入）”；
- 推荐在
DOMContentLoaded后检查首屏元素是否已挂载，再打点：if (document.querySelector('.first-screen-section')) performance.mark('first-screen'); - 如果首屏含懒加载图片，绑定
img.onload时要防重复，可用img.dataset.marked = '1'做标记 -
startTime是相对于navigationStart的毫秒数，别直接当绝对时间用
performance.measure() 和手动算差值有啥区别
本质没区别，都是算两个时间戳之差，但 measure() 会把结果存进 PerformanceEntryList，后续能统一用 getEntriesByType('measure') 拿到所有自定义测量项，方便批量上报或调试；而手动减法只是 JS 变量，一刷页面就丢。
另一个关键是精度：performance.mark() 和 measure() 都基于高精度时间戳（DOMHighResTimeStamp），比 Date.now() 精确得多，且不受系统时钟跳变影响。
- 必须保证 start 和 end 标记都存在，否则
measure()不报错但返回空 entry - 名称区分大小写：
performance.mark('RenderStart')和performance.measure('render', 'renderstart', 'RenderEnd')会失败 - Chrome DevTools 的 Performance 面板里，这些 measure 会显示为 User Timing 条目，带颜色和标签，比 console.log 更直观
标记太多会不会拖慢页面性能
单次 performance.mark() 开销极低（纳秒级），但大量标记（比如每帧都打一个）会导致 performance.getEntries() 返回超大数组，遍历时 GC 压力上升，尤其低端 Android 设备上可能卡顿。
真实项目中建议按需开启：开发环境全开，预发环境保留核心标记（如首屏、接口响应），线上环境只留 2~3 个最关键的（比如 'app-init', 'first-screen', 'pv-end'），并配合采样率控制（如 1% 用户上报）。
- 不要在 for 循环里无条件打点，至少加个计数器限频
-
performance.clearMarks()和clearMeasures()本身也有开销，别每打一个点就清一次 - 注意 Safari 对 User Timing 条目总数有限制（约 150 个），超出后新标记会被丢弃，不报错也不警告
