CodeMirror Duplicate Finder 默认不扫描 Monorepo 中未显式暴露的 workspace 子包，因其仅识别 VSCode 工作区可见文件；需打开 monorepo 根目录、确保子包源码在资源管理器中可见、检查 .gitignore 和 files.exclude 配置，并理解其纯文本比对机制不支持跨语义重复识别。
CodeMirror Duplicate Finder 在 Monorepo 中默认扫不到重复？
不是插件失效，而是它默认跳过 node_modules、被 .gitignore 排除的目录，以及所有未显式包含的 workspace 子包。LoopBack 4 或 pnpm monorepo 里常见的 packages/**、extensions/** 若没在 VSCode 工作区根目录下直接打开（而是只开了子包文件夹），插件根本不会扫描它们。
必须确保：
- 工作区是整个 monorepo 根目录（即打开的是含 pnpm-workspace.yaml 或 lerna.json 的文件夹）
- .gitignore 里没有把 packages/*/src 这类路径排除掉
- VSCode 设置中关闭了 files.exclude 对相关子包的隐藏（比如 "**/packages/utils/**": true）
怎么让 Duplicate Finder 真正覆盖所有 workspace 子包？
插件本身不识别 pnpm/npm workspace 结构，靠的是文件系统可见性。它只扫描当前工作区里“能被 VSCode 列出来的文件”。所以关键不是改插件配置，而是让子包源码对编辑器可见：
- 用 VSCode 打开 monorepo 根目录，而不是某个
packages/xxx子目录 - 确认
packages/*/src/**/*.ts文件在资源管理器里是展开可点的（不是灰色禁用状态） - 如果用了
files.exclude隐藏了部分子包，临时注释掉相关行，或改用更精确的 glob，例如："**/packages/*/dist/**"（只排除构建产物，不拦源码） - 检查
settings.json是否有"search.useIgnoreFiles": false—— 设为true（默认）才能尊重.gitignore，但若你故意想扫被 ignore 的目录，就得关掉它
为什么在 packages/api 和 packages/db 里看到相同逻辑，Duplicate Finder 却不标？
因为它的相似度计算基于纯文本结构，不跨语义归一化。哪怕两段代码都做「数据库连接失败重试」，只要一处写 for (let i = 0; i ，另一处用 <code>Array.from({ length: 3 }).forEach()，相似度就掉到阈值以下。
这时得手动调两个参数：
- 把 duplicate-finder.minLines 改成 4 或 5（小钩子、错误处理块常就 4–6 行）
- 把 duplicate-finder.similarityThreshold 降到 70（变量名、空格、注释位置稍一变，85 就太苛刻）
- 开启 duplicate-finder.includeStrings：否则模板字符串里的重复日志、SQL 拼接全被跳过
查到了重复，但两处分别在 packages/core 和 packages/cli，能直接合并吗？
不能只看工具结果。Monorepo 里跨包重复往往藏着架构隐患——比如两处都手写了 JWT 解析，但 packages/core 未来要加 RBAC，packages/cli 只需简单鉴权。强行抽成公共函数，反而会让 CLI 包多带一堆用不到的依赖。
更务实的做法：
- 先用 Ctrl+Shift+F 搜共性关键词（如 jwt.verify、decodeToken）定位所有疑似点
- 把两段代码复制进 diffchecker.com，看差异是否真只是变量名或超时时间
- 如果差异涉及业务规则（比如一处校验 user.role === 'admin'，另一处是 user.permissions.includes('write')），说明它们本就该独立演化
- 合并前，在 PR 描述里明确写出：契约不变（输入/输出/错误码）、调用方无感知、已跑通两边对应测试
真正容易被忽略的是：Duplicate Finder 从不告诉你「这段重复该不该留」。它只回答「哪里长得像」；而决定「像≠该删」，得你站在模块边界和未来迭代节奏上判断。
