客户王总去年做了个微信小程序，生意还行，今年听说百度端能接搜索流量，想再做一个，第一反应是重新报一次预算。聊完发现，像他这种情况，百度小程序开发未必要从零再来，很多页面逻辑可以直接复用，账本翻一翻就知道差多少。
跨端框架让一份代码多处跑
现在主流的做法是用 uni-app 这类跨端框架，一套代码编译出微信小程序、百度智能小程序、支付宝小程序，甚至 H5 和 App。页面结构、业务逻辑、接口层基本通用，需要改的多数是平台特有的接口，比如支付、登录、推送这些。如果从立项就选跨端方案，后续加一端的边际成本大概只占全新开发的四五分之一，这笔账一算就明白。王总的项目最后就是按这个思路做的，省下的钱够他再投一轮内容。补充一点：跨端不等于零成本，两端各一份审核、各一份发布流程，运维环节是双倍的，人手得留出来。另外，跨端框架的版本更新也要跟，拖太久会积累兼容债。
复用虽好，但这几点要想在前头
- 平台差异接口要做兼容层，支付和登录各端逻辑不同
- 样式细节有出入，重点页面要在每端单独走一遍测试
- 部分原生组件表现不一致，涉及复杂交互的要留调整余量
- 后续平台各自升级，维护时几个端要同步跟进
业务简单、页面十几个以内的项目，复用收益最大；功能特别重、重度依赖某一端能力的，反而不如单端做深。拿不定主意的，把三年内的平台规划列出来，照着规划倒推技术选型。
老项目能不能搬过去
原生开发的微信小程序没法直接编译到百度端，要么用转换工具粗转再手工调，要么重写页面层，工作量取决于代码规范程度。去年我们处理过一个两百页的商城项目，评估后只搬了核心交易链路到百度端，其余用 H5 兜底，成本砍掉一大半。百度小程序开发的技术选型，本质上是在为未来多端布局铺路，立项时多想一步，后面就省很多事。尤其是打算年后扩支付宝端或者做 App 的，前期选型多花两天，后面能省两个月。有类似打算的，建议先让比格网络这类做过跨端项目的团队评估一下现有代码，再决定是全搬、搬核心还是重新做，评估费小、返工贵，这笔账别算反了。
