@findex 可能是吧，重启了一次，更新成功了

当前版本 12 .2.1 今天下午升级 12.3 试了几次每次都快下完了报错

MFBLLB

接力

合上 22 次活动圆环

@lindt99cocoa @wangedenr @ahhui 谢谢，等我有空了去换一张 sim 卡试试

@autoxbc 手机都不怎么发热

@lycorischeung @HiCoder 看来这个问题还挺普遍

年前下的单，中间有自动变更过一次发货时间，给提前了一周

等他们动静没有了，你开始动静

14 寸，32g 还在路上

最早用 uber ，后面就没打过出租车

《凤凰架构》

@edward1987 抽象的肯定是内部逻辑，另外对外接口也应该尽量服用，不能来一个业务就开一个接口，这里不同的是场景而不是版本，这里不存在版本，接口必须向下兼容

@SmiteChow 这个接口是老接口，把所有场景识别出来对老员工确实也有一定考验，另外公司搭建了接口管理平台，也是与 swagger 注解自动生成的，我是希望最好使用方能通过接口平台能看懂，把平台用起来，提高沟通效率，目前看 swagger 的注解无法满足我上述的问题中的差异场景字段是否必传的体现，当前也只能是通过文档了

@sagaxu 当前订单模型结构整体是满足通用的，也在不同层级留有扩展字段，目前的复用是在字段层面，同一个字段可能不同业务的用法都会不同，或者不同业务在扩展对象里塞一个特性值，扩展本身就自带一层模糊的意思，只能通过注释来备注

@akira 即使设计一个单一接口作为路由，但是还是会涉及到一个抽象入参的设计，随着业务变化，参数还是会臃肿

@IvanLi127 controller 层还好，都是自己人写，但是 app 的后端是其他组来写对接的问题主要在这里，为什么不多拆接口，因为调用方跨组，希望 service 接口尽量复用，而不是每次新开接口，这样接口太多维护成本高

@Jooooooooo 之前我一直主张新开接口，这样场景很具体处理很方便，不过后来我也认同了去抽象。不拆分原因 1 领导认为主流程接口尽量复用，2 抽象的业务主流程大体一致，只是部分点会有差异，在一个接口里能更好识别不同业务的差异，3 目前场景比较多，业务组分了三个，每个业务组下还能细化出几个业务单元，如果接口拆分太散，维护起来麻烦，对接麻烦