断点调试的核心目的是验证代码执行路径是否符合预期，而非单纯找错误；需在重构前后用相同断点对比输入、状态流转与输出，并关注变量值、调用顺序、异步时机和DOM更新节奏。
理解浏览器断点调试的核心目的
断点调试不是为了“找到错误”，而是为了验证代码执行路径是否符合预期。重构前，先用断点确认当前逻辑的输入、状态流转和输出；重构后，再用相同断点对比行为是否一致。重点观察：变量值变化、函数调用顺序、异步时机、DOM 更新节奏。
重构前必做的三步断点准备
- 标记关键节点：在入口函数、条件分支首行、循环开始处、Promise.then/catch、事件回调内设断点，不只盯错误行
- 启用“忽略未加载脚本”和“黑箱脚本”：右键断点 → “Never pause here” 或在 Sources 面板右键第三方库 → “Blackbox script”，避免跳进 jQuery/React 内部干扰主线逻辑
-
保存当前执行快照：在断点暂停时，打开 Console，输入
copy({a: valueA, b: valueB, el: document.querySelector('#main')})，导出关键状态供后续比对
边调试边重构的安全操作法
不要一次性重写整个函数。推荐“断点锚定 + 小步替换”：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 在原函数某段逻辑前后各设一个断点（如计算前、赋值后），记下中间变量值
- 将这段逻辑抽成新函数，传入相同参数，返回相同结构，立即在原位置调用它
- 刷新页面，断点停住，对比新旧路径中变量值、this 指向、副作用（如 localStorage 修改）是否完全一致
- Chrome DevTools 的 “Step into”（F11）和 “Step out”（Shift+F11）比“Continue”（F8）更能精准控制粒度
识别重构风险的断点信号
以下暂停现象提示潜在问题，需立刻暂停重构、回溯检查：
- 断点触发次数异常（比如该进 1 次的循环进了 5 次）→ 检查闭包引用或事件重复绑定
- Watch 表达式显示
undefined但代码未报错 → 可能存在静默失败的可选链或空值合并，需补防御性判断 - DOM 断点（右键元素 → Break on → subtree modifications）意外触发 → 说明新逻辑意外修改了不该动的节点，检查 innerHTML 替换或 append 逻辑
不复杂但容易忽略。
