VSCode 工作区设置和用户设置，不要互相抢活

VSCode 真正用顺以后，很多人都会开始调设置。问题也从这里开始：个人用户设置越积越多，项目工作区设置也越来越重，到了某个节点，大家会发现格式化、补全、保存动作、插件行为全在互相覆盖，谁说了算都不清楚。

我后来最在意的一点不是“设置写在哪”，而是“这条设置到底该由谁负责”。

用户设置更适合承载个人体验

像主题、字体、界面布局、标签宽度、最小地图开关这类东西，本质上都是个人工作台体验。
它们影响我怎么看代码，不太影响团队最终交付的结果。

这类设置如果被项目强行接管，往往会引发不必要的摩擦。

工作区设置应该更靠近团队共识

一旦某条配置会影响代码结果，或者会让团队成员之间的文件差异变多，我就更倾向放到工作区里。
比如：

• 默认格式化器
• 保存时是否自动修复 lint
• 某种语言的缩进和换行习惯
• 项目特定的路径提示或任务入口

这些东西如果只活在个人配置里，团队其实很难真正形成一致。

真正危险的是两层都在做同一件事

最糟糕的状态不是设置少，而是用户设置和工作区设置都在控制同一类行为。
这时候问题会变得很微妙：

• 你这里能保存自动格式化，我那里不行
• 你这里 import 顺序稳定，我那里每次都改
• 某个插件在一个项目里好好的，换个仓库就像失灵

这些看上去像工具脾气，实质上很多时候只是职责边界没分开。

我现在更喜欢的分法

一句话概括就是：

• 影响“我怎么用编辑器”的，放用户设置
• 影响“项目代码会长成什么样”的，放工作区设置

这条分法不花哨，但执行久了之后，整个团队会轻松很多。

小结

VSCode 的配置能力越强，就越需要一点节制。
我现在不太追求把所有偏好都调到极致，反而更在乎每条设置归属是不是清楚。工作区设置和用户设置别互相抢活，编辑器才能真正稳定下来。