performance.mark 的核心是插入语义明确、可复用、可测量的时间锚点，用于量化业务耗时与定位体验瓶颈；需规范命名（如'user-login-start'）、在真实交互时刻打点、配合performance.measure计算端到端耗时，并及时清理避免缓冲区溢出。

用 performance.mark 建立业务代码执行的关键性能基准监控点，核心在于在真实用户路径中插入语义明确、可复用、可测量的时间锚点，而非简单打点。它不是为调试服务，而是为量化业务逻辑耗时、定位体验瓶颈提供依据。

明确 mark 的命名规范与业务语义

每个 mark 名称应能直接反映用户行为或关键业务阶段，避免模糊缩写或技术术语。例如：

• ✅ 推荐：'user-login-start'、'cart-submit-begin'、'product-list-render-complete'
• ❌ 避免：'step1'、'load'、'init'（含义不唯一，难以归因）

命名统一后，后续用 performance.measure 或分析工具提取时，才能准确聚合同类场景数据。

在真实用户交互上下文中插入 mark

mark 必须出现在实际触发业务逻辑的时刻，而不是组件挂载或函数定义处。常见有效位置包括：

• 用户点击提交按钮的事件回调开头（标记「操作发起」）
• Ajax 请求发送前（标记「请求发出」）
• 关键渲染完成后的 requestIdleCallback 或 queueMicrotask 中（标记「UI就绪」）
• 第三方 SDK 初始化完成回调内（标记「支付模块加载完成」）

注意：不要在异步回调未确定执行时机的位置打点（如未 await 的 Promise.then 外部），否则时间戳可能失真。

配合 measure 实现端到端耗时计算

单独 mark 没有直接价值，必须与 performance.measure 配合使用才能生成可观测指标：

• 在业务开始处调用 performance.mark('checkout-start')
• 在订单确认页完全渲染并可交互后调用 performance.mark('checkout-success')
• 立即执行 performance.measure('checkout-total', 'checkout-start', 'checkout-success')
• 后续可通过 performance.getEntriesByName('checkout-total', 'measure') 提取结果

该 measure 条目会自动包含 duration 字段，单位为毫秒，精度可达微秒级（受浏览器安全策略限制，通常为 1–5ms），适合统计 P90/P95 耗时分布。

注意清理与内存控制

长期运行的单页应用（SPA）若持续打 mark 不清理，会导致 performance entry buffer 溢出，触发 resourcetimingbufferfull 事件，甚至影响性能采集稳定性：

• 建议在路由切换或页面级业务流结束时，调用 performance.clearMarks('checkout-start') 或 performance.clearMarks()
• 对 measure 同样处理：performance.clearMeasures('checkout-total')
• 也可监听 performance.onresourcetimingbufferfull 主动做批量清理

不清理不会报错，但会让历史无效 mark 干扰分析，也增加内存占用。