ESLint + Prettier + Better Comments 是当前最轻量、最有效、最无痛的 JS 项目可读性提升组合，无需配置即可开箱即用：ESLint 提前暴露语义隐患，Prettier 统一格式避免视觉干扰，Better Comments 通过符号前缀为注释分层染色。
直接说结论：ESLint + Prettier + Better Comments 是当前最轻量、最有效、最无痛的 JS 项目可读性提升组合，不需要写一行配置就能开箱即用。
ESLint 检查语义错误，不是只报错
很多人装了 ESLint 却只看到红色波浪线，就以为它只是“挑刺工具”。其实它的核心价值在于提前暴露 undefined 变量、no-unused-vars、no-shadow 这类影响可读性的逻辑隐患——比如函数内重名参数遮蔽外层变量，肉眼难辨，但 ESLint 一眼标出。
- 必须启用
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }，否则修复要手动点灯泡 - 不建议直接用
eslint:recommended，它默认禁用no-console，而调试残留的console.log是团队代码里最常见的可读性污染源 - 如果项目已有
.eslintrc.js，优先保留；没有就新建一个，内容只需三行：module.exports = { extends: ["eslint:recommended"], rules: { "no-console": "warn" } };
Prettier 统一格式，避免“谁改的缩进”争论
可读性差往往不是逻辑问题，而是视觉干扰：有人用双引号，有人用单引号；有人每行 80 字符换行，有人硬塞到一行；括号换行位置五花八门。Prettier 不让你选，直接定死规则。
- 关键配置项只有三个：
"prettier.singleQuote"（推荐true）、"prettier.semi"（推荐false）、"prettier.printWidth"（推荐100） - 务必关掉 VS Code 自带的
"editor.formatOnType"，否则打字中途自动格式化会打断思路 - 和 ESLint 共存时，必须安装
eslint-config-prettier，否则两者对分号、空格等规则会打架，导致保存后反复来回格式化
Better Comments 让注释真正“说话”
普通 // 注释全灰，扫一眼根本分不清是临时 TODO、待确认疑问，还是关键说明。Better Comments 用符号前缀自动染色：! 标红（紧急问题）、? 标蓝（需要澄清）、* 标绿（重点说明），视觉上立刻分层。
- 不用改任何代码，装完插件立刻生效，支持所有 JS/TS 文件
- 别用
// TODO:，直接写// !TODO: 接口超时未加兜底，颜色+符号双重提示 - 注意：它不解析注释内容，只靠开头符号识别，所以
// !和//!效果一样，但// !（带空格）更易读、更稳定
真正容易被忽略的是注释与代码的耦合度——很多团队把 // ! 当成装饰，结果注释过期、代码已改，反而误导阅读者。可读性最终靠人维护，工具只是帮你看得更清楚、改得更及时。
