VSCode重复检测卡顿主因是插件全量扫描与AST解析占用资源，关闭或替换为ESLint的no-duplicate-string规则可降内存300–800MB；须配置files.watcherExclude、调整语言服务器并清理缓存。
VSCode 自带的代码重复检测（如 editor.codeActionsOnSave 触发的自动整理、或第三方插件如 duplicate-code-detector）卡顿，本质不是“检测逻辑慢”，而是它在后台持续扫描+解析 AST + 跨文件比对，把内存和 CPU 全占满。关掉它或换轻量方案，通常能立竿见影降下 300–800MB 内存。
为什么 duplicate-code-detector 一开就卡？
这个插件默认启用全项目实时监听，每次保存都会触发完整 AST 构建和字符串指纹比对——尤其在含 node_modules 或大量模板文件的项目里，它会把每个 JS/TS/HTML 文件都加载进内存做 token 化，导致 Extension Host 进程 RSS 常超 600MB。
- 它不尊重
files.watcherExclude，即使你排除了**/node_modules/**，仍可能通过 glob 遍历间接读取 - 不支持增量扫描，每次都是全量重跑，大项目耗时 >15s 是常态
- 没有缓存机制，同一段重复代码在不同文件里被反复计算多次
用 ESLint + no-duplicate-string 替代（零额外内存）
如果你只是想防明显重复字符串或硬编码（比如 API 地址、错误码），no-duplicate-string 规则比专用重复检测插件更轻、更可控，且完全复用已有 ESLint 进程，不新增任何扩展进程。
- 在项目根目录
.eslintrc.cjs中加入："rules": { "no-duplicate-string": ["warn", { "threshold": 3 }] } - 确保
"eslint.run": "onType"（而非onSave），避免保存瞬间卡顿 - 禁用该规则对生成文件的检查：
"eslint.probe": ["javascript", "typescript"]，不包含html或json
必须配的 files.watcherExclude 防泄漏底线
哪怕你不用任何重复检测插件，只要开了 VSCode 默认文件监听，duplicate-code-detector 或类似工具就会被间接唤醒——因为它们依赖文件变更事件触发。所以这组配置不是“可选优化”，是防止内存爬升的强制项：
- 必须写在项目级
.vscode/settings.json（全局设置无效） - 至少包含：
"**/node_modules/**": true、"**/dist/**": true、"**/build/**": true、"**/__pycache__/**": true - Linux 用户还要确认：
cat /proc/sys/fs/inotify/max_user_watches≥524288，否则内核句柄直接耗尽 - 改完后必须关闭并重新打开工作区，旧监听器不会自动卸载
Java/Python 项目要额外清理语言服务器缓存
Java 的 eclipse.jdt.ls 和 Python 的 Pylance 在做语义分析时，会把整个依赖树反序列化进内存；一旦遇到重复代码逻辑（如多个模块 import 同一工具函数），它们会在索引阶段反复加载相同 AST 片段，加剧内存压力。
- Java：清空
~/.m2/repository/.cache并删掉所有*.lastUpdated文件，再重启 VSCode - Python：在
settings.json中设"python.languageServer": "Jedi"（Pylance 太重），并清空~/.cache/jedi/ - 两者都建议加
"java.maxHeapSize": "4G"或"python.defaultInterpreterPath"显式指定解释器，避免自动探测开销
真正卡住你的，往往不是“检测不准”，而是“检测太勤”——多数重复问题靠人工扫一眼就能发现，没必要让编辑器每秒都在内存里建一棵新 AST 树。留一个轻量规则 + 一组硬性排除 + 一次缓存清理，比装十个插件更管用。
