工作区设置（.vscode/settings.json）优先级高于用户设置，同名配置无条件覆盖；需确保通过“open folder”打开项目根目录、文件路径正确、json格式合法，且仅“resource”作用域设置可被覆盖。
工作区设置（.vscode/settings.json）一定优先于全局用户设置，只要同名配置存在，就无条件覆盖——这不是可选行为，是 VSCode 的硬性规则。
为什么改了用户设置却没生效？
最常见的情况是：你刚在 Settings UI 里把 editor.tabSize 改成 4，但打开某个项目后发现还是 2。不是 VSCode 坏了，而是该项目根目录下的 .vscode/settings.json 里明确写了 "editor.tabSize": 2，直接盖掉了你的全局改动。
- VSCode 不会提示“这个值被覆盖了”，它只是默默执行优先级逻辑
- 检查方式：在 Settings UI 中搜索该配置项，右侧 ⓘ 图标会显示当前生效值来自 User 还是 Workspace
- 鼠标悬停在
settings.json的某个键上，编辑器也会提示作用域（Scope）信息
settings.json 文件位置和加载范围
全局用户设置文件路径固定，但内容只影响你账户下所有 VSCode 实例；工作区设置必须放在项目根目录的 .vscode/settings.json，且只对当前文件夹及其子目录生效。
- Linux/macOS 全局路径：
~/.config/Code/User/settings.json - Windows 全局路径：
%APPDATA%\Code\User\settings.json - 工作区路径：
你的项目根目录/.vscode/settings.json - 多根工作区中，每个子文件夹可自带
.vscode/settings.json，彼此独立
哪些设置根本无法被工作区覆盖？
不是所有配置项都支持工作区级覆盖。VSCode 把设置按作用域（Scope）分类，只有标记为 resource 的才能被 .vscode/settings.json 覆盖；application 或 machine 类设置（比如 update.mode、telemetry.enableTelemetry）写进工作区也无效。
- 判断方法：在 Settings UI 搜索某项，右侧图标如果是 ⚙️，说明支持多级作用域；如果是 ?，就只能在用户层改
- 常见不可覆盖项：
window.zoomLevel、extensions.autoUpdate、http.proxy - 误写进工作区不会报错，但 VSCode 启动时会静默忽略
团队协作时工作区设置该怎么提交？
.vscode/settings.json 应该提交进 Git，而不是加到 .gitignore。它的核心价值就是让团队成员开箱即用，避免“在我机器上是好的”这类问题。
- 推荐只放项目强依赖的配置，例如：
"eslint.validate"、"prettier.tabWidth"、"files.exclude" - 避免放个人偏好项，比如
"workbench.colorTheme"或"editor.fontFamily"—— 这些该留在用户设置里 - 如果项目用了 Prettier + ESLint，建议同时配
.vscode/extensions.json推荐插件，进一步降低环境差异
真正容易被忽略的是作用域类型判断和多根工作区中各子文件夹的独立配置能力——很多人以为 .vscode/settings.json 是“项目级开关”，其实它还能细粒度控制到某个子模块，前提是那个子文件夹也被当作独立工作区加载。
