Chrome DevTools Performance面板可定位JS执行阻塞：录制操作后，在Main轨道识别>50ms黄色长任务，结合FPS下降、Layout触发及调用栈分析具体函数与渲染冲突。
直接用 Chrome DevTools 的 Performance 面板就能定位 JS 执行阻塞，关键不是看“有没有脚本”，而是看“它何时执行、持续多久、卡住了什么”。
打开并录制 Performance 面板
在页面加载或交互前，打开 DevTools → 切换到 Performance 标签页（如未显示，点右上角三点 → More Tools → Performance）→ 点击 ● 录制按钮 → 操作页面（如刷新、点击、滚动）→ 等页面稳定后点 ■ 停止。录制结果会完整呈现主线程活动时间线。
识别主线程上的长任务（Long Tasks）
在录制结果的 Main 轨道中，黄色高亮块即为长任务——任何单次执行超过 50ms 的操作都会被标记。JS 执行阻塞就藏在这里：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 每个黄色块对应一次主线程占用，鼠标悬停可看到耗时、类型（如 Script Evaluation、Function Call）
- 连续密集的黄块说明 JS 在持续霸占主线程，动画掉帧、点击无响应往往由此而来
- 点击某个长任务，在下方 Summary 中查看调用栈，重点找耗时最长的函数名（如
handleScroll、renderList、第三方 SDK 的trackEvent）
观察 JS 执行与渲染阶段的冲突
不要只盯着“Script”标签，要结合上下文判断是否阻塞了用户可见体验：
立即学习“Java免费学习笔记（深入）”；
- 若一段 JS 执行紧接在 First Contentful Paint (FCP) 之前，且耗时明显，很可能延迟了首屏内容渲染
- 若 JS 执行后紧跟着大量 Layout 或 Recalculate Style，说明代码触发了强制同步布局（比如先读
offsetHeight再改style.width） - 若 JS 执行期间 Frames 轨道出现空白或帧率骤降（低于 60fps），说明渲染被硬生生打断
配合代码级监控验证
面板只能告诉你“哪里慢”，要确认“为什么慢”，可在关键逻辑处加轻量监控：
- 用
performance.mark()和performance.measure()包裹可疑函数，录制后在 Timings 轨道查看精确耗时 - 启用 Long Task Observer，实时捕获超时任务并打印调用栈：
new PerformanceObserver(cb).observe({entryTypes: ['longtask']}) - 检查 Network 面板 Waterfall，确认阻塞 FCP 的是否是未加
defer或async的同步脚本
