在长期运行的自动化系统里，“数据缺失”从来不是一个足够精确的故障描述。
缺少的是哪一项数据？它影响的是全部基础判断，还是只有某一项补充分析？它是否已经过期？如果忽略它，会不会绕过关键安全条件？
这些问题的答案，决定了程序应该继续、局部跳过，还是停止执行。
两种“缺失”，不能采用同一种处理方式
设想一个系统同时依赖：
- 确认当前市场和交易窗口所需的核心信息；
- 判断数据是否新鲜且时间顺序正确的基础检查；
- 某些补充研究判断所需的额外特征。
如果核心市场身份或关键价格数据已经过期，继续交易可能构成严重风险。此时不能简单地“容错继续”，正确做法通常是阻断受影响的执行并提示异常。
但如果缺少的是一项只供某个补充判断使用、且不构成基础安全前提的额外信息，让整个系统无条件停止所有判断，可能又过于粗暴。
因此，工程上需要区分关键依赖和局部依赖。
为什么局部依赖应该局部处理？
在迭代多年的系统里，不同分析组件可能需要不同的附加数据。把所有组件需要的字段合并为一个“全局必须齐备”清单，看起来简单，却会产生副作用：
- 组件 A 所需的一项附加数据短暂不可用；
- 并不使用该数据的组件 B 也被拒绝运行；
- 运行记录只留下笼统的“数据不足”；
- 研究者难以区分正常判断与不必要的连带阻断。
更合适的思路，是让每项可独立判断的组件明确声明自己的输入要求。附加信息缺失时，只限制它有权影响的部分；其余判断仍须经过原本的完整安全检查。
注意：这不是让程序在不知道价格、时间或账户状态时照样下单。局部隔离永远不能越过全局安全约束。
这次架构升级为什么强调依赖边界？
最近的 BTC 5 分钟自动化研究系统升级，针对不同决策环节重新明确了局部数据依赖的处理范围，并进一步强化了可追溯记录。
对外最值得分享的经验，不是内部规则具体引用哪些特征，而是不要让一项可选信息缺失被误判为整个策略系统不可用。
从软件工程角度，这与模块隔离、最小权限和故障域限制是相近的思路：一个局部问题，应该优先在被它实际影响的范围内处理。
错误日志应该回答哪些问题？
仅写 missing data 几乎不能帮助排障。
更有用的审计信息应该帮助回答：
- 缺失的是基础依赖还是局部附加信息？
- 数据是完全不存在、暂时不可用，还是时间戳已经过期？
- 哪个逻辑环节因此没有参与？
- 其他逻辑环节是否仍通过各自的安全要求？
- 最终没有执行的原因是什么？
审计应说明为什么跳过，而不是为不可用的数据编造替代值。
容错不是“尽量保持交易”
自动化交易对错误恢复有额外约束。进程活着不等于行情正确；行情正确不等于交易账户状态可靠；信号出现也不等于订单一定能够安全执行。
因此，一个设计合理的系统可能在局部分析信息缺失时继续完成其余可用的判断，同时在关键数据新鲜度、账户权限或执行安全条件不满足时坚定地选择不交易。
这两种行为并不矛盾，它们都服务于一个目标：让故障影响范围与真实风险范围尽可能一致。
如何验证依赖隔离？
不要只测试所有输入完整时的正常运行。还应在可控测试中分别模拟：
- 某个可选特征缺失；
- 基础市场数据过期；
- 时间戳不连续；
- 执行服务不可用；
- 恢复后重新进入稳定状态。
对每种情况，核对最终状态及日志是否符合事先声明的安全预期。对于金融自动化，可预期地拒绝危险行为同样是一项重要功能。
归根结底，可靠性不是忽略所有错误，而是知道哪些错误可以隔离，哪些错误必须阻止下一步。
本文是通用系统工程方法分享，不涉及专有信号规则、特征清单或参数。任何局部容错都不应削弱真实下单的安全前提。
延伸阅读：从机器人到可维护的交易系统 · 机器人为什么有时应该不交易？ · 从信号到执行