技术群里流传一个说法：微信小程序搬百度，全局把 wx 替换成 swan 就完事。真试过的人都知道，这话说对了一半。上个月我们把一个六十多页的商城项目迁到百度端，把百度小程序开发迁移的真实工时和坑位记下来，给准备动手的团队一个参照。
批量替换能解决的部分
基础能力确实替换得动：请求、存储、跳转、图片上传这些高频接口，两家命名几乎一一对应，写个脚本批量替换，再手工过一遍特殊写法，一天能跑通主流程。组件层面大部分也相通，视图、列表、轮播的用法一致，样式微调即可。这一部分占了整个项目工作量的一小半，替换思路是成立的。
必须动手术的三个模块
- 登录体系：openid 换成 swanid，授权流程和参数结构不同，登录模块重写
- 支付模块：微信支付换成百度收银台，下单、回调、退款三段全部重接
- 分享与卡片：分享逻辑换成搜索卡片和信息流的思路，配置项重新调
这三个平台强绑定模块的改造，占了总工时的另一半还多。六十页的项目，两人一周跑通主流程，登录支付再花五天打磨，最后真机回归测试三天，全程十来个工作日，这还不算审核等待。
条件编译的用法
如果项目原本用跨端框架写的，迁移就轻松得多，框架自带条件编译，平台差异代码用注释块区分，一份代码两端维护。纯原生的项目没这个便利，要么引入适配层把平台调用封起来，要么干脆接受两份分支的现实。那次迁移我们补了一层薄适配层，后续第三端进来也有的接。
迁移前的一份检查单
- 盘点页面清单，标注每页用到的平台接口
- 登录、支付、分享、推送四类强绑定模块单独列项
- 第三方插件和自定义组件逐个确认百度端有没有对应物
- 老版本基础库的兼容要求问清，别迁完低端机跑不动
检查单过完，工作量心里就有数了。迁移项目最怕的是边迁边发现坑，中途加项最耗士气，前期多花两天盘点，换来的是排期表上每一格都填得实。回归测试按核心路径走，浏览、下单、支付、售后四条链路逐条过，别凭感觉说没问题。迁完别忘了把百度端也纳入日常发布流程，两端的版本号和更新日志分开记，混在一起迟早出错。
结论很直白：迁移不是复制粘贴，是接口层的重做加页面层的微调。动手前按页面数、接口数、支付有无三项估个工时，心里有数再排期。百度小程序开发的迁移活，做过一遍就熟，没做过的团队第一次至少多估一半时间，比格网络两端项目都跑过，要评估单可以直接来拿。
