超级管理员
楼主
重复代码是最容易被忽视的技术债。它不会让程序报错，但会让每一次修改的成本变高。jscpd 是个可以做自动化检测的工具，聊聊怎么真正用起来。
为什么要在 CI 里做 靠 code review 抓重复是不现实的。reviewer 看的是当前 diff，而重复往往跨越文件、跨越时间——三个月前写的 A 模块和今天写的 B 模块有 60% 一样，评审时没人会发现。
自动化的价值在于它有一个全量视角，且不会因为赶进度而放水。
落地第一步：先摸底，别直接卡门禁 第一次在老项目上跑 jscpd，报告大概率很难看。这时候直接设阈值会让 CI 一片红，团队会想办法绕过它——比如把阈值调到形同虚设，或者直接关掉。
正确做法：
- 先跑一次全量，记录当前的重复率作为基线。
- 把门禁阈值设成「基线值 + 一点点余量」，保证新增代码不恶化。
- 每个迭代把阈值往下压一点，用几个月慢慢收敛。
几个配置上的坑
- 忽略目录要设全。node_modules、dist、build、生成的代码、第三方 vendor 目录，这些必须排除，否则报告全是噪音。
- 最小 token 数要调。默认阈值对某些语言偏敏感，会报出一堆「这只是长得像，其实不是重复」的误报。建议从默认值开始，看一周报告再调。
- 测试代码单独算。测试里本来就有大量相似结构，混在一起会污染主代码的指标。
- 格式化后再比对。缩进和换行差异会让本该识别的重复漏掉。
报告出来了怎么办 不是所有重复都要消除。判断标准很简单：
该消除的：业务规则重复。同一段校验逻辑在两个地方各写一遍，改需求时只改了一处，这就是未来的 bug。
可以留着的：数据结构相似但语义不同。两个 DTO 字段长得像不代表它们该合并，强行抽象反而增加耦合。
一条经验 「三次法则」比任何工具都好用——同一段逻辑出现第三次的时候再抽象。前两次重复的成本，通常低于一次错误抽象的成本。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。