1.3 环境准备：开通云开发与小程序账号

场景

选型敲定后的第二天下午，我带着电脑去店里，准备一口气把账号和环境开完。本以为是个收银台式的傻瓜流程，实际花了三天，卡点全在资质上：朋友的店是刚注册的个体工商户，营业执照经营范围只有“工艺品零售”，小程序类目审核时被退回一次；微信支付商户号申请要求对公账户，跑了两趟银行才办下来；最折腾的是小程序认证的公函盖章，个体户没有公章，只能走法人手持证件的特别通道，来回补充了两次材料。

这节把整个开通流程捋成一张地图，给同样从零开始的人省时间。先把结论放这里：个体工商户完全可以开通小程序和微信支付，只是部分环节要选对通道，别按企业流程死磕。整个流程分两条线并行推进——小程序账号线负责“能让用户打开”，云开发线负责“后端能跑”，微信支付线负责“能收钱”。

朋友全程只有一个诉求：别让我填一桌子表格。她怕的不是花钱，是那种“每个窗口都要重新解释一遍我是谁”的挫败感。所以我把所有需要法人本人操作的动作——认证扫脸、银行签字、商户平台确认——压缩到两个半天集中办完，其余能代填的表单我都先填好只留签字位。这个安排后面证明很关键，否则她会把这事拖到过完年。

那三天的流水账是这样的：第一天注册小程序、提交认证资料、同时在网上填云开发开通申请，下午去银行问对公账户需要哪些材料；第二天认证资料被退回，补经营范围说明的同时，跑银行交对公账户开户材料，云开发环境先在个人测试号上开起来了；第三天认证通过、对公账户办好、商户号申请提交，晚上把商品集合和权限规则配好，第一版列表接口跑通。如果没有提前画好并行计划，这三天的活很容易串行成两周，开店的日子就得往后顺延。

方案

三条线的步骤、耗时和卡点我提前列了一张表，照着走基本不会迷路：

我的建议是小程序注册和主体认证先跑起来，因为认证要等；等认证的几天里，云开发环境可以先用个人主体的测试号开通做开发，代码逻辑是一样的，上线前再切到正式环境。微信支付商户号同步去银行办对公账户，三件事并行能把三天压缩到一周内。

还有个顺序细节值得强调：支付商户号的申请可以在小程序认证通过之前就提交，因为它认的是营业执照而不是小程序，两边并行又是一天。但“绑定小程序与商户号”这一步必须等小程序认证完成、拿到已认证的 AppID 之后才能做，别把它排在前面干等。

配置/代码

云开发的开通比想象中简单。在小程序开发者工具里打开云开发面板，点开通，选按量付费，填一个环境名，两分钟就拿到环境 ID。这里插一句：环境开通时会让选基础版或标准版，起步期直接选按量付费的基础版即可，等大促前再根据调用量升级，钱花在刀刃上。拿到 ID 之后第一件事是建数据库集合并配权限——这一步常被忽略，直接影响后面调试顺不顺：

// 云数据库 goods 集合的权限规则：只读对所有用户开放
{
  "read": true,
  "write": false
}

商品这类公开数据设为所有人可读、不可写；购物车和订单这类私有数据，必须设成“仅创建者可读写”，否则用户 A 能查到用户 B 的订单，属于严重的信息泄露。我自己调试时图快把 orders 临时设成全可读，险些带着这个配置上线，幸亏发版清单里有一条“检查所有集合权限规则”，发布前五分钟改回来，惊出一身冷汗。

开通完成后，把环境 ID 填进小程序，再检查开发者工具里的 project.config.json，确认 cloudfunctionRoot 字段指向云函数目录，这样右键就能部署云函数，不用敲命令行。第一次部署云函数的流程是：在云函数目录上右键、选择“上传并部署：云端安装依赖”，等十几秒，控制台里出现部署成功就能调用了。部署频率和日志检索的技巧，在云函数错误与告警那节有展开。环境 ID 本身不敏感，可以提交进代码仓库；真正敏感的是后面微信支付的 APIv3 密钥，任何时候都不要写进仓库。

