如何用JavaScript进行代码调试_断点和性能分析怎么做

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 录制时忘了关掉其他标签页——它们的后台脚本会干扰主线程采样。