调试时console.log不显示，需确认已启动调试（F5）、命中断点，输出在“调试控制台”底部而非终端；debugger失效多因sourceMaps未启用或路径配置错误；变量需在当前作用域才可查；代码修改后需手动重启调试或配nodemon。
调试时 console.log 不显示？先确认是否在调试器里执行
VS Code 的调试控制台（Debug Console）不是浏览器的 console，它只响应当前调试会话中 JS 引擎直接执行的表达式。你在代码里写的 console.log() 默认输出到“终端”或“调试控制台”下方的“调试控制台输出”区域，但前提是调试已启动且断点已命中。
常见错误现象：console.log("test") 写了却没看到输出，其实是没进断点、或调试没启动、或脚本根本没跑起来。
- 确保已按
F5启动调试（而非单纯运行），且launch.json配置正确（如type: "pwa-node"或"pwa-chrome"） - 加个断点（
F9），让执行停住，再在调试控制台里输入表达式，才能看到实时求值结果 - 如果想看
console.log输出，优先盯住“调试控制台”面板底部的输出流（不是“终端”面板）；它和 Node.js / Chrome 的实际 console 是同一上下文
debugger 语句不生效？检查源码映射和运行环境
debugger 是 JS 原生断点指令，但它依赖 sourcemap 和调试器是否接管了当前 JS 执行环境。在 VS Code 里它常失效，不是语法问题，而是配置或路径没对上。
使用场景：你写了个 debugger，但代码跑过去了没停——大概率是调试器压根没加载你的源文件。
- Node.js 调试需确保
launch.json中sourceMaps设为true，且构建工具（如 TypeScript、Webpack）生成了有效的.map文件 - 前端调试 Chrome 时，确认
webRoot指向的是实际服务的根目录（比如"${workspaceFolder}/dist"），否则断点找不到源码位置 - 如果用 ESM +
node --loader ts-node/esm启动，VS Code 默认不支持，得换pwa-node并配runtimeArgs
调试控制台里输什么能查变量？别直接敲 varName
调试控制台本质是 REPL，但它作用域受限于当前暂停帧（stack frame）。你不能随便输一个变量名就出来，必须它在当前作用域里声明过，且没被优化掉。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
参数差异：在函数内部断点，可以查形参和局部变量；在全局断点，只能查全局对象上的属性（比如 window.a 或 globalThis.b）。
- 不确定变量在哪一层？点开左侧“变量（Variables）”面板，展开
Local、Closure、Global查看真实作用域 - 想强制查看闭包外的变量？用
this或arguments.callee（非严格模式）试试，但不推荐——说明设计上变量暴露不够清晰 - 输入
typeof xxx或xxx?.toString()比直接输xxx更安全，避免因undefined或 getter 报错中断调试流
为什么改了代码，调试时还是旧逻辑？热重载没起作用
VS Code 调试本身不带热重载。你改完保存，调试进程不会自动重启或刷新——除非你手动按 Ctrl+Shift+F5（重启）或配了文件监听工具（如 nodemon）。
性能影响：频繁重启调试进程有延迟；而靠 nodemon + attach 模式虽快，但首次 attach 失败率高，尤其端口被占时。
- Node.js 开发建议用
attach模式：先命令行跑nodemon --inspect-brk app.js，再在 VS Code 里选 “Attach to Node Process” - 前端开发可配合
webpack-dev-server的hot: true，但注意：JS 模块热更新后，断点位置可能偏移，需重新加载页面再断 - 改了
launch.json必须重启整个调试会话，改完不重启 = 白改
调试控制台不是万能沙盒，它和当前执行帧强绑定，脱离上下文的表达式大概率报错。最常被忽略的是：你以为停在某一行，其实调用栈已经跳出了那个函数——多看一眼左侧“调用堆栈（Call Stack）”面板，比反复输变量更省时间。
