一般来说，一个客户端产品会在不同的平台均有发布及为用户提供服务，在技术方案设计的过程中，多个平台的系统提供的API架构不同，对于特定的能力实现的流程和机制也有不同，一些开源的能力实现风格也有所不同，技术方案的设定就会存在多端的方案不对齐的情况。
基于同一个功能点，确定相关的技术点都是需要实现的，如果多端的技术方案没有对齐，会存在以下5个直接或间接的影响。
技术实现不统一：因平台特性不同，能力也有所不同，如前期只是以单一平台进行技术方案的投入，技术方案的设计过程，只考虑了单端的能力及现状，那待其它的平台准备实现时，当前的方案就会存在不适用的情况，这时要么对于当前的方案进行重构，要么基于平台的特性再实现一个方案，这时方案是不统一的。
协同成本高：同一个功能，技术方案不同，实现的方式也会不同，技术实现的研发的人员也有可能不是同个团队，相关文档需要写多份，开发过程对接的相关角色时需要得各端各讲一遍，依赖关系不同也会带来研发节奏的不同。
交付节奏不统一：从功能的需求开始，到具体的开发测试，因为技术方案的不同，需求评估成本不同，协同也不一样，实现也有不同，测试方案也有差异，最终交付的节奏不同，投入的资源的不同。当然方案相同也会存在交付节奏不统一的情况，从相同的资源投入的角度来看，多端技术方案不同，出现交付节奏不统一的概率会更高一些。
服务端的对接成本高：一般来讲，一个APP产品的同一个业务会对接一个服务，而当客户端的技术方案不统一，这时就相当于一个服务，对于不同的端的版本要进行功能差异化的适配，主要体现为三个层面，1）同一个功能中的通讯协议不同，解析及逻辑处理流程不同；2）同一个功能支持的版本不同，服务端需要对不同的端的不同版本进行适配；3）同一个功能不同平台需定制化的研发及联调，因为技术方案不同，当出现对服务端的实现产生了的影响，这时服务端就相当于实现了两套逻辑，需要单独研发及联调。
维护成本高：同一个功能，技术方案不同，当线上问题同类型的问题时也可能是不同的团队在定位，功能升级的推进也是多团队的协同。因为同一件事的背后逻辑的不对齐，团队人员之间的交流成本也会提高。同时对于团队的人员流动，业务的细节的考古成本也会提高，人员的复用成本较低。
而当技术方案多端进行了对齐，上述的影响，应该会有一个比较大的改善，客观的讲要作到代码的逻辑全部的统一，是不现实的要求。至少应该是整个功能模块的技术方案是统一的，实现流程统一的，对应的实现过程接口的定义是相近的，可差异化扩展的，通讯协议是相同的，同样也是可差异化扩展的。总结来说就是，多端技术方案的统一对于内部的实现细节不要求一致，但对于与外部协同的相关能力，尽可能是相同的，相似的，可差异化扩展及定制的。
同样，对于打点数据的上传，业务的配置，云控等与服务端相关的数据项处理也应该是多端方案对齐的，对于服务端的逻辑也可以多端的复用，达到效率提升的目的。
