构建可用自定义性能指标需锚定用户可感知、浏览器确认、语义清晰的真实节点，打点须在渲染就绪后（如 requestanimationframe 中验证 dom 状态），命名唯一且规范，measure 需配对存在并显式指定起止 mark，上报依赖 performanceobserver + sendbeacon 并含关键维度字段。
要构建真正可用的自定义性能指标，不能只调用 performance.mark() 和 performance.measure() 就完事。关键在于标记是否锚定在用户可感知、浏览器已确认、业务语义清晰的真实节点上，且整个链路从打点、测量到上报都可控、可验证、可聚合。
标记必须落在“稳态”而非“调用瞬间”
DOM 插入后立即 performance.mark('list-rendered') 很可能记录的是“写入完成”，而非“渲染就绪”。用户看到内容前，还需经历样式计算、布局、绘制等阶段。真正有效的打点需等待浏览器确认视觉就位：
- 单个元素插入：用
requestAnimationFrame回调，在下一帧检查node.isConnected && node.offsetHeight > 0 - 批量列表渲染：所有节点 append 后，取关键容器
getComputedStyle(el).display !== 'none'且el.children.length > 0再打点 - 避免在循环或节流回调内重复打同一名字的 mark，否则
performance.measure()默认只取第一个时间戳，导致耗时失真
命名要有业务语义，且严格唯一
mark 名不是代码日志，而是后续分析的聚合维度。名字一旦混乱，指标就无法归因：
- 用小写字母 + 短横线，如
'checkout-submit-start'、'search-results-shown' - 禁止拼接动态值（如
'item-' + id），否则无法统计 p95/p99 - 同一业务链路中，每个阶段用独立名称：准备、触发、响应、渲染、可见，各一个 mark，不复用
- 上线前用
performance.getEntriesByName('xxx', 'mark').length验证是否真的落进 PerformanceEntry —— 返回 0 就说明打点失效了
measure 要配对可靠，不能依赖“默认当前时间”
performance.measure(name, start, end) 不是自动计时器，它只是查表做减法。两个 mark 都得存在，且顺序合理：
- 起始 mark 必须在 measure 调用前已注册，否则 measure 静默失败（无报错、无条目）
- 避免省略
endMark依赖performance.now()，尤其在异步链路中，当前时间可能远滞后于真实完成时刻 - measure 名建议带前缀便于过滤，如
'time-to-payment-confirm'或'ui-list-render-ms' - 关键路径建议显式成对：先
mark('x-start')，再mark('x-end')，最后measure('x-duration', 'x-start', 'x-end')
上报要抗压、可追溯、不丢数
数据留在内存里等于没数据。但盲目上报又会撑爆服务端：
- 优先用
PerformanceObserver实时监听新产生的measure条目，比定时轮询getEntriesByType更精准、低开销 - 页面卸载前（
beforeunload）兜底上报，但必须用navigator.sendBeacon()，不可用fetch - 对非核心链路做抽样（如按用户 ID 哈希取模 1%），或对高频操作限频（如每分钟最多上报一次搜索链路）
- 上报 payload 中至少包含：
name、duration、url、user_id（脱敏）、device_type，方便多维下钻
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
