SaaS微信小程序开发实战，一套系统多端复用

去年年底，我们团队接了一个连锁餐饮品牌的数字化项目。老板上来就提了个要求：一套后台，要同时管直营店、加盟店，还要给C端顾客做点餐小程序，给B端店长做巡店小程序。当时我就意识到，这活儿要是按传统思路一个个开发，光维护就能把人拖垮。所以，我们最终选择了SaaS微信小程序开发的路线，把核心业务逻辑全部抽离到云端，前端用一套代码编译成多个小程序端。今天就把这过程中的实战经验拆开揉碎了聊一聊。

很多人一听SaaS微信小程序开发，第一反应就是“多租户”三个字。但真落地的时候，坑远比想象中多。比如我们对接微信支付时，发现不同加盟商需要各自独立的商户号，资金流不能混。这时候，SaaS架构里的“支付路由”就成了关键。我们不能简单地在后端写死一个商户号，而是要在用户请求进来时，根据其所属租户的标识，动态选择对应的支付配置。这一层逻辑如果没在数据库设计阶段就规划好，后面上线了再改，那真是牵一发动全身。我们当时就在租户表里专门加了支付配置的JSON字段，虽然看起来不够“规范”，但胜在灵活，每个加盟商可以单独配置自己的证书和密钥。

再聊聊多端复用这件事。微信小程序、支付宝小程序、抖音小程序，甚至H5，底层语法虽然都趋近于原生，但API差异还是让人头疼。比如微信的`wx.login`和支付宝的`my.getAuthCode`，返回的code格式完全不同。我们团队的做法是，在业务代码外层封装一层统一的鉴权模块，内部用条件编译去区分平台。说白了，就是把所有平台差异都堵在入口处，业务逻辑里永远只看到我们自己定义的`this.$login()`。这样，一套Vue或React代码，通过uni-app或Taro这类框架编译出去，80%的代码能直接复用。剩下那20%，基本就是原生组件或者特殊交互，单独写几个条件编译的分支文件就好。千万别想着每个平台单独维护一套代码库，那等于给自己挖了个无底洞。

这里有个特别容易忽略的细节——版本更新问题。SaaS系统最怕什么？怕你凌晨两点改了个bug，结果小程序端因为微信的审核机制，用户还在用旧版。所以，我们在SaaS微信小程序开发里，强制引入了“服务端开关”的概念。不是每个功能都靠发版上线，而是把那些高频变动的业务规则、营销活动配置，全部做成后端的动态配置项。小程序端启动时拉取一份配置中心的数据，按需渲染。比如某个加盟商要搞“满50减10”活动，运营在后台配置一下，小程序端不用审核，十秒内就能生效。这一点，对于多租户场景尤其重要，因为不同租户的活动配置千差万别，如果都靠代码发版，那开发团队啥也不用干，天天提交审核算了。

数据库层面的隔离策略，也是实战里绕不开的坎。我们选了共享数据库、共享Schema，但通过租户ID字段来行级隔离的方案。为什么不用独立数据库或者独立Schema？因为成本。你想想，几十个加盟商，每个都搞一套独立的表结构，备份、迁移、升级，哪个不是噩梦。但共享表结构也有风险，最怕的就是索引没设计好，某个大客户的查询拖垮了全库的性能。我们当时吃过一次亏，有个加盟商的数据量暴涨，一个普通的订单查询接口直接超时，导致所有租户都遭殃。后来痛定思痛，把所有核心表都强制加上租户ID作为索引前缀，并且做了读写分离，统计类的查询全部走只读从库。这才算稳住了。

再说说登录态和会话管理。SaaS系统里，一个用户可能同时是A加盟商的顾客，又是B加盟商的店长。那他的登录态怎么区分？如果只靠一个全局的openid，那肯定乱套。我们的方案是“用户中心+租户上下文”。用户统一在微信授权后，我们生成一个全局的user_token，但具体业务请求时，必须携带当前操作环境的tenant_id。后端拦截器会校验这个用户在指定租户下的角色权限。比如同一部手机，打开A品牌的小程序，他是会员；打开B品牌的巡店小程序，他是店长。这中间的用户信息是打通的，但业务数据是完全隔离的。这套机制实现起来不难，难的是想清楚“用户”和“租户”之间的关联关系，千万别做成一对一，一定要做成多对多。

还有一个容易被忽略的，就是文件存储和素材管理。多端复用后，图片、视频这些资源上传到哪个平台？我们统一用的是云存储，然后生成CDN加速的URL。但这里有个细节，微信小程序的`wx.uploadFile`和H5的`XMLHttpRequest`上传，对文件类型的校验逻辑不一致。你不能在客户端做太多限制，否则换个端就出问题。我们把文件类型、大小校验全部放到服务端，客户端只负责传二进制流。这样虽然增加了服务端压力，但换来了各端行为的一致性和稳定性。而且，存储的目录结构一定要按租户ID来分区，这样后续做数据清理或者迁出时，会省很多力气。

聊聊上线后的监控。SaaS微信小程序开发完，不是上线就完事了。多租户意味着多套业务逻辑同时跑，任何一个租户的异常数据都可能影响整体稳定性。我们接入了专门的前端错误监控，把小程序端的JS异常、API请求失败率、白屏率都做了实时上报。但最关键的，还是“租户维度”的监控。比如某个加盟商的接口成功率突然降到90%，哪怕整体是99%，也要立刻告警。因为对于那个加盟商来说，他感知到的就是系统坏了。我们通过日志系统里给每个请求打上tenant_id的标签，再用类似ELK的工具做聚合分析，能快速定位到是哪个租户的哪个接口出了问题。这一点，在传统单租户开发里几乎不用考虑，但在SaaS里，这就是生死线。

说到底，SaaS微信小程序开发的核心，不是技术选型多炫酷，而是“边界感”。你要清楚哪些逻辑是公用的，哪些是租户私有的；哪些数据可以共享，哪些必须隔离。一套系统多端复用，听起来像是技术上的省力，实际上是对业务抽象能力的巨大考验。我们这套方案跑下来，最大的收获不是代码量减少了一半，而是新接入一个加盟商时，从部署到上线只需要一天时间，这背后全是架构设计时留下的余地。如果你也在做类似的项目，记住一句话：别急着写代码，先把租户边界画清楚。