直接调试 webpack.config.js 的执行入口：将 launch.json 中 program 设为 "${workspaceFolder}/webpack.config.js" 并配 args: ["--help"]，或设 program 为 node_modules/.bin/webpack（.cmd），确保函数式配置的断点打在 module.exports 函数体内而非导出语句上。

调试时怎么快速定位到 webpack.config.js 的执行入口

Webpack 配置文件本质是 Node.js 脚本，VSCode 调试它不依赖 Webpack CLI 启动流程，而是直接运行或注入调试上下文。关键在于让 launch.json 知道“从哪开始执行”。

• program 设为 "${workspaceFolder}/webpack.config.js" 最直接——但必须配合 args: ["--help"] 或类似参数，否则 Webpack 不会加载该配置（它只在真正打包时读取）
• 更稳妥的方式是设 program 为 "./node_modules/.bin/webpack"（Linux/macOS）或 "./node_modules/.bin/webpack.cmd"（Windows），这样环境变量、argv、env 完全等同于终端执行 npm run build
• 函数式配置 module.exports = (env, argv) => {...} 里断点必须打在函数体内部，比如 console.log(env.mode) 这一行，而不是 module.exports = 那行——后者根本不会被 debugger 停住

打断点前必须确认的三个状态

很多断点不触发，不是配置错，而是 VSCode 没真正进入调试上下文。每次启动前快速核对：

Pandas 配置文件报告生成器

使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。

下载

• 终端是否处于项目根目录？launch.json 中的 cwd 默认是 ${workspaceFolder}，但如果开了多根工作区，可能指向错误路径
• console 字段设为 "integratedTerminal" ——否则你看不到 Webpack 输出的 warning、progress 日志，无法判断它是否真的跑起来了
• 如果用的是 ts-node 运行 webpack.config.ts，确保 ts-node 已安装且版本兼容（2026 年主流项目通常已自带，但老项目可能漏装 @types/node 导致类型报错干扰调试）

常用快捷键：不是“按了就灵”，而是“按对才省事”

调试配置文件时，高频操作不是写代码，而是跳转、重试、观察变量。这些快捷键比 Ctrl+S 更关键：

• Ctrl + Shift + P → 输入 “Debug: Toggle Breakpoint” 快速开关当前行断点，比用鼠标点更准（尤其缩进深或行尾有注释时）
• F5 启动调试后，F10 单步跳过、F11 单步跳入——遇到 new HtmlWebpackPlugin() 这类插件初始化，用 F11 才能进到构造函数内部看参数是否合法
• Ctrl + Shift + Y 打开调试控制台（Debug Console），这里可以直接输入 process.env.NODE_ENV 或 argv.mode 查值，比在 Variables 面板翻找更快
• Shift + F8 跳到上一个断点位置——当你误点了 Continue 越过关键行，不用重启调试，直接倒退回来

npm script 调试卡住时的绕过技巧

npm run build 卡住不报错？终端只显示 “webpack compiled successfully” 但没输出 bundle，大概率是配置里某处同步阻塞（比如 fs.readFileSync 读了不存在的路径，或插件 constructor 抛了未捕获异常）。

• 不要改 package.json 脚本去加 --no-cache 或 --progress，直接在 launch.json 里配："program": "npm", "args": ["run", "build"]，然后在 webpack.config.js 开头加 debugger;
• 如果卡在第三方插件里（比如 CopyPlugin），在 node_modules 对应源码里手动加断点——VSCode 支持调试 node_modules 里的代码，只要源码带 source map 或是纯 JS
• 注意：某些插件（如 MiniCssExtractPlugin）在 mode: "development" 下行为不同，调试时务必确认 argv.mode 和你预期一致，否则断点停住的位置逻辑可能完全不一样

调试配置文件最麻烦的从来不是“怎么设断点”，而是“为什么断点没生效”。环境变量、执行路径、Webpack 版本对配置解析方式的影响，远比语法错误更隐蔽。每次怀疑配置有问题，先验证 env 和 argv 是否如你所想，比反复改 resolve.alias 有效得多。