「有些默认设置并不是为大多数程序员优化的。」一位长期使用VS Code的开发者这样总结他的痛点。他花了10分钟调整配置，结果编辑器变得「更快、更平静、更值得信任」。
这不是什么复杂的插件开发，只是修改一个JSON文件。但效果出奇地明显。
正方：自动保存是刚需
按下Ctrl+S（或Cmd+S）已经成为肌肉记忆？这恰恰说明问题。
开发者设置了两行代码：
"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000
停顿1秒后自动保存。听起来微不足道，但改变了编码的「手感」。
他分享了一个真实场景：曾在大型代码库中忘记保存文件，导致新代码在测试中完全失效。他花了大量时间排查问题，最后发现只是文件未保存。「那时我才意识到自动保存有多有用。」
如果需要更多控制，可以换成：
"files.autoSave": "onFocusChange"
切换标签页或离开编辑器时触发保存。适合对时机敏感的脚本或任务。
反方：手动保存是最后的防线
反对者认为，自动保存剥夺了「确认」的心理节点。某些场景下，你可能想先写完一段逻辑再统一保存，避免触发不必要的编译或热重载。
「onFocusChange」模式看似折中，但切屏时意外保存的情况依然存在。
判断：延迟保存是 sweet spot
1000毫秒的延迟设计很聪明——它既消除了频繁按快捷键的机械动作，又保留了短暂的缓冲窗口。对于绝大多数开发场景，「afterDelay」比「onFocusChange」更符合直觉：你停顿思考时，保存自然发生；你快速切换时，不会被打断。
正方：格式化应该零摩擦
格式混乱是「刚好足够烦人，又不足以每次都手动修复」的问题。
一行设置解决：
"editor.formatOnSave": true
保存时自动处理缩进、空格、对齐。开发者特别提到HTML页面的场景：缩进混乱会严重影响可读性，手动修复既耗时又繁琐。
如果使用Prettier（前端开发中广泛使用的代码格式化工具），可以设为默认：
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
「你可以完全停止思考代码风格。」
反方：统一格式化是团队问题，不是个人设置
批评者指出，formatOnSave 的真正风险在于团队协作。如果项目配置了ESLint或Prettier，但团队成员的本地设置不一致，保存时会产生大量无意义的diff，污染代码历史。
更安全的做法是将格式化配置提交到版本控制（如.prettierrc），并通过git hooks强制触发，而非依赖编辑器的保存行为。
判断：个人效率与团队规范的边界
formatOnSave 的价值取决于场景。对于个人项目或已统一配置的团队，它是效率利器；对于配置混乱的遗留项目，可能加剧问题。
关键洞察：这个设置本身不解决「规范是什么」，只解决「执行规范的摩擦」。如果团队已有明确配置，formatOnSave 是最后一公里的优化；如果没有，它只是把混乱自动化了。
正方：横向滚动是注意力杀手
「阅读长行时，内容消失在屏幕外，你不得不来回拖动滚动条拼凑信息。」
解决方案：
"editor.wordWrap": "on"
长行自动换行，无需横向滚动。对JSON、日志、Markdown尤其友好。
反方：换行破坏视觉结构
反对者认为，强制换行会扭曲代码的「形状」，某些语言（如Python）对缩进敏感，换行后逻辑层次变得模糊。此外，对比两个文件时，换行会导致行号错位，增加 diff 阅读难度。
判断：按文件类型启用
折中方案是针对特定语言启用：
"[markdown]": {
"editor.wordWrap": "on"
}
Markdown、纯文本、日志文件开启；代码文件保持默认。既解决阅读痛点，又避免编辑干扰。
正方：文件树需要极简主义
Explorer侧边栏的「开放文件夹」按钮、下载计数、刷新图标——这些元素很少被点击，却持续占据注意力。
隐藏它们：
"workbench.tree.indent": 12,
"workbench.tree.renderIndentGuides": "none",
"explorer.decorations.badges": false,
"explorer.decorations.colors": false
缩进增加、引导线移除、徽章和颜色标记关闭。文件树变得「安静」，只剩文件名和层级关系。
反方：信息密度是有意的设计
徽章显示Git状态、颜色区分修改/新增/删除——这些视觉提示是快速导航的辅助。关闭后，开发者需要更多时间扫描文件名，或频繁切换Git面板确认状态。
判断：减法需要目的
极简主义不是盲目移除，而是识别「真正需要的信息」。如果项目规模小、Git操作频繁，保留徽章更高效；如果文件树主要用于浏览而非状态监控，隐藏干扰元素能显著降低认知负荷。
正方：光标应该指向未来
默认光标样式是细竖线，在复杂代码中容易「丢失」。更明显的视觉锚点：
"editor.cursorStyle": "line-thick",
"editor.cursorBlinking": "smooth"
加粗线条+平滑闪烁。开发者描述：「就像给光标加了聚光灯，再也不用在屏幕上『找』它。」
反方：过度设计分散注意力
加粗光标在密集代码中反而形成视觉噪音，平滑闪烁的动画可能引发部分用户的不适。对于习惯默认样式的用户，任何改变都需要重新适应。
判断：可逆的实验
光标样式是最容易回滚的设置——不满意即删除配置。建议尝试一周：如果频繁意识到光标的存在，说明它太抢眼；如果完全忘记它的存在，说明它恰到好处。
10分钟的投资
这些设置不依赖插件、不增加启动时间、不改变核心工作流。它们只是移除摩擦、减少决策疲劳、让编辑器更「透明」。
开发者最后提到：「好的工具应该让你忘记工具本身。调整VS Code，不是为了让它更强大，而是为了让它更不碍事。」
热门跟贴