问题——不少存量项目中，TSLint、ESLint 与 Prettier并行使用，规则来源不同、优先级不明确；开发者保存文件后经常遇到“格式被改回去”：编辑器先按一套规则调整缩进与引号——随后另一套工具又重新排版——导致无意义的代码差异频繁出现，评审噪音增加，甚至拖慢发布节奏。也有团队反馈告警长期居高不下，新成员难以判断“该以谁为准”，项目越大协作成本越高。 原因——从机制上看，ESLint与Prettier的职责边界不同。ESLint解析代码结构，侧重变量使用、可达性、潜错误等语义层面的规则检查与提示；Prettier关注排版输出，通常把源码抽象成语法结构后再“重新打印”，统一行宽、换行、分号等格式细节。若两者在缩进、引号、换行位置等同一事项上同时生效，又缺少明确的配置顺序或保存动作约束，就容易相互覆盖、反复改写。老项目中工具链叠加、规则继承混乱，是冲突频发的直接原因。 影响——工具冲突看似是体验问题，最终会转化为质量与管理成本：一是版本库出现大量与业务无关的格式差异，影响评审效率和问题定位；二是CI检查结果不稳定，本地与流水线结论不一致，削弱团队对规范体系的信任；三是新人接手门槛升高，时间消耗在风格争论与重复修复上，挤占功能迭代与性能优化空间。对高频交付团队来说，这类低价值消耗会持续拉低研发效能。 对策——较普遍的治理思路是“职责清晰、单点权威、自动化落地”。核心做法包括：第一，减少工具重叠，从多套校验体系收敛为以ESLint为主的统一入口。需要兼容旧规则的项目，可将原有规则逐步迁移并纳入ESLint生态，保证过渡期也有明确标准。第二，明确格式化由Prettier统一输出，同时在ESLint配置中引入兼容方案，关闭与格式有关的冲突项，并确保相关扩展配置在加载顺序上优先生效，避免反复覆盖。第三，限定自动修复边界，将编辑器保存时的自动修复控制在ESLint可管理范围内，并明确不改写第三方依赖或外部代码，减少不可预期的差异。第四，将关键配置文件纳入版本管理，在持续集成中固化“格式化+校验”流程，让每次提交都按同一标准被检查，从机制上避免“各自为政”。 同时，针对老项目“存量告警多、收敛慢”的情况，团队通常分阶段处理：先用自动修复解决低风险、机械性问题，如分号、引号、空行等；对未使用变量、潜在逻辑问题等需要人工判断的告警，则分批清理、逐步归零。通过“先降噪、再提质”，告警数量往往在几轮迭代后明显下降，为后续规则升级与质量门禁打下基础。 前景——随着前端工程化与多仓协作推进，代码规范正从个人习惯转向组织能力。一上，统一的格式化输出能减少风格分歧，让讨论回到架构与业务正确性；另一方面，将语义校验前置到开发与提交阶段，有助于更早拦截缺陷，降低线上风险。业内人士认为，未来的规范体系会更强调可扩展、可治理：在统一基线下，允许按业务域引入定制规则与例外清单，并通过自动化持续验证，实现“统一但不僵化、约束且可演进”。
代码规范工具用得合理，关键在于明确分工并形成稳定的协作方式。通过合适的工具组合和清晰的职责划分，原本会拖慢效率的冲突反而能转化为协作增益。这也说明——面对复杂的技术选型——与其堆叠更多工具和更复杂的配置，不如理解每个工具的核心能力，找到它们的最佳配合方式。当工具各司其职、相互衔接，开发效率与代码质量的提升就能持续落地。