中间件 SDK 的向后兼容，到底兼容到哪一层？

背景：做中间件这些年，最容易被低估、也最容易在半年后引爆的，就是"版本演进时的兼容边界"。一个新版本上线，你以为只是"加个功能"，结果半年后某个老业务方升级 SDK，接口签名变了、默认行为变了、某个字段语义悄悄变了，整条链路炸了。兼容问题不像功能 bug 那样当场暴露，它是"延迟引爆"的——今天省下的兼容成本，三个月后变成一次 P1 事故。

常见几种做法 / 分歧：

1. 严格向后兼容派：public API 一旦发出就"终身制"，任何签名变更必须走"新增方法 + 弃用旧方法"，老接口永远保留（哪怕标 @Deprecated）。代价是 API 表面积持续膨胀，代码里堆一堆僵尸方法，新人不知道该用哪个。
2. 大版本断代派：破坏性变更直接进 v2 / v3，老版本进维护期后不再修，逼用户迁移。好处是 API 干净、演进快，坏处是迁移成本全压在用户身上，且"维护期"往往一拖再拖。
3. 语义兼容派：签名不变，但内部行为按"合理直觉"改——默认超时从无限改成 3s、默认重试从 3 次改成 1 次、某个字段从"空串"变成"null"。最隐蔽也最危险：编译能过、单测能过，线上行为却变了，用户根本不知道。

我的倾向与理由（契约分级 + 显式弃用窗口）：

• 把 API 拆成 稳定契约（stability: stable）与 实验接口（experimental）：只有 stable 享受"终身兼容"承诺，experimental 随时可断、可删、可改语义，并在文档里明说"不受兼容约束"。
• 破坏性变更走标准流程：弃用标记 → 至少一个完整大版本周期的过渡窗口 → 才允许删除；默认行为变更必须在 CHANGELOG 单列一节，附迁移脚本 / 对照表。
• 理由：可维护性来自"可预期"。用户能容忍你改，不能容忍你"悄悄改"。显式弃用把破坏性变更从"暗雷"变成"明牌"，长期成本更低、回滚面更小。

想听大家聊聊：

• 你们团队怎么划分"稳定 vs 实验"API？有没有机器化的判定手段（比如按调用频次 / 灰度比例 / 接入方数量自动降级为实验接口）？
• "默认行为变更"（不改签名、只改语义）你们算不算破坏性变更？归在哪个等级、怎么管理？
• 有没有因为"兼容太保守"导致 API 臃肿到没人敢动，或"兼容太激进"直接酿成线上事故的真实案例？