alexa查询 - 检查旧项目残留依赖的优先级
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /265780a5e963.html
📄
alexa查询 - 检查旧项目残留依赖的优先级
先处理“会让项目跑不起来或悄悄算错”的残留依赖，再清理“只影响体积和整洁度”的部分。判断顺序可以按三条线走：构建是否报错、运行是否走错分支、上线产物是否仍引用旧服务。时间人手有限时，先做一次可重复的依赖清单核对，再决定删、换还是留。
先分清哪些残留会真正影响结果
旧项目里的残留依赖，常见有三类。第一类是包管理器清单里还留着旧包名，安装时可能被间接拉回来。第二类是代码里还写着旧接口、旧域名或旧统计脚本，构建不报错，但运行时会请求已经不存在或不该再用的地址。第三类是配置和文档里还写着旧值，人照着做就会走错路。前两类优先，第三类可以随后补。
判断依据不是“名字看起来旧”，而是看它是否进入构建链、运行链或发布产物。只出现在注释和说明里的旧词，优先级最低。
用依赖清单做第一轮排查
不同语言和包管理器的命令不同，但检查目标一致：看直接依赖、传递依赖和锁文件是否一致。以 Node 项目为例，可以执行：
npm ls --depth=0
它列出顶层依赖，适合快速看有没有明显不该出现的包。再看锁文件里是否仍有旧包：
grep -i "旧包名" package-lock.json
如果锁文件命中，但清单里没有，说明它可能被别的包间接依赖。此时不要直接手删锁文件条目，先确认依赖来源，再决定升级、替换还是保留。
Python 项目可以检查 requirements.txt 或 pyproject.toml，Java 项目检查 pom.xml 或 build.gradle。重点看两类信号：一是包名旁边是否还有旧版本范围，二是构建日志里是否出现“已弃用”或“无法解析”的提示。前者是可能原因，后者更接近已经定位的原因。
检查代码和配置里的旧入口
依赖清单干净，不代表项目干净。旧接口地址、旧统计脚本、旧环境变量常藏在源码和配置里。可以按关键词全文搜索，例如：
- 旧服务域名或路径片段
- 旧 SDK 的初始化函数名
- 旧环境变量名，如带
_OLD、_V1的键 - 旧构建脚本里引用的外部命令
搜索命中后逐条判断：如果它在构建阶段执行，优先处理；如果只在运行时某个低频分支执行，可以排后；如果只在文档里出现，最后处理。对每个命中项记录“位置、触发条件、替换方案、验证方式”，避免反复翻同一处。
用构建和运行结果做验收
清理动作做完后，验收信号比“看起来删干净了”更可靠。可以按下面顺序检查：
- 重新安装依赖，确认没有因缺失包而失败。
- 执行一次完整构建，确认没有旧包或旧脚本导致的报错。
- 启动项目，走一遍主流程，确认没有请求旧地址。
- 查看构建产物，确认里面不再包含旧域名或旧脚本片段。
如果第 1 步失败，说明删得过头，需要回退或补替代依赖；如果第 3 步仍发出旧请求，说明代码或配置还有残留；如果第 4 步仍命中旧片段，说明打包配置或缓存没清干净。每种现象都可能有多个解释，不要只凭一个报错就断定唯一原因。
时间和人手有限时的处理顺序
可以按这个顺序安排：先跑依赖清单和锁文件检查，再全文搜索旧入口，然后做一次构建与主流程验证，最后才整理文档和注释。这样做的理由是，前两步能快速暴露高风险项，后两步能确认清理是否真的生效。若项目已经不再维护，只保留可运行状态，那么优先保证构建通过和主流程可用，旧文档可以暂缓。
下一步建议：选一个旧项目，先执行依赖清单命令并保存输出，再对锁文件和源码各做一次关键词搜索，把命中项按“构建链、运行链、文档”分类，然后从构建链开始逐项处理。
