从0~1搭建微信小程序

分几个模块来说：前期准备工作、主要开发内容、发布准备。

一、前期准备工作

• 小程序注册、认证。企业认证需要准备的资料比较多，而且提交后，微信侧的审核一般是1天左右，大家可以在前期就准备起来。我们是在测试的过程中，发现绑定微信支付需要认证，才匆忙走流程，也耽误了一点时间。认证是收费的，微信侧一次300RMB，大家可以提前申请好全部预算，统一申请认证。

• 绑定小程序。小程序可以绑定在公众号下，如果公众号跟小程序是同一认证主体，后续的联动运营也会方便很多，所以在前期，也可以推动业务一起来梳理小程序的运营方案，看看是否要绑定公众号。

• 基本信息完善。包含小程序起名、小程序logo设置等等。还是这次开发过程中踩的坑，因为我们到发布前回归，才发现小程序的名字和logo都是开发随手填的，为了改名，又要走一遍认证流程，再次花费300RMB不说，流程也是很繁琐，会耽误整体进度。

• 测试版小程序准备。看项目要求，如果发布到线上的代码需要现在测试环境完成测试，需要准备测试版小程序。在测试版上验证通过后，再将代码部署到正式的小程序上。

• 运营者/开发者账号管理。建议给直接负责小程序运营的业务开运营者权限，项目组人员开开发者权限即可。方便进行权限管理。毕竟微信管理权限跟企业OA没有直接打通，后续有人离职等不太方便及时回收权限。

二、开发内容

账号体系搭建

当认证主体下只有一个应用时，在微信侧只有一个open ID，做好跟平台user ID的绑定关系即可。但是存在多个应用时，会出现2个问题：

• 多应用账号之间的关系。常见的做法是多应用账号之间互相独立。因为多个应用的主题基本都不一样，用户选择在一个应用上登录/换账号，不应该影响到在其他账号的登录态。举个例子，美团和美团外卖，我在美团小程序上用我妈的手机号给她团购，然后用美团外卖小程序点餐。两者的使用场景相差较远，就没必要做到登录态关联。再举个更极端的例子，如果2个应用之间场景差异巨大，用户甚至都不知道这2个应用属于一个主体，那就更加没必要做到登录态联动了。

• 微信侧union ID /open ID 与平台user ID的绑定关系。常见的做法是微信侧union ID /open ID 与最有可能是该微信使用者的user ID绑定（重点！！！），比如说通过微信授权登录的手机号对应的user ID 与微信侧账号绑定。这时候用户可能会出现切换手机号的情况，切换手机号时，可以把新手机号对应的user ID与微信侧账号临时关联，该账号退出登录后，解除关联关系。

存在多应用的时候，常常会出现应用之间消息联动的需求，比如在小程序A的消费记录，也要出现在小程序B里，这时候通过union ID 与 user ID去关联到用户即可

消息体系搭建

微信公众号提供的消息类型算是丰富了，精心运营的话，能玩出花儿来。小程序比较少，常见的是小程序模板消息，并且推送模板消息还需要用户授权。如果有公众号的话，可以通过union ID，将用户在小程序里的行为信息，通过公众号消息推送出去。

不过在公众号推营销消息时，经常会遇到一推就掉粉的情况，这需要把握个度。

选择H5 or 小程序页面

小程序路径是小程序的原生页面，很多功能都相对灵活，但是H5相对方便，具体要看业务需求来设计。我们在开发过程中，遵循的原则也是主框架用小程序页面，分支流程/跟其他应用重合度较高的场景用H5。

埋点处理

有些小程序的页面可能是从H5搬过来的，这时候要做好埋点，H5侧有埋点，小程序也要再单独埋点，做好数据来源区分，方便后续统计分析。

定位处理

小程序很多功能都依赖于用户定位。常见的做法是只展示上一次用户的定位，不管是用户的经纬度信息，还是用户手动切换的定位，直到用户删除小程序重新进入，再重新申请定位授权。

当然也可以依据业务需求，每次都展示用户的当前定位，或者某些场景展示当前定位，某些场景展示手动选择的定位（这种情况下用户可能会被定位绕晕，慎用！）

其他坑

• 小程序不支持点击下载APP。针对这个问题，要么点击出现二维码，引导用户保存图片（小程序也不支持长按扫非小程序码！），要么点击进入客服，通过客服回复引导下载。不管怎么处理，路径都很长。其实也是能理解，毕竟小程序的昵称是 mini APP嘛。

• 小程序/APP之间的互相跳转逻辑：

  

三、发布准备

发布流程基本可以参考：测试版小程序发布——测试版小程序审核——测试版小程序验收通过——体验版小程序审核——体验版小程序审核通过——正式发布。

在审核的时候，可能会遇到被打回的场景，微信都会给拒绝的原因，根据原因整改即可。我们审核近10次，基本都能在1天内完成，整体速度不算慢。

正式发布并验收通过后，可以把小程序搜索功能放开~另外关闭测试版的搜索功能~

今天就分享到这里，欢迎大家一起交流踩过的坑，共同进步