断点不生效主因是调试器未正确附加，需检查launch.json配置、启动调试而非直接运行，并确保sourceMap等设置匹配构建工具；条件断点和日志点可替代console.log；Watch用于主动表达式求值，变量面板展示当前作用域变量。
断点设置不生效？检查调试器是否已正确附加
VS Code 的断点依赖于调试器（Debugger）成功附加到运行进程。如果点击行号左侧加了红点但程序未停，大概率是没启动调试会话，或调试配置 launch.json 里 program、cwd、runtimeExecutable 等路径写错。
- 确认已按
Ctrl+Shift+D打开调试视图，并点击绿色三角形“开始调试”，而非直接运行脚本 - Node.js 项目需确保
launch.json中type为"node"，且program指向入口文件（如"${workspaceFolder}/index.js"） - Python 项目若用
python -m http.server类命令启动，需改用attach模式，不能用launch模式 - 浏览器调试前端时，必须先通过
Debugger for Chrome或Microsoft Edge Tools插件启动目标页面，再触发 attach
条件断点和日志点：比 console.log 更轻量的运行时探查
频繁增删 console.log 不仅污染代码，还容易忘记清理。VS Code 支持右键断点 → “编辑断点”，添加条件或转换为日志点（Log Point），后者不暂停执行，只输出表达式值。
- 条件断点示例：在循环内只在
i === 5时中断，右键断点 → 输入i === 5 - 日志点示例：输入
当前值: ${i}, 数组长度: ${arr.length}，效果等同于console.log(`当前值: ${i}, 数组长度: ${arr.length}`)，但无需修改源码 - 注意：条件表达式中不能调用会改变状态的函数（如
arr.pop()），否则行为不可预测
变量监视（Watch）与作用域面板的区别与协同使用
“变量”面板显示当前栈帧的局部变量、闭包变量和全局变量，而“监视”（Watch）是主动输入表达式并持续求值的地方。两者互补，但容易混淆用途。
- 想看某个对象深层属性（如
response.data.items[0].name）是否为空？不要展开十几层找，直接在 Watch 面板加这一整行表达式 - 监视表达式支持简写：输入
typeof data、data?.length、甚至JSON.stringify(errors)（只要当前上下文能访问） - Watch 表达式出错（显示
Cannot access 'xxx' before initialization）通常是因为变量尚未声明或不在当前作用域——这时回看“变量”面板，确认作用域层级更可靠
调试 Node.js 时 source map 未加载？关键在 outFiles 和 sourceMaps
TypeScript 或 Webpack 构建项目调试时，断点打在 .ts 文件却跳转到 .js，或根本无法命中，基本是 source map 路径解析失败。
-
launch.json中必须设"sourceMaps": true，且"outFiles"明确指向编译后 JS 文件位置（如["${workspaceFolder}/dist/**/*.js"]） - TS 编译需开启
"sourceMap": true和"inlineSourceMap": false（推荐生成独立.map文件便于调试器读取） - Webpack 用户注意：开发模式下
devtool: "source-map"是必须的；若用eval-source-map，VS Code 默认不支持，需额外配"resolveSourceMapLocations"
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch TS",
"program": "${workspaceFolder}/src/index.ts",
"outFiles": ["${workspaceFolder}/dist/**/*.js"],
"sourceMaps": true,
"smartStep": true,
"skipFiles": ["<node_internals>/**"]
}
]
}
断点和变量监视本身不难，难的是每次环境变更（TS 版本升级、打包工具换配置、跨平台路径差异）都可能让调试链路悄悄断裂。保持 launch.json 和构建配置的一致性，比记住快捷键重要得多。 
