核心是将复杂业务流程拆解为可命名、可定位、可复用的时间段，通过语义化 mark 打点关键节点，用 measure 显式关联起止标记生成耗时数据，并结合 getEntriesByName/ByType 提取验证、PerformanceObserver 自动化采集及 DevTools 可视化分析，构建真实场景性能基线。
用 performance.mark() 和 performance.measure() 埋点，核心是把复杂业务流程拆解成可命名、可定位、可复用的时间段，不是笼统测“整个流程”，而是明确知道“哪一步卡了、卡多久、是否重复发生”。
标记关键节点，让流程结构化
复杂业务工作流（比如“用户下单 → 校验库存 → 调支付网关 → 写订单库 → 发推送”）不能只打一个开始和结束标记。应在每个逻辑边界清晰处主动打标：
- 每个异步操作发起前：如
performance.mark('order-check-stock-start') - 关键数据就绪后：如
performance.mark('order-payment-response-received') - 状态变更完成时：如
performance.mark('order-database-committed') - 避免用模糊名称（如 'step1'），推荐语义化+短横线（如 'notify-sms-queued'）
- 同一阶段多次执行需加序号或时间戳，否则后一次会覆盖前一次（
performance.mark('fetch-data-' + Date.now())）
用 measure 关联耗时，生成可查条目
标记只是记点，measure 才真正产出可分析的耗时数据：
宝塔Linux面板11.3.0
下载
宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。
- 调用
performance.measure('check-stock-duration', 'order-check-stock-start', 'order-check-stock-end')显式定义区间 - 起止标记名必须已存在，否则 measure 不生效且无报错——建议在 measure 前加简单校验（如检查
performance.getEntriesByName('xxx-start').length） - 同一个标记名可参与多个 measure（如 'api-start' 既用于 'fetch-time'，也用于 'total-network-time'），便于多维度归因
- 测量名不必与标记名一致，利于分类统计（例如所有渲染相关 measure 都以 'render-' 开头）
提取与验证结果，避免误读
埋点后不取数等于没埋。要用标准方式及时提取并确认数据有效：
- 用
performance.getEntriesByName('check-stock-duration')获取指定测量项，取[0].duration得毫秒值（浮点数，精度达微秒） - 用
performance.getEntriesByType('measure')拿全部测量结果，适合批量分析或上报 - 测量结果默认保留在内存中，长时间运行页面要定期清理：
performance.clearMeasures()或按名清除 - DevTools → Performance 面板中开启 “User Timing” 轨道，可直观看到所有 mark/measurement 的时间位置和颜色编码，支持缩放、导出、跨帧对比
结合 PerformanceObserver 自动化采集
手动查 entries 适合调试，线上监控需自动响应：
- 创建 observer 监听
'measure'类型条目：new PerformanceObserver(cb).observe({entryTypes: ['measure']}) - 回调中过滤关键测量名（如
entry.name.startsWith('order-')），提取entry.duration和entry.startTime - 配合采样率控制（如仅上报耗时 > 500ms 的订单流程）、错误上下文（当前 URL、用户 ID）一并上报，形成真实场景性能基线
