微信小程序和后端代码nodejs

小程序能不能离开后端单独跑？微信能，但基本只能做个计算器。小程序和只要涉及用户登录、后端数据存储、代码支付、微信消息推送，小程序和后端就是后端绕不过去的坎。微信小程序官方给的代码方案里，Node.js 是微信最顺手的那一个——不是因为它是唯一选择，而是小程序和因为前后端都是 JavaScript，省掉了切换语言的后端心智负担。

我去年帮一个做社区团购的代码团队搭过一套小程序，前端用原生 WXML + WXSS，微信后端就是小程序和 Node.js + Express。整个项目从零到上线两周，后端代码量不到三千行。这不是炫耀速度，而是想说：技术选型对了，很多麻烦根本不会出现。

登录态：小程序和后端的第一道握手

小程序端调用 wx.login() 拿到一个临时 code，这个 code 只能用来换 openid。真正要做的，是把 code 发给自己后端，后端拿 code + appid + secret 去请求微信接口，换回 openid 和 session_key。session_key 绝对不能下发到小程序端——这是很多新手踩的坑。

Node.js 这边用 axios 或 node-fetch 发这个请求就行。拿到 openid 后，生成一个自定义的 token（JWT 最省事），存进数据库或者 Redis，返回给小程序。之后小程序每次请求带上这个 token，后端校验即可。整个过程没有魔法，就是标准的 OAuth 变体。

数据接口：别把 GraphQL 当银弹

有人一上来就上 GraphQL，觉得 REST 太土。但小程序的网络请求能力有限，wx.request 不支持批量查询，GraphQL 的优势根本发挥不出来。我见过一个项目硬上 Apollo Server，结果每个页面都要写一段冗长的 query，调试时连错误信息都看不全。

RESTful 接口在小程序场景下反而更直接。一个 GET /api/products?page=1 返回 JSON，小程序端 wx.request 拿到后 setData，完事。简单、可缓存、易调试。Node.js 用 Express 或 Koa 写路由，配合 mysql2 或 mongoose 操作数据库，半小时能搭出五六个接口。

支付回调：Node.js 的异步优势

微信支付的回调是 POST 请求，微信服务器会等你响应。如果你用 PHP 或 Java 写同步阻塞的代码，回调处理慢了，微信会重复通知。Node.js 的事件循环在这里很舒服——收到回调后先返回 <xml><return_code>SUCCESS</return_code></xml>，然后再异步处理订单状态更新、库存扣减、消息推送。

注意，返回的 XML 必须严格符合微信格式，大小写都不能错。我见过有人返回 JSON，微信直接判定失败，连续重试八次。Node.js 里用 xml2js 解析和构造 XML 很稳定，比手写字符串拼接靠谱得多。

部署：别把 Node.js 当 PHP 用

Node.js 是单线程的，一个未捕获的异常就能让整个进程挂掉。用 pm2 做进程守护是基本操作，但更关键的是：不要在小程序后端里做 CPU 密集型任务。图片压缩、视频转码这些活，扔给专门的微服务或者云函数。我见过一个团队在 Express 里用 sharp 批量处理用户上传的图片，结果请求一多，事件循环直接卡死，小程序端全部超时。

数据库连接池也要配好。mysql2 的 connectionLimit 默认是 10，小项目够用，但活动期间并发一上来，连接不够就会排队。调到 50 左右，配合 queueLimit 限制排队数量，能避免雪崩。

一个具体的坑：wx.request 的 content-type

小程序端 wx.request 默认的 content-type 是 application/json，但如果你后端用 body-parser 的 urlencoded 中间件，解析就会失败。要么前端改 header，要么后端同时挂 json 和 urlencoded 两个中间件。这个坑我踩过两次，每次都是调试半小时才想起来。

Node.js 写小程序后端，没什么高深技术，就是细节多。把登录、接口、支付、部署这四个环节的坑填平，剩下的就是业务逻辑了。工具选对了，写代码的时间其实比查文档的时间少。

本文地址：http://www.79wt.cn/news/90d1899891.html