调试时vsix体积暴增3–5倍，因vsce package默认全量拷贝工作区文件（含node_modules、dist、.git等），不执行tree-shaking或webpack构建，且main字段若指向源码路径会误打整个src目录；应清理dist/out、校验main为编译后js路径、配置.vscodeignore并使用vsce package --no-yarn --basecontenturl ./命令。
调试模式下插件体积暴增，不是打包逻辑错了，而是 vsce package 默认把整个工作区（含未忽略的 node_modules、dist、.git）全塞进 vsix —— 即便你本地用 npm run watch 只改了 1 行代码，调试构建仍会重复打包全部依赖。
为什么调试时 vsix 体积比发布版大 3–5 倍
VSCode 插件调试不走 vsce publish 流程，而是靠 vsce package 生成本地 vsix，它不做 tree-shaking，也不读 webpack.config.js，只做文件拷贝。常见膨胀点：
-
node_modules被完整复制（尤其含typescript、vscode-test等 dev 依赖） -
dist目录下混着未清理的*.js.map和旧版out/ -
.vscode文件夹或__test__目录被意外包含 -
package.json中main字段指向src/extension.ts（源码路径），导致 vsce 尝试打包 TypeScript 源文件
vsce package 必须加 --no-yarn 和 --baseContentUrl
不加 --no-yarn 时，vsce 会尝试调用 yarn install --production，但调试阶段你通常已手动装好依赖，这步不仅多余，还会因 yarn.lock 版本不一致触发重装，引入冗余模块。而 --baseContentUrl 不是可选项——它强制 vsce 使用相对路径解析资源，避免把本地绝对路径（如 C:\Users\xxx\...）写进 vsix 的 extension.js，否则调试器加载失败且体积虚高。
推荐调试打包命令：
vsce package --no-yarn --baseContentUrl ./
注意结尾的 ./：它让所有资源引用变成相对路径，同时跳过对 node_modules 的二次安装检查。
调试前必须清理 dist 并校验 package.json#main
调试构建不会自动清理输出目录，上一次构建残留的 dist/out 会被原样打包。更隐蔽的问题是 package.json 的 main 字段：如果它还指向 src/extension.ts 或 out/extension.js（TypeScript 编译前路径），vsce 会把整个 src/ 或 out/ 目录打进去，而不是仅取编译后的入口文件。
操作清单：
- 运行
npm run clean或手动删掉dist/和out/（确保只剩编译产物） - 检查
package.json#main是否为有效 JS 路径，例如"main": "dist/extension.js" - 确认
.vscodeignore存在且含标准条目：**/src/**、**/test/**、**/*.ts、**/node_modules/** - 若用 pnpm，额外加
**/node_modules/.pnpm/**到.vscodeignore
调试 vsix 启动慢？检查是否误打包了 webpack 构建产物
很多插件用 Webpack 打包 webview 或前端页面，但调试时容易把 dist/webview/ 下的完整 HTML/CSS/JS（含 source map 和未压缩的 vendor chunk）一起打进 vsix。这些文件不参与插件主逻辑，却占体积 60% 以上。
解决方法：
- Webpack 配置中设
devtool: false（禁用 source map） - 在
.vscodeignore显式排除dist/webview/**/*.map - 调试阶段改用
CopyWebpackPlugin只拷贝必要文件，而非整个dist/webview - 验证：解压刚生成的 vsix（重命名为
.zip），直接看dist/webview/目录大小 —— 若 >2MB，基本就是它拖慢了调试加载
真正影响调试效率的，从来不是代码行数，而是 vsix 解压后磁盘上的文件数量和单个大文件。一个含 12 万文件的 node_modules.asar 比 3 个 5MB 的 JS 文件更伤启动性能——因为 Electron 需逐个打开 asar 索引。动手前先 unzip -l your-extension.vsix | wc -l 看文件总数，比盲目删依赖更有效。
