Chrome DevTools调试需正确设断点并启用sourceMap，善用debugger和console.table等API，Performance面板录制要勾选Network和Screenshots，用performance.mark/measure精准计时，注意执行上下文和干扰因素。
Chrome DevTools 里怎么打断点
直接在 Sources 面板左侧文件树中点击行号即可设置断点，这是最常用也最可靠的方式。但要注意：如果代码经过打包（比如用 Webpack、Vite），原始 sourceMap 没开启或加载失败，断点会打在压缩后的 bundle.js 上，根本没法看逻辑。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 确保构建配置中开启了
devtool: 'source-map'（Webpack）或build.sourcemap: true（Vite） - 在已加载的脚本中右键选择
Blackbox script可跳过第三方库的断点，避免误停 - 用条件断点更精准：右键断点 →
Edit breakpoint→ 输入表达式如id === 123 - 临时禁用所有断点用快捷键
Ctrl+Shift+F8（Win/Linux）或Cmd+Shift+F8（Mac）
console.log 不够用时，该用哪些调试 API
console.log 容易污染代码、漏删、性能差；真正调试时应优先用 debugger 语句和结构化日志 API。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 在关键位置插入
debugger;，它会在运行到此处时自动触发 DevTools 断点（前提是 DevTools 已打开） - 用
console.table(data)查看数组或对象，比console.log更清晰 -
console.group('API')+console.groupEnd()折叠日志块，适合追踪流程分支 - 避免在循环里写
console.log(i)，改用console.count('loop')统计执行次数
Performance 面板怎么抓一次真实的页面卡顿
不能只看 FPS 数字——它可能掩盖长任务（Long Task）或布局抖动（Layout Thrashing）。真实卡顿往往来自 JS 执行阻塞主线程，或频繁强制同步布局。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 录制前勾选
Network和Screenshots，便于关联请求与帧画面 - 操作页面后按
Ctrl+E（Win/Linux）或Cmd+E（Mac）停止录制，再点顶部Bottom-Up标签看耗时最长的调用栈 - 重点关注
Scripting分类下的黄色/红色长条，右键 →Reveal in Sources直跳源码 - 若发现大量
Layout或Recalculate Style，检查是否在循环中读取了offsetHeight、getComputedStyle等触发重排的属性
为什么 performance.mark() + performance.measure() 比 Date.now() 更准
Date.now() 受系统时间调整、毫秒精度限制影响，而 performance.mark() 基于高精度时间戳（通常精确到微秒），且不会被系统时钟漂移干扰，是测量函数执行、资源加载的真实首选。
实操示例：
performance.mark('api-start');
fetch('/api/data').then(() => {
performance.mark('api-end');
performance.measure('api-duration', 'api-start', 'api-end');
// 测量结果可通过 performance.getEntriesByName('api-duration') 获取
});
注意点：
- 标记名必须是字符串，且不能含空格或特殊字符
- 同一标记名重复调用
performance.mark()会覆盖前一次，如需多次测量请用唯一 ID（如api-start-${Date.now()}） -
performance.clearMarks()和performance.clearMeasures()要及时清理，否则历史数据会累积影响分析
this 或闭包变量），以及 Performance 录制时忘了关掉其他标签页——它们的后台脚本会干扰主线程采样。 
