关键在打点位置而非调用方法：起始点选用户触发或逻辑明确开始的稳态节点，结束点需数据解析完成、dom更新且可见；命名规范、配对严格、实时上报并清理。
直接用 performance.mark() 和 performance.measure() 就能测，但关键不在“会不会调”，而在“打在哪儿”——打点位置错了，数据再准也没用。
找准业务逻辑的真实起止点
代码执行开始 ≠ 用户感知开始，函数返回 ≠ 结果可用。标记必须落在可验证的稳态节点上：
- 起始点选在用户触发动作或系统明确进入该逻辑的瞬间，比如按钮点击回调第一行、路由参数可读取后、防抖结束后的首次有效调用
- 结束点不是
fetch().then()或setState完成，而是数据已解析、模板已更新、关键 DOM 已挂载且可见（例如el.offsetHeight > 0 && el.textContent.trim()） - 避免在
mounted、useEffect立即打结束点——此时常是骨架屏；也不要在Promise.resolve()后立刻打，DOM 还没重绘
规范命名与配对测量
每个 measure 都依赖两个真实存在的 mark，缺一不可，且浏览器不会报错，只会静默失败：
- 命名用小写字母 + 短横线，语义清晰，如
'search_submit_start'、'search_results_rendered' - 禁止拼接动态值（如
'item-' + id），否则无法聚合统计 p95/p99 - 同一链路中，准备、触发、响应、渲染、可见各阶段用独立名称，不复用
- 显式创建测量：
performance.measure('search_duration', 'search_submit_start', 'search_results_rendered') - 上线前验证：
performance.getEntriesByName('search_results_rendered', 'mark').length === 1
安全采集与可靠上报
数据留在内存里等于没测：
- 优先用
PerformanceObserver实时监听新创建的measure条目，低开销、无遗漏 - 兜底在
beforeunload中用navigator.sendBeacon()上报剩余数据，避免页面关闭丢数 - 做简单抽样（如
userId % 100 === 0才上报），控制服务压力 - 每次上报后调用
performance.clearMeasures()和performance.clearMarks()，防止缓存膨胀
不复杂但容易忽略：标记不在代码行号上“插针”，而在逻辑真正落地、用户真正看到的边界上。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
