Spring Cloud 联调：用契约替代口头约定

后端架构先看边界和失败路径，再看吞吐数字。这篇只讨论一个问题：Spring Cloud 联调：用契约替代口头约定。

写作边界：围绕“Spring Cloud 联调：用契约替代口头约定”出现的数字、事故场景和性能结果均用于演示分析方法，不是特定项目的实测结论。落地时请记录版本、输入、资源、统计窗口和失败路径，再用自己的测试数据复核。

契约里至少写清四件事

PRD 和接口文档分开并没有问题，问题是两份材料对同一个失败状态说法不同。Spring Cloud 接入检索或模型服务时，契约里至少要写清输入上限、超时预算、错误语义和降级结果。

Token 预算应由业务场景、上下文长度和成本共同确定，不能只由产品或研发单方拍板。SSE 已开始传输后，可以用明确的event: error通知客户端；若请求尚未建立，认证失败、限流和服务不可用仍应使用合适的 HTTP 状态码。两种路径要在客户端状态机里分别处理。

回归集也要可追溯。样本来自哪里、是否脱敏、预期结果由谁确认，都比“有多少条 Prompt”更重要。契约变更后同时跑接口测试和语义回归，并把不兼容项写进发布说明，联调会少很多猜测。

落地检查

• 固定“Spring Cloud 联调：用契约替代口头约定”涉及的输入、版本、流量模型与统计窗口，再比较变更前后。
• 对自动化动作设置权限、超时和熔断；失败时回到可解释的确定性路径。
• 把结论连同原始日志、指标截图和回滚条件一起归档，避免只留下口头判断。