Chrome DevTools 通过 Performance 面板和 Runtime 事件系统完整还原脚本生命周期，涵盖加载、解析、执行与清理全过程；需启用Web Vitals、Screenshots、JS CPU Profile及网络记录，结合performance.mark锚点、ScriptEvaluation发起源分析、executionContextDestroyed/GC观察及Runtime事件（如consoleAPICalled、exceptionThrown）交叉验证执行上下文与副作用。
Chrome DevTools 通过 Performance 面板和 Runtime 事件系统，能完整还原脚本从加载、解析、执行到清理的全过程。关键不是看单个函数耗时，而是理清它在整个生命周期中的触发时机、上下文依赖和资源影响。
抓取含上下文的完整执行轨迹
录制前需确保启用关键选项：勾选“Web Vitals”“Screenshots”，打开“Record JavaScript CPU Profile”和“Record network”。在控制台提前运行 performance.mark("start") 作为人工锚点；操作后停止录制。Trace 中会自动标记 executionContextCreated（上下文创建）、ScriptEvaluation（脚本评估）、FunctionCall（函数调用）等事件，它们共同构成脚本生命周期的时间线。
定位脚本启动源头与执行入口
在火焰图中找到 ScriptEvaluation 块，点击后看 Summary 面板的 Initiator 字段：
- 若为 Parser，说明是 HTML 解析时同步加载的内联或 defer 脚本
- 若为 Script，通常来自
document.createElement("script")或import()动态导入 - 若为 TimerFire 或 EventListener，说明是定时器或用户交互触发的回调执行
- 配合右侧 Call Stack，可确认是否在某个 executionContextCreated 后立即开始执行
观察执行结束与上下文释放情况
脚本生命周期不只包含“跑起来”，还包含“退场”：
- 查找 executionContextDestroyed 事件，确认脚本所属上下文是否被及时回收（如 iframe 移除后）
- 若某脚本执行后长时间无 GC 或 Layout 事件，但内存占用持续上升，可能有闭包引用未释放
- 在 Memory 面板中录制 Allocation instrumentation on timeline，观察脚本执行期间是否有大量新生代对象未被回收
- 注意 executionContextsCleared 事件——页面刷新或导航时该事件出现，意味着所有脚本上下文被重置
结合 Runtime 事件交叉验证行为逻辑
打开 Command Menu（Ctrl+Shift+P），输入 “Enable runtime event logging”，启用 Runtime 监控后可捕获更细粒度行为：
- consoleAPICalled：判断脚本是否在特定阶段输出调试信息，辅助定位执行节点
- exceptionThrown：异常抛出位置常是生命周期中断点（如 Promise reject 后未处理）
- inspectRequested：开发者手动打断执行时的介入时机，可用于验证脚本是否按预期暂停
- 这些事件时间戳与 Performance 中的 ScriptEvaluation 对齐，就能确认脚本是否在预期上下文中运行、是否被异常打断、是否留下未清理副作用
