小程序后端怎么选：云开发、自建还是 Node？我的答案从来不是固定的

去年双十一早上八点零三分，我手机收到一条短信报警：一个社区团购小程序的接口成功率掉到 40% 以下。八点二十，客户电话进来，声音都变了调：「我就发了个今天开团的链接，怎么大家下单全在转圈？」

这个小程序是客户上一个外包失联后转过来的：Node 写的后端，宝塔面板部署在一台 1 核 2G 的服务器上，数据库 MongoDB，没有备份策略。开团那波并发一进来，Node 进程内存打满，接口全线超时。那天早上我们把服务器临时升到 2 核 4G 扛过去了，但真正的问题埋在更早的地方——后端选型那天起，就没有人和客户聊过「这个系统以后长什么样、谁来管」。

小程序后端到底选什么，我这些年给的答案从来不是固定的。就三条路：微信云开发、自建后端（我用 .NET WebAPI）、Node 自建。选哪条，看的不是技术排行榜，是你手上有什么。

先说云开发：便宜、省事，但有边界

云开发是微信官方的无服务器方案：不用买服务器，不用域名备案，连 request 合法域名都不用配，数据库和文件存储都内置。我有个做社区门店预约的客户，整体逻辑就是「选时段、提交预约、到店核销」，上了云开发之后一年到头不用碰服务器，上个月账单 37 块。

但有三个边界要提前想清楚。第一，数据锁在微信生态里：哪天想做个网页版后台、或者把数据导进自己的报表系统，得走导出或付费迁移，很别扭。第二，复杂业务受限：对账、定时结算、对接第三方 ERP 这类活，用云函数写会越来越拧巴。第三，成本曲线：逻辑简单时便宜，请求量和数据库读写一上来，费用涨得比一台固定服务器快。

自建 .NET WebAPI：贵在前期，赚在复用

那个双十一出事的团购小程序，我们最后重写成了 .NET WebAPI。不是因为 Node 不行，而是客户自己有一套 WPF 写的进销存桌面软件——供应商、商品、库存全在里面。重写时小程序后端直接连进销存的数据库，库存扣减走同一套逻辑，桌面端开单和小程序下单看到的是同一个数字，再也没有「两边对不上」的扯皮。

自建的隐性成本要诚实列出来：域名一年几十块，ICP 备案顺利也要两周左右，HTTPS 证书、服务器加固、备份策略，上线前一个都不能少。工程细节上，wx.login 换 openid 的 code2session 要自己封装；access_token 有效期两小时，必须做全局缓存，多实例部署还得放 Redis；订阅消息一次授权只能下发一次，下发时机要和业务节点对齐；微信支付 v3 的回调要按 Wechatpay-Serial 选平台公钥验签、AES-256-GCM 解密，还要处理平台证书轮换——这些坑云开发都帮你免了，自建就得一个个踩过去。

换来的是完全的掌控：数据在自己库里，想接什么接什么，性能不够就升配或加缓存。

Node 自建：给前端团队的路

如果客户团队本身是前端出身，Node 就是顺理成章的选择：前后端同一种语言，招人维护都方便，外包市场里 Node 小程序后端的报价也普遍友好。但那个团购客户的团队里没有任何技术人，前外包失联后连宝塔的登录密码都没人知道——对他来说，Node 自建等于把维护风险原样留在原地。选型不是选最好的技术，是选「出事的时候谁能在最短时间打开看」的那一个。

一棵能直接抄的决策树

已有系统要打通（进销存、ERP、桌面软件）→ 自建后端，优先复用现有数据库和业务逻辑。这一条几乎是决定性的：云开发再省事，也替代不了数据同源。

全新项目、逻辑简单、没有技术人（预约、展示、轻量商城）→ 云开发，把运维整个交给微信。

团队有前端、想自己长期维护 → Node 自建。

最后补一句很多甲方没想过的：自建的那套 WebAPI 不只是给小程序用的。同一个接口层，WPF 桌面端在吃，MAUI / uni-app 的 APP 也在吃。后端选型做得对，一次投入三端复用；做得不对，以后每上一个新端都要把后端重写一遍。

那个团购小程序重写后跑到现在，没再出过一次大规模超时。双十一早上那条报警短信的滋味，我替客户记着，也替「选型时没人问以后」这六个字记着。

---

有定制软件需求（.NET 桌面端 / 小程序 / APP），直接联系：微信/手机 17788568694

手机 17788568694 ｜ 微信 17788568694（与手机同号）｜ QQ 76656825