1. 一个具体问题
一个接口文档从未承诺返回列表的顺序，维护者把底层结构从有序容器换成无序容器，结果多个客户的报表出现错乱。维护者觉得没有违约，客户却认为稳定运行的系统被破坏。文档契约与实际形成的依赖之间，往往存在很大距离。
2. 一句话解释
当使用者足够多时，系统几乎任何可观察行为，都可能被某个使用者当作稳定依赖。
3. 出处与原意
Hyrum Wright 根据大型基础库迁移的经验提出这一观察，Titus Winters 帮助命名和传播。作者网站称它为软件工程观察。这里的“任何行为”是强调规模下隐式契约的风险，不是可以严格证明每一项行为都必然被依赖的定理。
4. 原理与机制
调用者不仅看到方法签名，也看到错误文案、遍历顺序、默认值、时间特征和失败次数。某个偶然行为一旦重复足够久，就可能进入脚本和业务判断。接口拥有者看不到所有下游，因此文档中“未定义”不等于现实中“无人使用”。应对方式是降低意外承诺、增加消费者测试和渐进迁移。把不保证的行为在测试环境中主动扰动，也可以提前暴露错误依赖，但这种扰动本身必须可控。
兼容性管理因此需要区分承诺等级。明确支持的契约可以保持稳定，已发现的偶然依赖应记录影响和迁移时间，尚未发现的依赖则通过灰度与回滚降低风险。若为了减少维护负担而立即删除旧行为，却没有识别调用方，成本往往只是被转移给下游。相反，永久保留每一个历史缺陷也会锁死演进，关键在于让迁移成为可安排的工程工作。
5. 一个完整案例
假设案例：内部检索接口一直按写入顺序返回结果，两个报表脚本直接取第一项当作最新记录。维护者计划换索引时，先加入可选的新排序模式并记录调用方，在预发布环境随机化未承诺的顺序。报表团队因此发现问题，改为明确传入按时间降序的参数。迁移再从少量调用者开始，观察错误率与业务校验差异。最终不是永久保留所有偶然行为，而是把真正需要的排序变为显式契约，并为其他调用者提供迁移窗口。
6. 适用条件与反例
适合公共 API、共享库、命令行工具和长期存续的数据格式。不能因此认定任何变化都不允许：漏洞修复或明显错误仍可能必须打破兼容性，只是要评估影响、沟通并给出替代路径。只有一个受控调用方的系统，通常可以更直接地协同修改。
7. 今天可以尝试的行动
准备一次接口升级时，除字段列表外再列出三项可观察行为，例如顺序、错误文本和重试时机。询问主要调用方是否依赖，补上少量真实消费者测试，并明确哪些行为将稳定、哪些需要迁移。不要只凭服务端单元测试宣布兼容。