先讲一次排查。一个社区团购小程序的订阅消息总是时灵时不灵，最后在服务器上抓到原因：Node 后端被两个进程各跑了一份（宝塔里残留了一个旧进程），两边各自刷新 access_token，互相覆盖，微信侧的 token 一被顶掉，另一个进程的下发就静默失败。类似「环境混乱型故障」在这种没维护人的小后端上特别常见。
这个项目后来整个重写了，也让我把「小程序后端怎么选」这个问题的答案整理成了三条固定路线。结论先放这：不是选最强的技术，是按客户现状分流。
路线一：云开发------没有技术人的甲方
云开发把服务器、数据库、HTTPS、合法域名配置全免了，部署即上线。适合全新、逻辑简单的项目：预约、展示、轻量商城。我手上一个门店预约客户，云开发月账单 37 块，一年没碰过服务器。
边界也很清楚：数据锁在微信生态里，导出和迁移别扭；对账、定时结算、对接 ERP 这类复杂逻辑用云函数写越久越拧巴；请求量上来后费用涨得比固定服务器快。纯新项目可以上，要「长成系统」的别上。
路线二：自建 .NET WebAPI------要和已有系统打通
那个团购客户手上有一套 WPF 进销存，商品、库存、供应商全在里面。重写时小程序后端直接连进销存库，库存扣减走同一套逻辑，桌面端和小程序看到同一个数字。凡是「已有系统要打通」的场景，数据同源的收益会碾压一切省事。
自建要交的学费是微信侧工程清单：
- code2session：wx.login 的 code 换 openid，服务端统一封装；
- access_token：两小时过期，全局缓存，多实例放 Redis（开头那次故障就是反面教材）；
- 订阅消息：一次授权一次下发，时机挂业务节点；
- 支付 v3：回调先落库再应答，按 Wechatpay-Serial 选平台公钥验签，AES-256-GCM 解密，处理平台证书轮换；
- 前置条件：域名 HTTPS + ICP 备案 + request 合法域名，缺一个真机全挂。
路线三：Node 自建------前端团队的主场
前后端同栈，招人和维护成本低，外包市场报价友好。前提是客户有前端、或者能长期找到 Node 的人。那个团购客户一个技术人都没有，前外包失联后连宝塔密码都没人知道------这种现状下，Node 自建等于把故障风险原样留着。技术选型的隐藏条件是：出事的时候，谁能在最短时间打开看。
分流决策
- 已有 ERP / 进销存 / 桌面软件要打通 → 自建，优先复用现有库；
- 全新、简单、无技术人 → 云开发；
- 有前端团队、长期自维护 → Node。
最后一个容易被忽略的架构事实：自建的那套 API 不只服务小程序。同一个接口层，WPF 桌面端在吃，MAUI / uni-app 的 APP 也在吃。后端选对了，一次投入三端复用；选错了，每上一个新端就是一次后端重写。
写在最后
重写后的团购小程序跑了一年多，没有再出过一次大规模超时，那次 access_token 互相覆盖的排查也成了我给每个客户讲选型时的开场案例。小程序后端选型的本质，不是技术竞争，是运维归属和数据归属的决策。
有定制开发需求欢迎掘金私信交流。