默认目录结构会拖慢VSCode性能，因node_modules、vendor等无关目录被持续扫描，导致CPU占用高、智能提示延迟；需通过files.exclude/search.exclude精准排除，并采用多根工作区和src统一结构优化。
为什么默认目录结构在大型项目里会“卡住”VSCode
VSCode 对文件索引和语言服务的响应速度，直接受项目目录深度、文件数量和无关路径干扰程度影响。默认打开整个根目录时，node_modules、vendor、dist、build 这类目录会持续被扫描，导致 CPU 占用高、智能提示延迟、搜索变慢，甚至偶尔触发“文件监视器耗尽”错误。
这不是 VSCode 性能差，而是它默认假设你“需要看到所有东西”。但真实开发中，你真正编辑的往往只是 src/、app/ 或 lib/ 下的几十个文件——其余都是构建产物或依赖缓存。
- 对 Laravel 项目，
vendor/和storage/framework/必须排除，否则 PHP Intelephense 启动后可能卡顿 10 秒以上 - 对前端 monorepo，
packages/*/node_modules层级嵌套过深，会导致 TypeScript 语言服务器反复重载 - 直接把
git目录全量纳入资源管理器，会让右键菜单响应变迟钝（尤其在 Windows 上）
files.exclude 和 search.exclude 必须配齐
files.exclude 控制资源管理器里“不显示哪些路径”，search.exclude 控制 Ctrl+Shift+F 搜索时“跳过哪些路径”。两者不等价，漏配一个就等于白优化。
推荐在项目根目录的 .vscode/settings.json 中写入：
{
"files.exclude": {
"**/.git": true,
"**/node_modules": true,
"**/vendor": true,
"**/dist": true,
"**/build": true,
"**/coverage": true,
"**/storage/framework": true,
"**/public/build": true
},
"search.exclude": {
"**/node_modules": true,
"**/vendor": true,
"**/dist": true,
"**/build": true,
"**/coverage": true,
"**/storage/framework/cache": true,
"**/storage/logs": true
}
}
-
**/.git设为true是为了视觉清爽；但它不影响 Git 功能，提交、拉取照常工作 - Laravel 的
storage/framework/cache和logs要单独列在search.exclude里，否则日志爆炸式增长时搜索会卡死 - 不要用
**/node_modules/**—— VSCode 不支持双星号嵌套通配，只认**/node_modules
多根工作区（.code-workspace）不是“高级功能”，而是大型项目的刚需
当你同时维护前端 + 后端 + CLI 工具时，硬塞进一个文件夹再靠 files.exclude 过滤，只会让资源管理器越来越臃肿。这时必须用 .code-workspace 文件把它们逻辑隔离。
比如微服务项目，创建 myproject.code-workspace：
{
"folders": [
{ "name": "api", "path": "./services/api" },
{ "name": "web", "path": "./apps/web" },
{ "name": "shared", "path": "./libs/shared" }
],
"settings": {
"editor.tabSize": 2,
"files.exclude": { "**/node_modules": true }
}
}
- 每个
folder可以有自己的.vscode/settings.json，比如api/用 PHP Intelephense，web/用 Volar；而settings区块定义的是整个工作区共用项 - 终端启动目录默认是第一个
folder的路径，如需统一到某个目录，加"terminal.integrated.cwd": "${workspaceFolder:api}" - 别把
.code-workspace文件放在项目根下就完事——要把它作为团队标准配置提交到 Git，并在 README 里写明“用 VSCode 打开此文件而非文件夹”
src/ 目录不是 Python 专利，它对任何语言都有效
把源码统一放进 src/，不只是为了打包干净，更是为了让 VSCode 的语言服务器“专注干活”。比如 Python 的 src/myapp/ 结构，配合 "python.defaultInterpreterPath": "./venv/bin/python" 和 "python.testing.pytestArgs": ["src"]，就能避免测试发现不了模块、补全找不到包的问题。
同理，TypeScript 项目设 "compilerOptions.baseUrl": "src"，PHP 项目在 composer.json 里配 "autoload": { "psr-4": { "App\": "src/" } }，都能让 VSCode 的跳转、重命名、引用查找更准。
- VSCode 的文件监视默认基于工作区根目录，
src/把“可编辑代码”物理收拢，天然减少误触node_modules或dist的风险 - 如果项目已有历史结构（比如 Laravel 默认没
src/），不必强行迁移——可以用files.exclude把非app/、routes/、config/等核心目录全部隐藏，效果等价 - 注意：某些插件（如 ESLint）默认从工作区根找配置，若配置文件在
src/下，需显式设置"eslint.workingDirectories": ["./src"]
最常被忽略的一点：目录结构优化不是一次性动作，而是随项目演进持续调整的活儿。比如新增一个 scripts/ 目录跑自动化任务，第二天就得把它加进 files.exclude；引入新的构建工具生成 .turbo，立刻 exclude 它。VSCode 不会主动提醒你这些，得养成“加新目录 → 查看资源管理器是否变卡 → 检查 exclude 列表”的条件反射。
