VS Code设置分用户级和工作区级，工作区设置优先且仅限.vscode/settings.json；修改应通过命令面板打开json文件，避免手动覆盖；同步不包括工作区配置及本地化设置。
VS Code 的用户设置是全局生效的，工作区设置只对当前文件夹有效；二者冲突时，工作区设置优先。别指望改一个地方就全项目统一——得看清楚你在改哪一层。
用户设置（settings.json）怎么改才不被覆盖
用户设置保存在 VS Code 内部配置路径下，但最稳妥的修改方式是通过命令面板打开：Ctrl+Shift+P（windows/linux）或 Cmd+Shift+P（macos），输入 Preferences: Open Settings (JSON) 回车。这样能避开 ui 设置的隐式覆盖风险。
- 手动编辑时，确保 JSON 格式合法，末尾不加逗号，键名用双引号包裹（如
"editor.tabSize"） - 不要直接修改
settings.json文件路径里的原始文件（比如~/Library/Application Support/Code/User/settings.json），容易被自动同步或重置覆盖 - 插件的用户级默认配置（如
"prettier.requireConfig"）也写在这里，但要注意：某些插件会忽略用户设置，强制读取工作区根目录下的配置文件（如.prettierrc）
工作区设置优先级高，但只认.vscode/settings.json
工作区设置必须放在项目根目录的 .vscode/settings.json 里，VS Code 才会识别。放在其他子目录、或命名为 settings.local.json 都无效。
-
.vscode/目录需和package.json或tsconfig.json在同一级，否则部分语言服务（如 typescript Server）可能无法正确加载工作区语义 - 如果同时存在
.vscode/settings.json和根目录下的jsconfig.json，前者控制编辑器行为（如缩进），后者影响语言功能（如路径别名解析），二者不互斥但作用域不同 - 敏感配置（如
"git.enableSmartCommit"）建议只放工作区，避免误开在个人项目里提交了不该提交的代码
settings.json 里常见参数的实际效果差异
很多参数看起来相似，但行为差别很大。比如 "editor.formatOnSave" 和 "editor.codeActionsOnSave" 都发生在保存时，但前者只调用格式化器（如 Prettier），后者可触发修复（如 ESLint 的 source.fixAll.eslint）。
-
"files.exclude"影响资源管理器显示，但不影响搜索（Ctrl+P）或跳转；要全局隐藏搜索结果，得配"search.exclude" -
"emeraldwalk.runonsave"是插件配置，不属于 VS Code 原生设置，必须确认插件已启用且版本兼容，否则字段会被静默忽略 -
"typescript.preferences.includePackageJsonAutoImports"这类带typescript.前缀的设置，只对 TS/JS 文件生效，即使你把它写在用户 settings.json 里，打开 python 文件也不会起作用
同步设置时哪些内容不会跨设备迁移
VS Code 账户同步默认只传用户设置（settings.json）、快捷键、片段和已安装扩展列表，但以下内容从不同步：
-
.vscode/settings.json—— 工作区设置永远本地化，这是设计使然，不是 bug -
.vscode/tasks.json和.vscode/launch.json—— 涉及本地路径、端口、环境变量，同步反而危险 - 扩展的本地状态（如 GitLens 的最近仓库记录、TODO Tree 的缓存）—— 这些存在
GlobalStorage目录里，不走同步通道
真正容易被忽略的是：当你用 github Codespaces 或 Dev Container 时，.vscode/settings.json 会被加载，但用户设置里的 "terminal.integrated.defaultProfile.linux" 这类 OS 特定配置会失效——容器环境识别的是容器内的 OS，不是你本地的。