VSCode调试Node.js断点无效，根本原因是launch.json配置与实际运行环境不匹配：program必须指向可执行JS文件（如${workspaceFolder}/src/app.js），不能是.ts源码；需启用--inspect协议、正确配置sourceMaps及env变量，否则调试器无法准确附着进程或解析源码。
VSCode 调试 Node.js 不是“点一下 F5 就行”，关键在于 launch.json 的配置是否匹配你的启动方式、环境变量和项目结构；错配会导致断点不命中、process.env 为空、甚至调试器直接退出。
为什么 launch.json 配置不对，断点就无效？
VSCode 的 Node.js 调试器依赖 V8 Inspector 协议，它需要准确知道从哪启动进程、用什么参数、加载哪些文件。如果 program 指向了错误入口（比如误写成 dist/index.js 但你还没构建），或 env 没传 NODE_ENV 导致条件分支跳过，断点自然不会触发。
-
program必须指向可执行的 JS 文件（如${workspaceFolder}/src/app.js），不能是 TypeScript 源码或未编译的.ts文件 - 若用
ts-node启动，program应设为${workspaceFolder}/node_modules/.bin/ts-node，并把实际入口加到args里 -
skipFiles: ["<node_internals>/**"]</node_internals>必须保留，否则调试会频繁卡在internal/模块里，干扰主线逻辑 - 使用
nodemon时，不要在launch.json里直接调用它——应改用request: "attach"模式，先用命令行启动带--inspect的 nodemon 进程
ESLint + Prettier 冲突时，谁该让步？
两者默认规则存在重叠（比如引号、分号、逗号位置），不协调会导致保存时反复格式化又报错。Prettier 是“格式化引擎”，ESLint 是“代码质量检查器”，分工必须明确。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 在
.eslintrc.js中加入extends: ["eslint:recommended", "plugin:prettier/recommended"]，让 ESLint 主动禁用所有与 Prettier 冲突的规则 -
prettier插件本身不修复问题，只格式化；真正自动修复靠 ESLint 的source.fixAll.eslint保存钩子 - 若用
npm run lint -- --fix手动修复，确保eslint-config-prettier已安装且生效，否则--fix可能干掉 Prettier 格式 - 避免在
.prettierrc里写"semi": false同时又在 ESLint 里开semi: ["error", "always"]——这会让编辑器陷入“格式→报错→再格式→再报错”循环
调试时看不到 require 或 module.exports 的值？
这是 CommonJS 模块系统的调试盲区：VSCode 默认不把模块对象暴露在作用域顶层，require 和 module 在 Debug Console 里查不到，但它们确实存在。
- 在断点处打开 Debug Console，输入
Object.keys(require.cache)可看到已加载模块路径列表 - 想查某个模块导出内容，用
require('path/to/module')——注意路径必须是运行时解析后的绝对路径或相对路径（不是import风格） -
module.exports本身无法直接打印，但可在模块末尾加console.log('exports:', module.exports)辅助验证 - 若用 ESM（
type: "module"），require和module不可用，此时需改用import.meta.url和动态import()查看模块状态
最常被忽略的是 launch.json 中 console 字段的取值："integratedTerminal" 能看到 console.log 输出并交互，而 "internalConsole" 会吞掉部分输出且不支持命令输入——尤其在调试 CLI 工具时，这点直接影响你能否复现用户真实执行流。
