小张刚接手公司一个老项目，打开 VS Code 写代码时发现缩进突然变成 4 个空格，而他习惯用 2 个；同事发来的 JSON 文件报红，可明明语法没错——后来才发现，是工作区里 .editorconfig 文件把 tabWidth 锁死在 4，还开了 strict mode。
工作区设置，不是全局设置
很多人一上来就猛点「设置」→「用户设置」，改完后发现：新项目还是不生效。问题出在层级关系上。VS Code 的设置分三层：用户级（全局）、工作区级（当前文件夹）、文件级（单个文件）。真正管用的，往往是工作区设置——它只对当前项目生效，互不干扰。
怎么加？两种常用方式
第一种：直接在 VS Code 里操作。打开项目根目录 → 按 Ctrl+,（Win）或 Cmd+,（Mac）打开设置 → 右上角点「工作区」标签 → 搜索「tabSize」，点右边铅笔图标，选「在 settings.json 中编辑」。这时会自动生成 .vscode/settings.json 文件，内容类似：
{
"editor.tabSize": 2,
"editor.insertSpaces": true,
"files.trimTrailingWhitespace": true
}第二种：手动建文件。在项目根目录下新建 .vscode 文件夹，再在里面建 settings.json，粘贴上面那段就行。这样提交到 Git 时，团队成员一拉代码，编辑器行为就自动对齐了。
哪些设置适合放工作区？
语言相关规则最典型。比如前端项目要开 ESLint 自动修复，后端 Python 项目要配 Pylint 和 autopep8，这些都不该污染个人全局设置。再比如：
• React 项目默认启用 JSX 语法高亮和 Emmet 支持
• Markdown 文档目录需要开启预览自动刷新
• 某些老旧 Java 项目必须用 JDK 8 编译，就得在工作区指定 "java.configuration.runtimes"
还有容易被忽略的「排除项」。比如 "files.exclude": {"**/node_modules": true}，放在工作区里，既加快文件搜索，又避免误删依赖。
小心 .editorconfig 和 settings.json 的冲突
如果项目里同时有 .editorconfig 和 .vscode/settings.json，VS Code 默认优先读 .editorconfig（尤其涉及缩进、换行符这类基础格式）。想绕过它？在 settings.json 里加一行："editor.formatOnSave": false，或者干脆关掉 EditorConfig 扩展——但更推荐留着它，毕竟这是跨编辑器通用规范。
老王带实习生时总说：“别怕配，配错了删掉重来就行。关键是让编辑器听你的，不是你迁就它。” 配好一次工作区设置，下次打开项目，光标自动跳转、保存即格式化、错误实时标红——这才是办公该有的顺手劲儿。