chrome devtools 可直接诊断运行时性能瓶颈：performance 面板抓主线程长任务与渲染问题，memory 面板查内存泄漏，coverage 面板识别冗余代码，控制台用 time/timeend 或 performance.mark/measurement 轻量埋点定位耗时逻辑。
直接用 Chrome DevTools 的控制台相关能力就能做初步但有效的运行时性能瓶颈诊断，不需要额外装工具，关键在“边写边测”和“有目标地录”。
Performance 面板：抓主线程卡顿的源头
这是最常用也最直观的方式。打开 DevTools → Performance 标签页 → 点击左上角录制按钮（●），然后在页面上复现卡顿操作（比如点按钮、滚动、切换 Tab），停止录制后看生成的火焰图。
- 重点看 Main 线程下方的长条（红色或黄色）：宽度超过 50ms 就是长任务（Long Task），它会阻塞用户交互，是“假死”的直接原因；点开就能看到具体哪个函数、哪行 JS 在耗时
- 关注 FPS 曲线：持续低于 60fps 且伴随 Layout / Paint 高峰，说明渲染压力大，可能由频繁 DOM 修改或强制同步布局（Forced Sync Layout）引起
- 留意 GC（垃圾回收）标记：如果主线程频繁被 GC 中断，说明内存分配过快或存在泄漏苗头
Memory 面板：查内存是否悄悄涨不停
内存问题往往滞后显现，但一旦发生，页面会越用越慢甚至崩溃。适合在怀疑“用一会儿就卡”时使用。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 先点“Take heap snapshot”拍一张初始快照
- 执行疑似泄漏的操作（例如反复打开/关闭弹窗、切换列表页）
- 再拍一张快照，切换到“Comparison”模式，筛选 Detached DOM tree 或按构造函数（如
Array、Object、自定义类名）排序，看哪些对象数量/大小明显增长且没释放 - 常见线索：
Timer没清除、事件监听器没解绑、闭包中意外保留了大数组或 DOM 引用
Coverage 面板：发现“写了却没跑”的冗余代码
按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（Mac），输入 “Coverage” 回车启用。刷新页面后操作一遍核心流程，面板会标出 JS/CSS 中未执行的代码段（通常灰色）。
- 覆盖率 >30% 的文件值得重点关注——可能是按需加载没做好，或是功能已下线但代码还在
- 能帮你快速识别可删除的逻辑、废弃的 polyfill、或拆分打包的优化空间
- 对大型 SPA 或长期迭代的老项目特别有用
控制台内置测量法：轻量埋点，精准定位某一段
不用离开代码编辑环境，适合日常开发中验证某个函数、某个循环、某个 API 处理是否真慢。
-
console.time('label')+console.timeEnd('label')：简单粗暴，适合开发调试阶段快速比对 -
performance.mark('start')→ 执行逻辑 →performance.mark('end')→performance.measure('name', 'start', 'end')：更精确（微秒级），支持后续用performance.getEntriesByName()提取数据，也方便上报监控系统 - 监听长任务：
new PerformanceObserver观察longtask类型，可在测试或灰度环境自动捕获超时任务并打印堆栈
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
