eslint + prettier + better comments 是当前最轻量、最有效、最无痛的 js/ts 项目可读性提升组合，无需配置即可开箱即用；eslint 暴露语义模糊点，prettier 专注格式统一，better comments 通过符号识别强化注释可读性。
直接说结论：ESLint + Prettier + Better Comments 是当前最轻量、最有效、最无痛的 JS/TS 项目可读性提升组合，不需要写一行配置就能开箱即用。
为什么 ESLint 不只是报红波浪线
很多人看到 no-unused-vars 或 no-shadow 报错就关掉规则，其实这些恰恰是可读性杀手。比如函数参数名和外层变量同名，肉眼难辨作用域；又比如声明了 tempData 却没用，后续阅读者会下意识猜测“它是不是漏写了调用”。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 和 ESLint 共存时最常踩的坑
两者规则打架会导致保存后代码反复跳动：分号一会儿加一会儿删，空格一会儿多一会儿少。这不是插件问题，而是配置缺失。
实操建议：
- 必须安装
eslint-config-prettier，它会关闭 ESLint 中所有与格式相关的规则，让 Prettier 全权负责 - VS Code 设置里务必关掉
editor.formatOnType，否则打字中途自动格式化会打断思路 - 关键 Prettier 配置只设三项：
prettier.singleQuote（推荐true）、prettier.semi（推荐false）、prettier.printWidth（推荐100）
Better Comments 注释染色不生效？检查这三点
装完插件发现注释还是全灰，大概率是符号识别失败。它不解析内容，只靠开头字符匹配，对空格和位置很敏感。
实操建议：
- 别写
// TODO:，改用// !TODO:或// ?Why:，开头必须是!、?、*等支持符号 -
// !和//!效果一样，但// !（带空格）更稳定，避免被误判为注释内容的一部分 - 真正容易被忽略的是注释与代码的耦合度——很多
// !注释写完就没再更新，等函数逻辑变了，注释反而误导人
复杂点在于：可读性不是靠堆插件实现的，而是靠规则之间不互相干扰、提示信息不自相矛盾、以及注释始终随代码演进。一旦某条规则开始让人“习惯性右键忽略”，它就已经在损害可读性了。
