1. 一个具体问题
一个数据接口同时接收“2026-10-10”和“10/10/26”两种日期写法，调用方觉得很方便。但新地区把后者理解成不同顺序，维护者开始无法判断用户意图。宽容曾帮助接入，后来也让不清楚的协议变成了历史包袱。
2. 一句话解释
波斯特尔法则鼓励发送时遵守规范、接收时适度宽容，但宽容必须受明确语义和安全边界约束。
3. 出处与原意
Jon Postel 在早期互联网协议文档中提出稳健性原则，RFC 793 保留了这一表述。它来自异构网络互操作的背景。后来的 RFC 9413 讨论了宽容接受错误对协议演进的危害，表明这是一项需要结合环境评估的原则，而不是永远正确的通行证。
4. 原理与机制
宽容接收能让小差异不至于中断服务，但若系统静默猜测输入含义，发送者就没有动力修正错误。长期积累后，错误格式成为隐式接口，新的实现必须复制旧缺陷才能兼容。危险还可能来自多个组件对同一输入的解析不同。比较稳妥的方式是区分无歧义的规范化与有歧义的修复：前者可以有记录地接受，后者应返回清晰错误，并通过版本、告警和迁移期推进规范。
协议演进还涉及错误反馈的接收对象。只在服务端日志里记录容错，调用方可能永远不知道自己依赖了旧格式；完全静默的兼容尤其难以退出。可以向开发者返回可识别的弃用信号、提供校验工具，并统计剩余旧客户端。对普通用户则用可理解的字段提示解释如何修改，不必把内部协议术语暴露到操作界面。
5. 一个完整案例
假设案例：一个活动报名接口允许用户提交带首尾空格的邮箱，也曾自动把无法识别的日期猜成当地格式。团队保留去除空格这一明确转换，并记录规范化次数；对日期改为只接受完整年月日，旧客户端先收到警告与迁移说明，过渡期后再严格拒绝。遇到日期错误时返回字段级提示而不是悄悄改成今天。团队用有效报名率和错误重试成功率判断体验，避免把“宽容”仅仅理解成永远不报错。
6. 适用条件与反例
适用于协议设计、导入工具和输入验证的兼容性讨论。权限、金额和签名校验等关键字段尤其不能靠猜测补齐。对于可以明确识别的历史格式，暂时兼容可能比立即拒绝更合理，但应有监测、文档和退出条件。
7. 今天可以尝试的行动
检查一个输入接口，把当前容错行为分为“含义唯一”“需要猜测”“可能改变权限或价值”三类。为后两类补充明确错误和迁移计划；对保留的兼容转换记录调用来源，防止无法解释的宽容永久积累。