VSCode 保存时自动 ESLint：我如何把代码风格变成低摩擦习惯
我以前写这篇文章，是为了记录一个很实用的 VSCode 配置：保存文件时自动按 ESLint 规则修复代码。
现在回头看，这个配置本身很简单。
但它背后的价值不只是“格式化更快”，而是把代码风格、低级错误和提交前清理前移到日常编辑动作里。
我越来越觉得，好的工程习惯不是靠意志力维持的。
它应该尽量低摩擦。
保存文件就是一个天然的触发点。
我为什么需要保存自动修复
在一个 JavaScript 或 NodeJS 项目里，代码风格问题很容易分散注意力。
少一个分号、缩进不一致、未使用变量、引号风格不同，这些问题都不复杂。
但它们会反复出现在 review、提交检查和协作沟通里。
我不希望每次写完功能以后，还要专门抽一段时间去想“格式有没有统一”。
这种事情应该交给工具。
我更愿意把自己的注意力留给业务逻辑、状态边界、异常处理和真实用户流程。
我的基本配置思路
我会先确认项目里已经有 ESLint 配置。
这通常意味着项目里存在类似文件：
.eslintrc
.eslintrc.js
.eslintrc.json
eslint.config.js
package.json里的 ESLint 配置
然后在 VSCode 里安装 ESLint 插件。
接着，我会在项目或用户设置里加入保存时修复规则。
旧项目里常见写法是：
不同 VSCode 和 ESLint 插件版本可能会调整推荐配置值。
所以我现在不会只复制旧配置，而是会按项目当前版本确认最终写法。
有些新环境里，保存动作会要求更明确的配置值。
但核心思路没有变：让 ESLint 在保存时处理它能自动处理的问题。
我会把配置放在哪里
如果只是我自己的个人习惯，我会放在 VSCode 用户设置里。
如果这是团队项目，我更倾向放在项目的
.vscode/settings.json 里，并且让团队知道这个配置的影响。我的判断标准是：
- 只影响我个人编辑体验的，放用户设置；
- 影响团队一致性的，放项目设置；
- 和构建、CI、提交检查有关的，写进项目脚本；
- 不能靠编辑器兜底的，放到 lint-staged、CI 或 pre-commit 流程里。
保存自动修复不是质量保障的全部。
它只是把最轻的一层提前处理掉。
我会如何处理冲突
前端项目里经常同时出现 ESLint、Prettier、TypeScript、框架插件。
如果保存时不断出现来回改格式，我会先停下来检查规则边界：
- ESLint 是否同时负责格式和代码质量；
- Prettier 是否已经接管格式；
- VSCode 默认 formatter 是谁；
- 项目是否启用了多个互相覆盖的插件；
- CI 使用的 lint 命令和本地保存规则是否一致。
我不喜欢让工具互相打架。
工具一旦打架，开发者会失去信任，最后反而关掉所有自动化。
我的目标是让保存这件事安静地工作。
我的配置地图
以后我会按这条路径处理 ESLint 自动修复：
- 先确认项目已有 ESLint 规则。
- 安装或启用 VSCode ESLint 插件。
- 在项目当前版本下确认
editor.codeActionsOnSave的正确写法。
- 检查默认 formatter，避免 ESLint 和 Prettier 冲突。
- 保存一个有 lint 问题的文件做验证。
- 再运行项目的
lint命令，确认编辑器行为和命令行一致。
- 团队项目把必要配置写入仓库，个人偏好留在用户设置。
这比单纯贴一段 settings 更可靠。
这篇旧文现在对我的意义
这篇文章原来是一条 VSCode 小技巧。
现在我更愿意把它看成工程习惯的一部分。
保存自动 ESLint 的价值，不是让我看起来更熟悉工具，而是让我减少无意义的返工。
当低级风格问题在保存时被处理掉，我就能把注意力放回真正需要判断的地方。
我希望自己的开发环境越来越像一条顺手的流水线。
不是复杂，而是稳定。
不是替我思考，而是帮我清掉那些本来就不值得反复思考的事情。
Loading...
