淘宝小程序定制注意事项（三）

这次做淘宝小程序的时候，前端其实不是最让我头疼的部分。

真正需要提前想清楚的是：淘宝前端、自己的后端、淘宝 TOP API、商家 session，到底怎么串起来？

这里不讲完整代码，主要说一下实际项目里的架构思路。

1、先看整体链路

我们这个项目属于品牌方的互动活动小程序，整体架构可以简单理解成：

淘宝 App → 小程序 / H5 → 淘宝 JS SDK → 自己的 PHP 后端 → MySQL / Redis

同时，自己的 PHP 后端还会调用淘宝 TOP API。

后端部署在聚石塔 SAE 环境，技术栈是：PHP、ThinkPHP、MySQL、Redis、Nginx、淘宝 TOP SDK。

2、为什么前端不能把所有事情都做了？

因为有一些操作明显属于商家侧能力。

比如查询用户有没有购买某个商品，实际上是在查店铺订单；再比如给用户增加会员积分，也属于商家侧能力。

所以这种接口不能简单理解成"前端调一下淘宝接口就完了"，而应该由自己的后端负责。

3、消费者端和商家端是两条线

实际项目里，我会把它理解成两个角色。

用户侧：用户 → 消费者端 → 授权 → 自己的后端。

商家侧：商家 → 千牛 App → 扫码 → 获取 sessionKey → 自己的后端 → 淘宝 TOP API。

把这两条线分开之后，后面做接口就清晰多了。

4、订单验证是怎么做的？

我们这个活动有一个任务：用户购买指定商品以后，可以获得活动奖励。

用户进入活动页面以后，后端的处理链路是：

用户进入活动 → 后端拿到用户 open_id → 读取商家 sessionKey → 调用淘宝订单接口 → 查询本店订单 → 判断有没有符合条件的商品 → 有则完成任务，没有则不完成。

这里需要注意的是：查询订单的时候，用的是商家端 session。这也是为什么前面一定要把消费者端和商家端区分开。

5、sessionKey 放在哪里？

实际项目里，我们把商家 sessionKey 放在数据库配置表中。

商家通过千牛 App 扫码获取以后：获取 sessionKey → 后端保存 → 后续接口复用。商家再次登录或者 session 失效的时候，再更新。

这样做比较简单，也符合这个项目的实际需求。

至于怎么判断 sessionKey 是否有效，我们没有单独做一个复杂的"session 检查机制"。实际可以通过调用一个商家接口来验证，比如调用订单查询。接口正常返回，说明当前 session 还可以使用；如果返回 session 无效，就提示重新获取。对于这种活动项目来说，这种方式比较直接。

6、数据库主要保存什么？

这个项目是一个活动类项目，所以数据库并不是特别复杂，主要有：用户、任务记录、中奖记录、奖品池、奖品配置、分享记录、活动配置、API 日志、第三方接口日志。

比如用户表里，会保存 open_id、星光值、任务状态。任务状态这里没有把每天的每个任务都单独做字段，而是用了 bit 位记录。好处是每日任务状态比较集中，重置的时候也比较简单。

7、Redis 在这里主要干什么？

Redis 主要不是为了"显得架构高级"，它在这个项目里有非常明确的用途：奖品库存和并发控制。

比如抽奖的时候，如果多人同时请求，只是"查数据库库存 → 库存减一"，并发情况下就可能出现超扣。所以项目里使用 Redis 队列，再配合数据库原子更新来处理。

8、第三方 API 最重要的其实不是"调通"

淘宝 API 调通只是第一步。真正做项目的时候，还需要处理：签名、session、权限、超时、错误码、日志、重试、幂等。

尤其是积分发放这种操作，不能因为网络抖了一下，就重复给用户发两次积分。所以第三方接口调用一定要有完整的日志和业务状态。

9、最后一个经验：架构不要为了架构而架构

这个项目并不是一个特别大的互联网系统，所以我们没有为了"看起来专业"堆很多东西。实际就是：PHP + MySQL + Redis + 淘宝 TOP SDK，再结合聚石塔 SAE 的环境。

关键不是用了多少技术，而是每个技术解决了什么实际问题。淘宝项目本身已经有很多平台复杂度了，自己的业务侧反而应该尽量简单。

总结

如果把整个后端压缩成一句话：

前端负责用户互动，自己的后端负责业务逻辑，淘宝 TOP API 负责淘宝侧数据和能力，MySQL 保存业务数据，Redis 处理缓存和高并发场景。

真正开发之前，把这几条边界划清楚，后面的代码就没有那么乱了。而淘宝小程序项目里，最容易把人绕进去的，恰恰就是这些边界。