背景
在产线环境里，插件包问题很少是“只坏一个包”这么简单。更常见的情况是：底层公共包版本不兼容，表面上看是 A 包报错，实际会连带一串上层工具包都不可用。OpenTAP 在 Package 模块里并没有只做一层依赖检查，而是把“直接损坏”和“被牵连损坏”分开建模，这让排障时能快速区分根因与影响面。
框架分析
这套逻辑主要在 Package/DependencyAnalyzer.cs。核心思路是三步：
- 先构建
packagesLookup（按包名索引）与dependers（反向依赖图）。 - 第一轮遍历只判定“直接损坏”：依赖缺失，或版本不满足
VersionSpecifier.IsCompatible(...)，当前包就加入broken_packages。 - 第二轮做级联扩散：把已损坏包压栈，沿
dependers向上游传播，直到没有新增节点。
因此 BrokenPackages 表示的是“最终不可用集合”，不是单点检测结果。GetIssues() 再把具体问题分类为 Missing、IncompatibleVersion、DependencyMissing，用于输出更可读的诊断信息。
实现过程
复现这段机制很直接，先在源码里定位关键符号：
1 | cd /home/ops/clawd/repos/opentap |
阅读时重点看两个循环：
- 建图循环：处理每个
package.Dependencies，补齐缺失包占位（Version = null），并登记反向边dependers[loaded].Add(package)。 - 扩散循环：
newBroken栈持续弹出损坏节点，把所有依赖它的包也标记为损坏。
这其实是一个在反向依赖图上的可达性传播。工程价值在于：你不用逐层手算“谁会被牵连”，框架会给出完整影响范围。
注意事项
第一，BuildAnalyzerContext 内部用包名去重（同名取首个），如果仓库里并存多版本同名包，分析结果会偏向当前选择版本。第二，Missing 与 DependencyMissing 要分开看：前者更接近根因，后者通常是连带影响。第三，自动修复脚本应优先处理底层缺失/版本冲突，再重跑分析，不要直接对上层报错包做“头痛医头”式升级。
小结
DependencyAnalyzer 的价值不在“判断某个依赖是否兼容”，而在把依赖故障从点扩展成图：先识别根因，再量化波及范围。对持续集成和批量升级场景，这种级联判定能显著降低误判与重复修复成本。
关键源码路径：
Package/DependencyAnalyzer.csPackage/DependencyChecker.csPackage/PackageSpecifier.csPackage/VersionSpecifier.cs