VSCode工作空间配置_独立于全局的项目级参数设置

判断一个设置项能否被覆盖，其实有个很简单的方法。打开VSCode的设置界面（Ctrl+,），搜索你想确认的配置。如果该设置项的右侧显示了「Workspace」图标并且可以编辑，那就说明支持覆盖；如果只有「User」图标且呈灰色不可用状态，那就意味着工作空间对此无能为力。

如何让 ESLint / Prettier 配置真正只作用于当前项目

想让代码检查和格式化工具乖乖听话，只服务于当前项目，光在 .vscode/settings.json 里打开开关是远远不够的。稍有不慎，就会和全局的插件行为产生冲突，导致格式化结果和预期大相径庭。

关键在于配齐三层“保险”：

• 第一层，开关控制：在项目的 .vscode/settings.json 中，明确启用插件，例如 "eslint.enable": true 和 "prettier.enable": true。
• 第二层，规则定义：确保项目根目录下存在对应的配置文件，比如 .eslintrc.cjs（或新版ESLint的 eslint.config.js）以及 .prettierrc。并且，这些配置文件的内容应该是独立、完整的，不能依赖用户主目录下的同名文件。
• 第三层，路径锁定：在 .vscode/settings.json 中加上 "eslint.workingDirectories": ["./"] 这样的配置。这相当于强制ESLint将扫描范围锁定在当前项目根目录，避免它跑到其他项目或全局目录里去寻找规则。

这三环缺一不可，尤其是在多个项目共用同一套插件版本时，漏掉任何一环都可能让团队协作陷入混乱。

工作空间配置与 .gitignore 的协同问题

通常来说，.vscode/settings.json 这类包含个人偏好的文件，默认是不应该提交到Git仓库的，除非里面包含了团队强制要求的统一规范（比如规定必须使用空格缩进："editor.insertSpaces": true）。

但问题来了：很多人为了省事，会直接把整个 .vscode/ 目录都写进 .gitignore。这个做法其实有点“一刀切”了，因为它会误伤 .vscode/tasks.json 或 .vscode/launch.json 这类文件。而这些文件里，往往存放着项目特定的构建任务或调试配置，是开发流程中不可或缺的一部分。

更稳妥、更精确的做法是进行差异化忽略：

• 在项目根的 .gitignore 文件中，可以明确忽略个人设置：.vscode/settings.json
• 但同时，要保留那些对团队协作重要的文件，比如：
  • .vscode/tasks.json（项目构建任务）
  • .vscode/launch.json（调试配置）
  • .vscode/extensions.json（可用于推荐团队统一安装的插件）

否则，当队友拉取代码后，可能会发现连「Start Debugging」按钮都找不到，还得手动重新配置一遍调试环境，这无疑会降低协作效率。