隔离可选能力的加载失败

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

部分安装的工具包仍有源码读取器，却缺少改动文件追踪模块。共享入口若顶层加载追踪器，会使读取器也无法启动；吞掉错误返回空列表又会把不可用误报为没有改动。

具体做法

在追踪能力的调用或隔离初始化边界加载可选模块，让无关读取器正常注册。失败返回明确的tracker-unavailable及修复说明，不返回no-changes；诊断日志自身失败也应被隔离。清除失败的加载缓存，让修复后的新调用可重试，成功缓存则按实际加载器契约使用。对并发加载和重试做运行检查。

反例

工具入口顶层import追踪器。模块缺失时全部工具加载失败；若捕获错误就返回空改动列表，告诉用户没有变更。

改进写法

源码读取器独立加载。在changed-files边界加载可选追踪器；缺失时返回tracker-unavailable并说明该功能无法判断改动。隔离日志失败并清除拒绝的加载promise，修复后按加载器支持的方式重新尝试。测试真实调用，不能仅凭注册成功说功能可用。

为什么这样改

故障边界与能力边界一致，才能保护无关功能。明确不可用与有效空结果的区别，保留失败信息；重试策略还防止一次失败缓存永久锁住修复后的能力。

如何验证

教学夹具移除追踪模块：读取器应可读取样本文件，changed-files明确不可用。让日志同步抛错也不应破坏读取器。恢复模块后进行新加载，应取得预置的changed.txt，而不是继续复用失败promise。

适用边界

只有可选能力可如此降级；必需授权、校验或完整性依赖不能以空结果绕过。清除应用promise不保证运行时模块缓存可恢复，可能需要重启或新的加载上下文。修复命令需按可信实际安装环境核查，冻结来源不授予执行授权。