用途：为 API 设计并落地版本管理方案，覆盖策略选择、向后兼容规则、弃用流程与迁移输出。
主要能力：
- 策略选择。URL 版本（/v1/users）易路由、日志与缓存，适合公开 API；请求头版本（API-Version: 2 或 Accept 协商）保持 URL 干净，适合内部/RPC 风格，但需加 Vary: API-Version 以免 CDN 与代理缓存串版本；查询参数版本（?version=2）仅适合只读、公开、不可缓存的端点，禁止用于写操作。
- 兼容性判定。破坏性变更包括：新增必填请求字段、收窄字段类型、改变错误码或错误结构、重排枚举值、删除响应字段、改变分页形态、收紧校验。安全变更包括：新增可选请求字段、新增响应字段、新增枚举值、放宽校验。
- 弃用头。使用 RFC 8594 标准：Deprecation: true、Sunset: Sat, 31 Dec 2025 23:59:59 GMT、Link: https://api.example.com/v2/users; rel="successor-version"，应在路由/中间件层统一注入。
- 路由模式。优先在网关或反向代理层路由（/v1/* → service:8001，/v2/* → service:8002）；变更端点少于 20% 时共享代码库按版本分支，超过 50% 时 fork 处理层但共享服务与数据层，数据库层不要分叉。
- 下线执行。提前加弃用头（第三方至少 3 个月，内部 2 周），记录并统计旧版本流量，联系头部客户，下线后返回 410 Gone 并保留路由 6 个月以上。
- 版本协商。无版本头时可选返回最新版（不推荐）、返回最旧稳定版（较安全）或返回 400 明确报错（内部 API 最佳）。
输出形式：中间件片段、网关路由配置、OpenAPI 破坏性变更审计、弃用通知模板、迁移指南骨架。
限制：资料未提供具体框架的完整代码示例、价格或平台支持信息；实际弃用时间线与默认版本行为需按业务自行确定。