如果你之前主要做微信小程序，第一次接淘宝小程序会有一个感觉：怎么这么多东西？
代码本身倒没有想象中那么夸张。真正让人觉得麻烦的，是平台周边这一整套东西。
我最近刚完整做完一个淘宝小程序项目，简单总结一下我的感受。
1、最大的区别：平台参与得更深
普通小程序项目，我们习惯的链路很短：前端 → 自己的后端 → 自己的数据库。
但淘宝小程序的实际项目，中间会多出很多淘宝自己的东西：淘宝 App → 小程序 / H5 → 淘宝 JS SDK → 淘宝 TOP API → 自己的后端 → MySQL / Redis。
而后端又不能随便放在普通服务器上，需要放到聚石塔相关环境里。
所以你会发现：自己真正写的代码，反而只是整套系统的一部分。
2、账号体系也更复杂
第一次做的时候，我觉得比较容易混淆的就是账号。
实际项目里大概是：品牌方主账号 → 创建子账号 → 给开发方使用 → 开放平台添加开发者。另外还要处理聚石塔权限。
所以如果客户跟你说："我们已经有淘宝店了，你直接开发就行。"技术人员最好别马上开始写代码，先把账号和权限情况问清楚。
3、为什么还要分消费者端和商家端？
这个设计一开始看起来有点复杂，但做完以后就比较容易理解了。
消费者端主要是用户正在使用的小程序：商品信息、收藏商品、关注店铺、用户授权。
商家端则主要处理需要商家身份才能操作的数据：查询本店订单、会员积分、商家相关数据。
可以简单理解成：消费者端解决"用户在干什么"，商家端解决"店铺有什么权限"。两套应用其实是两个不同的角色。
4、真正让我觉得麻烦的是后端
如果只是写一个普通活动页面，可能没什么。但一旦涉及"这个用户买没买过这个商品？"，你就不能只在自己的数据库里判断，需要去调用淘宝订单接口。又比如"用户中奖以后，给他发100积分"，又需要调用淘宝的会员积分接口。
于是业务链路变成：用户 → 淘宝小程序 → 自己的后端 → 淘宝 TOP API → 淘宝返回结果 → 自己的业务逻辑。
这时候你需要同时考虑：API 权限、sessionKey、签名、超时、返回结果、异常、重试、幂等。开发思路已经和普通小程序不太一样了。
5、部署也是一个大坑
项目最后放到了聚石塔的 SAE。这一套东西下来会涉及：SAE、MySQL RDS、Redis、EIP、CLB、VPC、交换机，而且地域需要统一。比如 SAE 在一个地域，RDS 又买到了另外一个地域，后面就会出现各种问题。
还有 SAE 的 Nginx 需要监听 8080。第一次不知道的时候，很容易出现容器一直重启。
6、所以淘宝小程序的难点到底在哪里？
如果让我总结，我觉得不是"淘宝小程序代码难"，而是"淘宝平台规则多"：
第一层，账号和权限；第二层，消费者端和商家端应用；第三层，淘宝 JS SDK 和 TOP API；第四层，sessionKey 和商家授权；第五层，聚石塔和 SAE；第六层，审核和上线。
这些东西全部串起来以后，才是一套完整的淘宝小程序项目。
7、如果让我重新做
我会把开发顺序调整成：账号权限 → 消费者端应用 → 商家端应用 → 聚石塔环境 → TOP API 调通 → sessionKey 跑通 → 再开始业务开发。
而不是先把页面做完，再解决平台问题。因为平台问题往往才是最容易卡项目进度的地方。
最后
做完这个项目以后，我最大的感受是：微信、支付宝、抖音、淘宝这些平台的小程序，表面上都叫"小程序"，实际开发体验完全不是一回事。
如果只是会一种平台，再去接另一个平台，千万别简单理解成"换套 API"。真正麻烦的，通常是平台背后的权限体系、运行环境和业务规则。
这也是我觉得做这种项目之前，最值得提前研究的地方。下一篇，把淘宝小程序的后端架构拆开讲。
热门跟贴