作为后端，如果你要是问我是不是一定要保持单一原则，那我会毫不犹豫的说：是。

但我会依据情况不同改变对单一原则的认定标准（底线灵活）。

单一职责是给内部代码维护用的，不是给外部直接调用的。单一职责的优势是可组合性非常强，代码好维护。但是如果这个接口被外部用了，以后想变就没那么容易了。给外部使用的接口应该首先保证可控，其次才考虑扩展性和灵活性。如果针对外部使用场景专门封装了场景特化接口，这个接口可以随时根据场景调整，内部的单一接口也可以随时按需重构，内部代码的可控性和外部边界都会清晰很多。

视具体业务情况而定

我只会给你开一个聚合接口，不保证后续兼容

看数据的关联性，如果是相对隔离的数据，就分开，不然其他页面正好需要其中一个接口的数据呢，接口单一职责原则的好处不是仅仅对于这一个页面来说的，而已整个系统，职责单一的接口可以灵活的支持其他业务的需求，大接口，基本上只能满足你这一个需求。其他需求要用的话，返回的无用字段太多了。单独一次请求的性能并不一定比两次性能好或者说有感知的提升啊，都是异步并发调用，而且大多时候，观感上来说，分多个接口的效果反而更好（数据逐步渲染，但人眼看到有部分数据出来，就会觉得已经响应了）