嘿，这个问题问得特别到位——我在做AWS相关的API架构设计时，也经常和团队讨论这个决策点。行业里确实有一些公认的惯例，结合你提到的「厂商创建数字钱包优惠券、消费者在夫妻店兑换」这个场景，咱们来具体拆解：

应该拆分新API的典型场景 #

• 业务领域边界明确分离：如果新端点属于完全独立的业务域，就该拆分。比如原API是面向厂商的「优惠券管理API」（负责创建、编辑、批量发放优惠券），而新增的是面向消费者/夫妻店的「优惠券兑换API」（验证有效性、发起兑换、记录核销记录）。这两个场景的用户角色、核心逻辑、数据模型完全不重叠，拆分后能让每个API的职责更单一，后续维护也更清晰。
• 性能与扩展性需求差异大：如果新功能的流量特征和原API完全不同，拆分是更优选择。比如厂商侧的API可能是低频次的后台操作（每天几十上百次请求），而消费者兑换在促销时段可能是每秒上千次的高并发请求。拆分后你可以给兑换API单独配置Auto Scaling、缓存策略、数据库读写容量，不会因为兑换高峰拖垮厂商管理API的稳定性。
• 安全与权限隔离需求：不同受众的API安全策略差异大时，拆分能降低风险。厂商侧API需要高权限（比如修改优惠券规则、查看全量数据），可能用IAM服务账号+MFA验证；而消费者/夫妻店侧只需要低权限（仅能验证自身优惠券、发起核销），用OAuth2用户令牌或者API密钥即可。拆分后可以分别配置API权限策略，避免高权限接口被误访问。
• 独立迭代与版本管理：如果新功能需要快速迭代，或者会打破原API的兼容性，拆分更灵活。比如原API已经稳定运行了半年，现在要推出一套全新的「优惠券过期自动核销」逻辑，和原有的创建逻辑不兼容，拆成新API可以单独迭代版本（比如coupon-redemption-v1），不用强迫原API的厂商用户做迁移。
• 团队职责划分清晰：如果不同团队负责不同业务模块，拆分API能提升协作效率。比如厂商侧API由B端产品团队维护，消费者兑换由C端团队负责，拆分后各自独立开发、测试、部署，不会因为某一方的迭代阻塞另一方的进度。

应该合并到现有API的情况 #

如果新端点和原API的业务逻辑高度耦合，比如「优惠券状态查询」——不管是厂商还是消费者都需要查询优惠券的有效期、使用状态，而且数据模型完全一致，这时候合并到原API更合适，避免重复开发接口，也能保证数据的一致性。

总的来说，核心决策原则就是基于业务域的单一职责、隔离差异化需求、适配团队协作模式，没有绝对的对错，但以上这些是行业里常用的判断依据。

内容的提问来源于stack exchange，提问作者Dan