VSCode通过工作区设置（.vscode/settings.json）实现项目级配置隔离，优先于用户级设置且可提交Git；需以文件夹形式打开项目，注意文件名全小写、语法正确，并区分适合/不适合放入工作区的配置项。
VSCode 本身不支持“为每个项目自动加载不同全局设置”，但可以通过工作区设置（.vscode/settings.json）实现项目级配置隔离——这是最可靠、最常用、也最符合 VSCode 设计意图的方式。
为什么不能直接改用户 settings.json？
修改 settings.json（用户级）会影响所有打开的文件夹和窗口，比如你为 Python 项目设了 "python.defaultInterpreterPath"，再打开一个前端项目，这个路径可能干扰 ESLint 或 Prettier 的行为。更严重的是，团队协作时，用户级设置无法被 Git 跟踪，别人拉代码后还得手动配一遍。
工作区设置才是正确出口，它只在当前文件夹（含子目录）生效，且可提交到仓库。
如何创建并正确使用 .vscode/settings.json？
在项目根目录下新建 .vscode 文件夹，再在里面建 settings.json。注意：文件名必须全小写，大小写错误（如 Settings.json）会导致 VSCode 完全忽略它。
- VSCode 启动时会优先读取
.vscode/settings.json，覆盖用户级同名设置 - 设置项写法和用户 settings 完全一致，例如：
{ "editor.tabSize": 2, "files.exclude": { "**/__pycache__": true }, "python.defaultInterpreterPath": "./venv/bin/python" } - 如果某项没出现在工作区配置里，仍会回退到用户级设置，无需重复写全部配置
哪些设置适合放工作区？哪些不该放？
工作区设置适合那些“与项目强绑定”的配置：
阿拉丁·前端工程工坊把「前端只会写页面、规范停在文档里、脚手架手敲、构建靠抄、性能靠猜、可访问性靠忘」从「手动搭项目、抄配置、肉眼查规范」升级成一条本地工具链——多框架脚手架生成(React/Vue3/Svelte + Vite)、可复用组件生成(Props 类型+样式+示例)、规范落地检查(lint-lite:命名/未用变量/console残留/TS any/目录结构)、构建配置生成与产物体积预算、性能审计(依赖体积/重复/懒加载/Lighthouse 清单)、可访问性(a11y)校验(alt/aria
-
python.defaultInterpreterPath（指定本项目的虚拟环境） -
eslint.workingDirectories（多包 monorepo 下的规则作用域） -
files.watcherExclude（排除 node_modules 或 build 目录提升性能） -
editor.codeActionsOnSave（仅对该项目启用 auto-fix）
不适合放的有：
-
workbench.colorTheme（主题属于个人偏好，不应强制团队统一） -
window.zoomLevel（纯显示设置，和项目无关） -
telemetry.enableTelemetry（涉及隐私/策略，应由用户自主控制）
遇到设置不生效？先检查这三件事
工作区设置看似简单，但几个细节极易踩坑：
- 确认 VSCode 是以**文件夹形式打开项目**（File → Open Folder），而不是单个文件（Open File）——只有打开文件夹才会加载
.vscode/settings.json - 检查右下角状态栏是否显示「工作区」字样；若显示「用户」，说明当前未识别为工作区
- 运行命令
Developer: Show Settings Search，搜索某个设置项，看右侧是否标注「Workspace」来源；若显示「User」或「Default」，说明你的settings.json没被读取或有语法错误
另外，某些扩展（如 Prettier、ESLint）有自己的配置优先级逻辑，它们可能读取 .prettierrc 或 .eslintrc.js 而非 VSCode 设置，这时候得看扩展文档，别只盯 settings.json。
