必须将插件源码根目录移至纯英文路径，因中文路径会导致vscode-test、tsc编译、vsce打包及调试器在Windows上因GBK与UTF-8编码冲突而失败，且无法通过配置修复。
VSCode插件开发时路径含中文会直接导致调试失败
插件开发阶段若工作区或插件源码路径含中文，vscode-test 启动测试窗口、npm run compile 生成 out/ 目录、甚至 vsce package 打包时都会出错。根本原因不是 VSCode 界面，而是 Node.js 的 child_process.spawn 在 Windows 上默认用 GBK 解析参数，而 TypeScript 编译器、tsc、mocha 等工具链内部路径处理依赖 UTF-8 —— 二者在路径字符串上“对不上号”。
典型报错包括：Error: spawn C:我的插件
ode_modules.bin sc ENOENT、Cannot find module 'C:Users张三...（路径被截断）、TypeError [ERR_INVALID_MODULE_SPECIFIER]（import 路径解析失败）。
- 必须把插件源码根目录移到纯英文路径下，例如
D:devmy-extension，不能只改 VSCode 安装路径 - 确保
package.json中的main、activationEvents、scripts字段引用的路径（如"./src/extension"）不依赖运行时拼接中文路径 - 不要用
path.join(__dirname, '中文目录')构造资源路径 —— 改用vscode.Uri.file()+vscode.workspace.fs.readFile()等 API 安全读取
调试 launch.json 中的中文路径陷阱
即使插件代码本身没中文，launch.json 里写死的路径仍可能踩坑。比如 "program": "${workspaceFolder}\out\test\index.js" 看似安全，但若 ${workspaceFolder} 是 D:项目my-ext，VSCode 调试器底层调用 node 时仍可能传入乱码参数。
更隐蔽的是 env 或 args 字段里拼接路径：比如 "args": ["--extensionDevelopmentPath=${workspaceFolder}"]，这个变量展开后若含中文，code --extensionDevelopmentPath 命令行参数就会失效。
- 调试前先确认
process.env.VSCODE_PID和process.argv是否含乱码（可在 extension 的activate函数里加console.log(__filename)验证） - 统一用
${workspaceFolderBasename}替代${workspaceFolder}避免路径参与命令构造 - 调试启动命令改用
code --extensionDevelopmentPath="D:\dev\my-extension"（双反斜杠+英文路径），绕过变量展开环节
vsce 发布时路径过长或含中文导致打包失败
vsce package 本质是把整个插件目录压缩为 ZIP，再重命名为 .vsix。Windows 资源管理器默认解压逻辑不支持长路径，而 vsce 内部调用的 zip-stream 库在文件名编码上对非 ASCII 字符处理不稳定 —— 尤其当 package.json 的 icon、preview 字段指向中文路径下的图片时，打包会静默失败或生成损坏的 VSIX。
现象：命令行无报错，但生成的 .vsix 文件无法拖入 VSCode 安装，提示 Invalid package: specified file name is invalid or too long。
- 所有静态资源（图标、截图、README 中的本地图片链接）路径必须为纯英文、无空格、深度 ≤3 层，例如
images/icon.png，而非资源/图标.png - 发布前执行
vsce ls检查打包内容列表，确认所有路径字段（files数组）不含中文和超长路径 - CI 环境中强制设置
chcp 65001（UTF-8 代码页）再运行vsce package，避免 PowerShell 默认 CP936 干扰
CI/CD 流水线中路径兼容性容易被忽略
本地开发能跑通，不代表 CI 流水线（GitHub Actions / Azure Pipelines）也能过。Linux runner 默认 UTF-8 环境看似友好，但 Docker 容器若 base image 是 mcr.microsoft.com/vscode/devcontainers/base:ubuntu，其 locale 可能未设为 en_US.UTF-8，导致 tsc 编译时路径解析异常；Windows runner 则面临和本地一致的 MAX_PATH 和代码页问题。
最常被跳过的一步：没验证 vsce publish 前的签名步骤是否因路径问题失败 —— vsce 调用 openssl 签名时，临时密钥路径若含中文，会触发 error:02001003:system library:fopen:No such process。
- CI 脚本开头统一加
export LANG=en_US.UTF-8（Linux/macOS）或chcp 65001 > nul（Windows） - 所有构建产物路径硬编码为
/tmp/vscode-ext或C:uild，禁用${{ github.workspace }}直接拼接 - 用
vsce package --no-yarn显式关闭 yarn 缓存路径干扰（yarn 默认缓存路径可能含用户中文名）
vsce publish 最后一步因签名路径含中文失败，而错误日志只显示 openssl 错误，根本不会提示是路径问题。 
