VSCode本身不检测代码重复，所谓“重复检测慢”实为扩展（如Duplicate Code Detector、ESLint等）后台扫描策略不当所致；根本原因在于未排除node_modules等无关目录、未限定文件类型与校验范围，导致冗余AST解析和环境加载。
VSCode 本身不检测代码重复，所谓“重复检测慢”，实际是某扩展（如 Duplicate Code Detector、CodeMetrics 或 ESLint + eslint-plugin-detect-unused-vars 等）在后台扫描时卡住——问题不在 VSCode，而在扫描策略、文件范围和语言服务配置。
为什么 Duplicate Code Detector 扫描一卡就是十几秒？
该插件默认对整个工作区递归分析 AST，遇到 node_modules、dist、build 等目录会逐个解析 JS/TS 文件，哪怕只是跳过内容，也会触发语法树构建和内存分配。尤其当项目含大量生成代码（如 protobuf、Swagger client）时，单文件解析耗时可超 800ms。
- 必须在工作区级
.vscode/settings.json中配"files.exclude"和"search.exclude"，仅排除还不够，要让插件根本“看不见”这些路径 - 禁用对非源码文件的扫描：
"duplicate-code-detector.includeGlobs": ["**/*.ts", "**/*.js", "**/*.py"]，别让它碰.d.ts、.min.js、.test.js - 若用 TypeScript，确认
typescript.preferences.includePackageJsonAutoImports为"auto"而非"on"，否则每次扫描都会同步加载node_modules类型定义
ESLint 检测重复逻辑（如 no-duplicate-case）响应延迟
不是规则本身慢，而是 ESLint 扩展在未限定校验范围时，默认监听所有 **/*.{js,ts,jsx,tsx} 文件，并在保存时全量重跑。中大型项目下，一次 lint 可能触发 300+ 文件解析。
- 在
settings.json中显式限制校验范围："eslint.validate": ["javascript", "typescript"]，去掉"javascriptreact"等非必要类型 - 关闭自动修复干扰：
"eslint.run": "onType"改为"onSave"，避免边写边扫拖慢输入 - 确保项目根目录有
.eslintignore，内容至少包含：node_modules/**、dist/**、build/**、coverage/** - 若用 Prettier 配合 ESLint，禁用
prettier/prettier规则的 auto-fix，它会在保存时反复格式化再 lint，形成循环
Python 项目用 vulture / radon 检测重复/冗余代码卡顿
这类工具本身是命令行程序，VSCode 通常通过终端或 tasks.json 调用。慢点往往出在环境启动：每次调用都激活虚拟环境、加载 site-packages、解析 pyproject.toml。
- 不要用
python -m vulture .全局扫描；改用精准路径：python -m vulture src/ --min-confidence 80 - 在
tasks.json中加"isBackground": true和"problemMatcher"，避免阻塞编辑器主线程 - 禁用 Python 扩展的自动环境探测：
"python.defaultInterpreterPath"设为绝对路径（如/path/to/venv/bin/python），跳过findPython同步查找 - 若用
radon cc，加-s（short output）参数，避免生成冗长报告文本塞满输出面板
真正影响重复检测速度的，从来不是算法复杂度，而是你有没有让工具只看该看的文件、只走必要的环境路径、只触发一次而非反复重载。漏掉任何一个 exclude 或路径约束，就可能多扫几百个无意义文件——这种开销，比算法优化重要十倍。
