用途：在设计或修改 API、添加破坏性变更、客户端依赖 API 稳定性时使用，帮助团队建立 API 版本化与演进策略。
主要能力：
- 破坏性变更识别表：删除字段、重命名字段、改字段类型、改响应结构、加必填参数、删端点、改错误码均属破坏性；新增可选字段、新端点、可选参数则安全。
- 版本策略：URL 路径版本（推荐，如 /api/v1/users，显式、可缓存、易路由）；请求头版本（Accept: application/vnd.api+json; version=1，URL 干净但隐蔽、难测试）；查询参数版本（/api/users?version=1，简单但易被遗忘）。
- 版本演进模式：同一控制器同时提供 getUserV1 与 getUserV2，v1 由新字段计算旧结构，避免静默改 v1 响应或强制客户端同步升级。
- 弃用协议：通过 Deprecation、Sunset、Link 响应头公告，记录调用量，外部 API 至少维护 6 个月，到期后返回 410 Gone 并给出迁移文档与后继端点。
- 生命周期：Alpha（v0.x，可破坏）→ Released（v1+，不可破坏，支持 2-3 个版本）→ Deprecated（警告）→ Sunset（410 Gone，移除代码）。
- 压力应对：针对“先上线以后再版本化”“内部 API 不用版本”“只是修 bug”“没人用这个字段”“会通知客户端”等理由给出反驳与行动建议。
使用方式：作为设计评审与变更决策的检查清单，在新增端点、修改响应、规划演进时对照执行；示例代码为 JavaScript/TypeScript 片段，展示路由与响应头写法。
适用场景：公开 API、内部服务接口、SDK 后端、需要长期兼容客户端的系统。
限制：资料未提供具体工具、安装命令、收费信息或平台支持范围；内容为方法论与代码示例，实际落地需结合自身框架。核心原则是版本从第一天开始、已发布版本永不破坏、弃用要留足迁移时间。