云数据库这边也顺手把索引建了，不然等数据量上来再建就尴尬了：goods 集合按 categoryId 建单字段索引，skus 按 spuId 建索引，orders 按 openid 和 status 建组合索引。控制台的索引管理页可以点点建好，也可以在代码里用 createIndex 建好存进部署脚本里，后者方便多个环境同步照抄，免去在正式环境漏建索引这种低级事故。

如果你还没有云开发环境，腾讯云云开发 CloudBase 新用户特惠是新开通的首选入口，套餐比按量付费适合起步期日均调用不高的商城。

微信支付这边的配置是本节的重头：商户平台拿到商户号，在小程序后台把 AppID 与商户号关联，然后在商户平台生成 APIv3 密钥并设置支付回调地址。回调地址必须填备案过的 HTTPS 域名——云开发的好处是云函数可以直接获得一个默认域名，备案后挂上来，省去自备服务器的麻烦。备案全程花了大概十二个工作日，建议开通环境当天就提交，别等到大促前。

证书和密钥统一走云函数的环境变量注入，代码里只读变量名，这样即便代码仓库哪天泄露，钱那头的钥匙还在保险柜里。

各集合的权限规则也在这一步配齐，后来再没动过。其中 orders 的“仅创建者可读写”是最关键的一条，杜绝了越权查看他人订单的可能，更细的鉴权设计在安全加固那节展开：

踩坑

第一个坑是类目与经营范围。小程序服务类目“电商平台”要求营业执照有对应经营范围，朋友的“工艺品零售”被退回。解决办法是重选“百货/工艺品”类目，电商类目留给以后扩展。类目选错轻则审核退回，重则上线后被处罚，值得花半小时研究类目说明。另外已选类目会影响后续能否调用支付、直播等能力，选之前先对着能力清单核一遍，免得事后返工。

第二个坑是公章。个体工商户默认没有公章，微信认证的公函流程让我们干等两天。后来走“法人手持身份证加营业执照”的替代通道才通过，客服提示这个通道需要营业执照注册满一定时长，新执照可能要等。开店计划里务必给认证留缓冲，别把开业日子卡在认证这关上。

第三个坑是支付回调域名。一开始我以为要自己买域名备案，跑了一圈发现云函数自带 HTTPS 域名，只是要注意这个域名有调用频率限制，做过高并发压测会被限流。最终方案是下单走云函数域名，静态资源走 CDN 域名，两条链路分开。备案这件事本身也要十几个工作日，趁早提交。

第四个坑是测试环境数据污染。开发环境我造了一批测试订单，某次把环境 ID 改错发布到正式环境，测试订单混进了线上列表。虽然十分钟后回滚，但那十分钟正好有顾客在下单，客服解释了好一阵。此后 env 切换变成发版检查清单的第一条，并且测试环境里的订单统一带“测试”前缀，一眼能认出来。

第五个坑是 AppSecret 误提交。有一次提交代码顺手把小程序的 AppSecret 也传上去了，虽然仓库私有，还是连夜重置了一遍密钥。加 git 忽略规则永远比记性好使，密钥这种东西不该出现在编辑器里。

第六个坑是没开计费提醒。云开发按量付费，某次我写了个压测脚本忘记关，跑到半夜，第二天收到扣费提醒才发现，账单多出了一小笔冤枉钱。当天就在控制台设了月度预算阈值告警，超过预算八成就弹通知。小团队对账单敏感，这条告警值千金。

小结

环境准备这一节没啥技术难度，全是流程和资质的耐心活。核心经验三条：三条线并行推进省时间；权限规则和密钥在写第一行代码前就定好规矩；发版清单里永远有“检查环境 ID 和集合权限”这两条，再加一条“密钥没进仓库”。友情提示：所有需要法人本人扫脸和签字的环节集中办好，这是个体户开店最省力的走法。开通只是入场券，下一节把云函数、云数据库、云存储的地图铺开，正式进入开发。

延伸阅读

• 技术栈对齐：云函数与云数据库地图：下一节，摸清家底再动手
• 腾讯云产品选型与实践：账号与权限体系的通用设计
• 回到本书目录：全书五篇结构一览