CodeMirror Duplicate Finder 扫出重复块点击无反应，主因是.gitignore或files.exclude排除了目录、文件编码非UTF-8（如带BOM）、未启用duplicate-finder.includeStrings:true导致模板字符串/JSX内重复被跳过。
CodeMirror Duplicate Finder 扫出来的重复块点不动？先看这三处配置
插件扫出重复但点击无反应，大概率不是插件坏了，而是项目结构或配置拦住了扫描路径。常见卡点有：
-
.gitignore或files.exclude里排除了待查目录（比如"src/utils/**"被忽略，那再准也扫不到） - 文件编码不是 UTF-8（尤其 Windows 上带 BOM 的文件，部分插件解析失败，报
Invalid character但不提示） - 重复代码被包裹在模板字符串、JSX 或注释里——该插件默认跳过这些内容，如需检查，得手动启用
duplicate-finder.includeStrings: true
为什么右键 Find Duplicates in Workspace 没反应？检查 workspace 是否加载完整
VSCode 的“工作区”概念容易被忽略：如果你只是打开了单个文件夹，而不是通过 File → Add Folder to Workspace 加入的多根工作区，插件可能只扫描当前打开的文件夹，漏掉子模块或工具库目录。
实操建议：
- 确认左下角状态栏显示的是
Workspace而非FOLDER - 如果项目含 monorepo 结构（如
packages/下多个子包），必须把整个仓库根目录作为 workspace 加载，否则Find Duplicates in Workspace实际只扫当前打开的那个 package - 插件不会主动 reload，改完
.gitignore或新增目录后，要手动右键触发一次扫描
侧边栏分组列表里一堆“相似度 76%”，怎么快速判断哪几处真该合并？
相似度数字只是辅助，不能直接决定是否合并。真正要关注的是上下文语义和演化风险：
- 两处重复分别在
src/user/和src/order/下？先别急着抽函数——它们未来很可能因业务差异各自加字段、改校验逻辑，强行合并反而增加耦合 - 重复块里含硬编码值（如超时时间
timeout: 5000、API 路径/v1/users）？这类“看似重复实则有意为之”的变体，合并前得先确认是否真共享同一契约 - 插件标出的“重复”里，有一处多了一行
if (!data) return;或日志？这种差一行的变体，插件无法识别，但人工一眼能看出是否属于防御性补丁——别删，要留
Ctrl+Shift+F 搜关键词 + diffchecker.com 是比插件更稳的兜底方案
当插件对“变体重复”失效时（比如一个用 axios.post，另一个用 fetch；一个参数叫 payload，另一个叫 data），靠关键词搜索 + 人工比对反而更快：
- 用
Ctrl+Shift+F搜共性标识符，如localStorage.setItem、catch (err)、handleError - 把搜索结果中疑似重复的 2–3 段代码，复制进 diffchecker.com 快速比对结构
- 注意关掉 diff 工具的“忽略空格”选项——缩进差异有时恰恰暴露了逻辑分支变化
工具永远只负责缩小范围，最终判断哪段该合并、哪段该保留差异，得你盯着业务逻辑看。尤其当重复出现在不同领域边界时，合并前多问一句：它们真的会走同一条演化路径吗？
