根本原因是标记未真正注册成功；需满足名称合法、调用已执行且未被clearMarks清除，常见问题包括构建工具误删、变量拼接命名、异步时序错乱及IE11兼容性限制。
performance.mark() 为什么打完点却 getEntriesByName 拿不到？
根本原因不是 API 失效，而是标记没真正“注册成功”。performance.mark() 调用后，标记只有在满足三个条件时才会出现在 performance.getEntriesByName() 结果里：名称是合法字符串、调用已执行（非被压缩移除）、且未被 performance.clearMarks() 清掉。
常见失效场景：
- 构建工具（如 Terser）把
performance.mark('xxx')当作无副作用语句删了——加void 0兜底：performance.mark('xxx'); void 0; - 用变量拼接名：
performance.mark(prefix + '-start')，压缩后可能变成performance.mark('a' + '-start')，导致名称不一致 - 异步逻辑中先读再打：
setTimeout(() => { performance.mark('a'); }, 0); console.log(performance.getEntriesByName('a'));—— 极大概率返回空数组 - IE11 虽支持
mark()，但不支持clearMarks()，若你手动清理失败，旧标记会残留干扰新数据
如何安全配对 performance.mark 和 performance.measure？
performance.measure() 不是自动计算工具，它只做一件事：查两个已存在的 mark 名，取它们的 startTime 相减，生成一条 PerformanceMeasure 条目。任一 mark 缺失，measure 就静默失败，不报错也不留记录。
确保配对可靠的实操要点：
立即学习“前端免费学习笔记（深入）”；
- 必须显式检查起点是否存在：
if (performance.getEntriesByName('api-start').length) { performance.mark('api-end'); performance.measure('api-latency', 'api-start', 'api-end'); } - 名称严格区分大小写和空格：
'Api-Start'和'api-start'是两个不同标记，measure()不会模糊匹配 - 避免重复名覆盖：多次
performance.mark('load')只保留最后一次，建议加唯一后缀，如`load-${Date.now()}`或`load-${Math.random().toString(36).substr(2, 6)}` - 别用
performance.timing里的字段（如navigationStart）直接传给measure()—— 它只认字符串名，不接受数值时间戳
为什么不能只用 console.time 替代 performance.mark？
console.time() 是调试辅助，performance.mark() 是标准性能基线。两者根本不在一个层级上。
关键差异：
-
console.time('x')的计时上下文不稳定：Promise 链中断、跨 iframe、React 异步更新后都可能丢失或错位 - DevTools Timeline、Lighthouse、RUM SDK 等工具原生识别
performance.getEntriesByType('mark')，但完全忽略console.time记录 -
performance.mark()的时间戳统一基于navigationStart，能和FP、FCP、DOMContentLoad等原生指标对齐分析；console.time是相对当前 JS 执行时刻的任意偏移 -
console.time数据无法结构化导出，也不能通过PerformanceObserver自动捕获上报
上报 measure 数据时最容易漏掉的三件事
很多团队实现了打点和 measure，但监控后台收不到数据，问题往往卡在上报环节。
必须确认以下三点都到位：
-
PerformanceObserver必须显式配置{ entryTypes: ['measure'] }—— 缺少这个选项，回调永远不会触发，这是最常被跳过的配置 - 上报不能依赖
window.onunload：页面快速跳转或崩溃时，日志直接丢失；应在measure创建后立刻提取并用navigator.sendBeacon()发送 - 高频打点必须节流：滚动、输入等场景下 measure 可能一秒几十条，直接发请求会阻塞主线程甚至被浏览器限流；应聚合为批次（如 500ms 内最多发一次），或使用
requestIdleCallback异步发送
真正难的不是打点动作本身，而是让每个 mark 都对应可复现的用户行为切片，并确保从打点、测量到上报整条链路没有时序断点或命名歧义。一旦某个环节用了变量拼接名、或忘了清旧标记、或 observer 没配 entryTypes，整套监控就变成盲区。
