工作区设置优先级高于用户设置，仅对以该文件夹为根打开的窗口生效；用户设置全局生效，二者叠加时工作区配置覆盖同名用户项。
用户设置是全局生效的，工作区设置只对当前文件夹（含子目录）起作用；二者叠加时，工作区设置优先级更高。
用户设置 vs 工作区设置：作用范围与优先级
VS Code 的配置分三层：默认设置（只读）、settings.json 用户级、.vscode/settings.json 工作区级。用户设置位于 Code → Preferences → Settings（GUI）或 ~/.config/Code/User/settings.json（Linux/macOS）、%APPDATA%\Code\User\settings.json（Windows）。工作区设置必须放在项目根目录的 .vscode/settings.json 中，且仅对该文件夹内打开的编辑器窗口生效。
- 用户设置影响所有项目，比如
"editor.fontSize": 14、"files.autoSave": "onFocusChange" - 工作区设置覆盖同名用户项，适合项目专属规则，例如
"python.defaultInterpreterPath": "./venv/bin/python" - 若某设置在用户和工作区中都存在，工作区值一定生效——这是唯一确定的覆盖逻辑
哪些设置适合放在工作区？
涉及路径、语言特定行为、团队协作约定的配置，应进工作区。否则容易污染其他项目或引发环境不一致。
-
"eslint.workingDirectories"：必须按项目结构设，不能全局写死 -
"prettier.semi"或"editor.tabSize"：不同项目可能有不同代码规范 -
"git.ignoreLegacyWarning"：仅当前仓库需关闭提示时才加 -
"files.exclude"：如"**/dist": true，只对当前构建产物目录生效
如何安全地分层管理？
不要在工作区里重复用户已配好的通用项；也不要在用户设置里硬编码项目路径。关键在于“职责分离”。
- 用户设置专注个人习惯：
"workbench.startupEditor": "none"、"telemetry.enableTelemetry": false - 工作区设置专注项目事实：
"typescript.preferences.importModuleSpecifier": "relative"、"editor.codeActionsOnSave": { "source.fixAll.eslint": true } - 用 VS Code 内置的设置搜索（
Ctrl+,）查看某设置的当前生效值右侧是否显示Workspace或User标签，避免误判 - 如果某个设置在工作区没生效，先检查
.vscode/settings.json是否被.gitignore忽略了——它得真实存在于磁盘上
{
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll": true
},
"eslint.validate": ["javascript", "typescript"]
}
工作区配置最容易被忽略的是作用域边界：它只对“以该文件夹为根打开的窗口”有效。如果你用 code /path/to/project 打开，它才加载；如果只是把项目文件夹拖进一个已打开的、根为 /home 的窗口里，.vscode/settings.json 不会触发。
