无法用 performance.mark() 捕获“js 引擎启动”时刻，因其发生在浏览器进程层面、早于 js 上下文创建；首个可靠标记应为 navigationstart 之后、domcontentloaded 之前且早于业务代码执行的时机，典型做法是在 head 顶部内联 script 中立即调用 performance.mark('app-init-early')。
直接结论：无法用 performance.mark() 捕获“JS 引擎启动”时刻，但能可靠捕获首个业务逻辑执行前的最早可标记节点——即 navigationStart 之后、DOMContentLoaded 之前、且早于任何业务代码执行的时机。
为什么不能标记 JS 引擎启动？
JS 引擎（V8 等）的初始化发生在浏览器进程层面，早于页面上下文创建，不属于 User Timing API 的作用域。你写的第一个 performance.mark() 调用本身就需要 JS 引擎已就绪、全局对象已存在、脚本已开始执行——此时引擎早已启动完毕。
真正可抓取的“起点”，是浏览器导航生命周期中最早暴露给 JS 的标准时间点：performance.getEntriesByType('navigation')[0].navigationStart。它代表页面导航发起时刻（含重定向、DNS、TCP 等前序阶段），也是所有后续 mark 的时间基准零点。
如何打第一个真正有意义的业务前标记？
目标不是“引擎启动”，而是“业务逻辑尚未执行，但环境已就绪”的临界点。典型做法是在 <script></script> 标签内联、且位于所有业务逻辑之前的位置立即打点：
- 把
<script></script>放在最顶部，不 defer、不 async - 第一行 JS 就调用
performance.mark('app-init-early') - 确保该脚本不依赖任何外部模块、不等待 DOM 或 window.load
这个标记实际反映的是：HTML 解析器遇到该 script 标签 → JS 引擎编译并执行该段代码的耗时，已包含解析、编译、首次执行开销，是业务侧能控制的最早可观测节点。
怎么关联到首个业务逻辑执行？
首个业务逻辑通常指入口函数（如 initApp()、renderRoot() 或 React/Vue 的 mount 调用）。关键在于确保它和前面的 mark 处于同一调用栈或可明确串连的异步链中：
- 避免在
setTimeout(..., 0)或Promise.resolve().then()中启动业务逻辑——这会引入 microtask/macro-task 调度延迟，破坏时序连续性 - 若必须异步（如等待 Webpack runtime 初始化），用
queueMicrotask()替代setTimeout，精度更高 - 打第二个 mark 时，命名需体现语义，例如
'app-entry-start'，而非泛泛的'start' - 立刻调用
performance.measure('app-init-to-entry', 'app-init-early', 'app-entry-start')
注意：如果 app-entry-start 因异常未执行，measure 会静默失败。建议在业务入口加一层存在性校验：
if (performance.getEntriesByName('app-init-early').length) {
performance.mark('app-entry-start');
performance.measure('app-init-to-entry', 'app-init-early', 'app-entry-start');
}
容易被忽略的兼容性与清理问题
这个路径看似简单，但长期运行的 SPA 或微前端场景下极易出问题：
-
performance.mark()不自动去重，同名多次调用只保留最后一次 —— 所以必须用唯一命名（如'app-init-early-' + Date.now()） - Chrome/Edge 支持
detail字段传上下文，但 Safari 不支持；跨浏览器唯一可靠方式是靠命名区分（如'app-init-early-main-app'） - 不做清理的话，单页跳转 10 次后可能堆积上百个无用 mark，拖慢 DevTools 性能分析面板加载
- 建议在路由切换完成、新页面逻辑启动前，调用
performance.clearmarks()和performance.clearmeasures()
真正难的不是打点，而是让每个 mark 都能稳定复现、不被异步调度污染、且在多实例共存时互不干扰。
