最稳方式是使用VSCode内置命令“Developer: Open Extensions Folder”一键打开插件文件夹；该命令由VSCode自行解析真实路径，不依赖系统、不关心用户名含空格或中文，且命令名必须为Open而非Show。
怎么直接打开 VSCode 插件安装目录
最稳的方式不是查路径、不是拼字符串，而是让 VSCode 自己告诉你它把插件放哪儿了。命令面板里搜 Developer: Open Extensions Folder，回车——文件管理器立刻弹出真实路径，不依赖系统、不care用户名带空格或中文，也不怕 macOS 上误点到 ~/Library/Application Support/Code/User/extensions 这种过时位置。
- Windows 用
Ctrl+Shift+P，macOS/Linux 用Cmd+Shift+P或Ctrl+Shift+P - 别输错命令名：是
Open，不是Show（旧版 UI 可能显示“Show”，但命令名始终是Open Extensions Folder） - 这个目录下每个子文件夹就是一个插件，命名如
ms-python.python-2024.12.1，一眼能看出发布者、插件名和版本
为什么不能只靠默认路径硬记
因为默认路径只是“通常情况”，不是铁律。VSCode 允许通过 --extensions-dir 启动参数覆盖路径，比如团队共用一台机器时可能统一指向 /mnt/shared/vscode-extensions；或者你手动改过配置，那 ~/.vscode/extensions 就只是个空壳。
- 执行
code --list-extensions --show-paths能看到每个插件的实际路径，比猜更准 - 在终端里跑
echo ~/.vscode/extensions只能验证“默认位置是否存在”，不能证明插件真在那儿 - macOS 上尤其容易踩坑：有人翻文档看到
~/Library/Application Support/Code/User/extensions就去访问，结果是空的——那是用户设置和缓存，不是插件存放地
插件目录结构里哪些文件值得关注
进到某个插件子目录后，package.json 是核心入口，里面定义了激活时机、贡献点、主模块路径等；node_modules 如果存在，说明插件自带依赖，删它会导致功能异常；而 out/ 或 dist/ 通常是编译后的代码，调试时看这里比源码更直接。
- 不要手动删
node_modules：重装插件会自动恢复，但删了可能导致Cannot find module错误 -
package.json里的main字段指向启动文件，比如"main": "./out/extension.js"，这就是插件实际运行的起点 - 如果插件支持调试，
.vscode/launch.json可能藏在插件目录里，但多数第三方插件不自带，得自己配
定位插件功能代码时容易忽略的点
很多插件的功能逻辑不在根目录，而是分散在 src/ 或 src/commands/、src/outline/ 这类子目录里。比如 Code Outline 的大纲生成逻辑，实际在 src/tree/OutlineTreeProvider.ts，而不是 extension.js 里直接写死。
- 搜索关键词比盲目翻文件高效：在插件目录里用 VSCode 全局搜索
getDocumentSymbols，能快速定位符号解析逻辑 - 语言服务相关功能（如大纲、跳转）往往调用
vscode.languages.getDocumentSymbols，这是 VSCode 提供的 API，不是插件自己实现的解析器 - 插件本身不解析语法，它只是 LSP 客户端，真正干活的是 TypeScript Server、Python Language Server 等后台进程
package.json 和调用链，比一上来就扒 node_modules 有效得多。 
