别让一次改需求就推翻重来
做办公系统对接时，经常遇到甲方一句话就让整个接口重做的情况。比如上周财务部门突然说报销流程要加个审批节点，原来传5个字段的API现在得塞8个，还要求兼容旧客户端。这种事太常见了，关键是怎么设计API才能少返工。
留好扩展点，别把路走死
定义接口的时候，别图省事把所有字段都设成必填。像用户信息这类结构，多用可选字段（optional field）。新功能需要加数据，直接在body里添字段就行，老程序忽略新字段也能正常跑。就像发快递，地址电话是必须的，备注栏爱写不写，谁也不会因为没写备注就把包裹退回。
{
"user_id": "U1001",
"name": "张三",
"department": "市场部",
"extension": {
"position_level": "P3",
"entry_date": "2022-03-01"
}
}把扩展属性集中放在extension对象里，后续加职级、工龄、绩效都不用动主结构。
版本控制不是备胎，是标配
/api/v1/user 这种路径设计不是装样子。真遇到不兼容更新，比如把department改成dept_code这种破坏性改动，直接上v2。老系统继续走v1，新功能用v2，两边互不影响。等旧客户端都升级完了，再下线老版本。某次行政系统升级组织架构模型，靠这招平滑过渡了三个月，没人投诉接口断了。
用查询参数收容临时需求
运营同事临时要导出带考勤状态的花名册，技术肯定不想马上改接口。这时候用query parameter最方便：/api/users?include_attendance=1。服务端按需拼数据，前端拿到后自行处理展示逻辑。类似include_xxx这类开关，能挡住七成以上的零散需求变更。
文档比代码更怕过期
每次改接口，顺手更新下Swagger注释。曾经有次新增了status_filter参数，但忘了写文档，结果三个团队各自猜含义，联调花了两天才对齐。现在养成习惯，提交代码的同时把接口说明贴群里，谁要用自己看，省得反复解释。”,”seo_title”:”API设计技巧：轻松应对频繁的需求变更”,”seo_description”:”了解如何通过合理的API设计策略，快速适应办公系统中不断变化的业务需求，减少返工成本。”,”keywords”:”API设计,需求变更,接口设计,办公系统,版本控制,扩展性”}