百度快照时间：旧项目里残留的依赖怎么查才不返工
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8abf2122788f.html
📄
百度快照时间：旧项目里残留的依赖怎么查才不返工
把“百度快照时间”当成一个历史线索来用：它记录的是搜索引擎某次抓取并缓存页面的时刻，不是项目里某个依赖的安装时间。要检查旧项目的残留依赖，正确做法是先用锁文件、清单文件和实际运行结果三路交叉比对，再决定删、留还是替换。这样多人协作时才能把结论写进交付说明，减少下一轮返工。
先分清三种“时间”，别拿快照时间当依据
旧项目里能看到的“时间”至少有三类，混用会直接导致误判：
- 百度快照时间：百度抓取并缓存该页面的时刻，只能说明搜索引擎在某个时点见过这个页面，不能说明页面里提到的依赖是否还在用。
- 文件系统时间：文件被创建或最后修改的时间，可能因为复制、打包、Git 检出而被整体刷新。
- 依赖解析时间：锁文件里记录的版本解析结果，反映的是某次安装时实际拉到的版本组合。
判断残留依赖时，只有第三类加上实际运行结果能作为删除依据。快照时间最多帮你判断“这个页面大概多久没被更新过”，属于旁证，不是证据。
三路交叉比对：清单、锁文件、运行结果
把下面三项结果列成一张表，逐条对：
- 清单文件：
package.json、requirements.txt、pom.xml等声明的直接依赖。 - 锁文件：
package-lock.json、poetry.lock、go.sum等记录的实际解析版本，注意其中大量是间接依赖。 - 实际引用：在源码、构建脚本、配置文件、CI 配置里搜索包名，确认是否还有 import、require 或调用。
三路一致且都有引用，属于在用；只在锁文件里出现、清单和源码都搜不到，多半是间接依赖或历史遗留；清单里有、源码搜不到，需要进一步确认是否被动态加载或通过插件机制调用。
一个可以照做的检查步骤
假设一个旧项目要交接，需要判断 old-chart-lib 是否还能删。可以这样走：
- 在清单文件里搜索该包名，记录它声明的版本范围。
- 在锁文件里搜索，记录实际锁定的版本；如果锁文件里没有，说明它可能从未真正安装成功过。
- 在源码目录搜索包名和常见引入写法，例如
import old-chart-lib、require('old-chart-lib')。 - 搜索构建脚本、打包配置、CI 配置，排除只在构建阶段使用的可能。
- 在本地或测试环境移除该依赖后重新安装并运行测试；如果测试通过且构建产物无差异，可以标记为“可移除候选”。
第 5 步是关键，也是最花时间的一步。它把“看起来没人用”变成“移除后确实没坏”，代价是需要一个能跑起来的测试环境。如果项目没有测试，就先做构建验证，并在交付说明里写明“仅通过构建验证，未覆盖运行时路径”，让接手的人知道风险边界。
什么情况下可以放心删，什么情况下必须留
可以优先删除的情况：清单、锁文件、源码、构建脚本四处都搜不到，且移除后构建和测试均通过。需要保留的情况：被动态加载、被反射调用、被外部插件按名字引用，或者只在特定环境变量下启用。这类依赖静态搜索往往搜不到，判断方法是查文档、查运行时日志，或者临时加一条加载失败告警观察一段时间。
如果团队里有人坚持“先留着，反正不影响”，代价是每次安装变慢、安全扫描噪音变多、新人理解成本上升。如果坚持“先删了再说”，代价是可能在生产环境才暴露问题。折中做法是：先标记为待移除，写进交付清单，约定下一个迭代验证后再删。
把结论写进交付说明
检查完成后，至少记录三项：依赖名称与版本、判断依据（搜了哪些位置、跑了什么验证）、结论与遗留风险。这样下一轮协作的人不需要重新走一遍同样的搜索。百度快照时间这类历史线索可以附在备注里，说明该页面大约多久没更新，但它不进入删除依据。
下一步：挑一个当前最不确定的依赖，按上面的五步走一遍，把结果填进交付说明，再决定删或留。
