微信小程序wx.request

聊微信小程序开发，绕不开一个核心接口——wx.request。如果你写过小程序，肯定跟它打过交道，它就像小程序和服务器之间的传话筒，负责把前端的数据发过去，再把后端的响应拿回来。说白了，没有它，你的小程序就是个孤岛，登录、支付、数据展示全得趴窝。很多新手一上来就对着文档吭哧吭哧调接口，结果被各种坑绊倒，比如跨域问题、参数格式不对、回调地狱。其实wx.request没那么玄乎，理解它的本质，再踩几个常见坑，你就能玩得转。

先说说wx.request到底干了啥。它是个异步请求接口，底层封装了HTTP协议，支持GET、POST、PUT、DELETE这些常用方法。你写个配置对象，填上URL、data、header，然后等success或者fail回调触发。举个最简单的例子：用户登录时，你把code传到后端换openId，代码就是wx.request({ url: ' data: { code }, success: res => console.log(res) })。看起来简单？但很多人栽在URL上。微信小程序的请求域名必须提前在后台配置白名单，而且只能用HTTPS，不能用localhost调试。有个朋友第一次开发，直接写http://127.0.0.1:3000，跑了一天报错，发现是小程序默认屏蔽非安全请求。这种低级错误，文档里写得明明白白，但新手就是容易忽略。

参数传递的坑更隐蔽。wx.request的data参数，默认会序列化成JSON字符串发送，但如果你用POST方法，得注意Content-Type。默认是application/json，后端如果解析不了，就得手动改header。比如你传个表单数据，得写成header: {'content-type': 'application/x-www-form-urlencoded'}，然后data里用键值对。我见过一个项目，前端传了JSON，后端用PHP的$_POST死活接不到，排查半天才发现是类型不匹配。还有，data里不能直接传数组或嵌套对象？其实可以，但后端得按JSON解析。你传个{list: [1,2,3]}，后端用json_decode就能拿到数组。可有些人非要用字符串拼接，搞出一堆bug。记住：统一用JSON，双方约定好结构，省心省力。

回调地狱是wx.request的另一个痛点。小程序里，请求往往嵌套：先获取用户信息，再根据信息请求数据，更新页面。串行写下去，代码就变成这样：wx.request({...success: wx.request({...success: ...})})。三层以上，逻辑乱成一锅粥，改个需求得翻半天。有人用Promise封装，把wx.request包一层，返回一个Promise对象，然后链式调用。比如：function request(url, data) { return new Promise((resolve, reject) => { wx.request({ url, data, success: resolve, fail: reject }) }) }。然后就能写request('/a').then(res => request('/b', res.data)).then(...)。这样清晰多了。但别忘了处理错误，fail回调里得reject，不然捕获不到异常。还有，wx.request本身不支持取消请求，如果你在页面跳转后还发请求，可能引发内存泄漏。解决办法是在onUnload里用complete标志位，或者用第三方库如axios的CancelToken。但这些细节，文档不会手把手教你。

数据绑定和请求配合时，容易出性能问题。很多人每次请求成功，直接setData更新整个页面，导致渲染卡顿。比如列表页，一次请求返回100条数据，你setData({list: res.data})，小程序得重新渲染整个列表。优化方案是分页加载，或者用局部更新。比如只更新某个字段：this.setData({ 'list[0].name': '新名字' })，这样只触发部分渲染。还有，请求超时时间默认60秒，但有些场景需要更短。比如扫码支付，用户等太久会不耐烦。你可以设置timeout参数，比如100毫秒。但注意：超时后触发fail回调，你得自己处理重试逻辑。有个电商小程序，下单接口偶尔超时，用户点一次没反应，再点一次就重复下单。后来加了防抖和重试机制，才解决问题。

跨域和安全性也得提一嘴。小程序的wx.request没有跨域问题，因为它不走浏览器同源策略，但得配置服务器域名白名单。每个请求的referer是固定格式，比如，后端可以通过这个做简单校验。但别依赖这个，因为referer可以被伪造。真正得防的是CSRF攻击。比如用户登录后有个修改密码接口，如果没加token校验，攻击者可以诱导用户点链接，用你的cookie发请求。解决方案是每次请求在header里带一个自定义token，后端验证。wx.request的header支持自定义字段，你可以写header: {'X-Token': token}。还有，敏感数据不要明文传，比如密码、身份证号，得用HTTPS加密，或者前端加一层加密。但别想着前端加密能防住黑客，因为代码在小程序包里是可见的，真正安全靠后端。

说说wx.request的替代方案。如果你需要上传文件，用wx.uploadFile；下载文件用wx.downloadFile；WebSocket实时通信用nnectSocket。这些接口和wx.request底层原理类似，但针对特定场景做了优化。比如上传文件，它会自动处理multipart/form-data格式。还有个冷门但实用的接口——wx.requestPayment，它其实是调用微信支付，底层不是HTTP请求，而是微信内部通信。别混淆了。回到wx.request本身，它的核心价值在于稳定、简单。微信团队一直在优化，比如支持请求队列、自动重试，但这些功能得靠你自己封装。我建议你把wx.request封装成一个工具函数，统一处理错误、loading状态、token过期重定向。比如所有请求前显示loading，成功后隐藏，失败时弹出toast。这样代码复用率高，维护成本低。你不需要记住每个接口的细节，但得理解它的边界——它只是个基础工具，真正的业务逻辑在你手里。