微信小程序请求管理：从混乱到有序，告别头皮发麻

刚接手一个小程序项目，产品经理甩过来一张原型图，上面密密麻麻写着接口调用需求。我盯着屏幕发呆，脑子里蹦出的第一个问题不是“这个功能怎么实现”，而是“这几十个请求到底该怎么管理”。如果你也经历过这种时刻，应该能懂那种头皮发麻的感觉——不是不会发请求，而是怕请求乱七八糟，后续维护起来想死。

其实微信小程序的请求机制，说白了就是一套基于 HTTPS 的 API 调用。官方提供了 wx.request 接口，基础用法简单到看一眼文档就会。但真正坑人的，是那些细节：域名必须提前配置，TLS 版本要 1.2 以上，请求超时默认 60 秒，还有开发者工具和真机表现不一致的问题。我见过太多人，在本地开发环境跑得好好的，一上真机就报错，找半天才发现是域名白名单没加。这种坑踩过一次，下次就长记性了。

说到域名白名单，这可能是小程序请求里最让人烦躁的设置之一。每个小程序都得在后台配置 request 合法域名，而且必须是 HTTPS。用 HTTP 直接报错，连商量的余地都没有。更坑的是，开发调试阶段，你可能会频繁切换域名——测试服、预发服、正式服，每个都得提前配好，不然就只能看到 “request:fail” 的提示。我有个同事，上线前一天忘了配正式服域名，结果用户一打开就白屏，紧急发版才救回来。这教训够深刻吧。

请求封装是每个小程序项目绕不开的坎。你不可能每个页面都写一遍 wx.request，那会累死人，而且代码也会变得难看。常见的做法是建一个 api.js 文件，把基础 URL、请求头、超时时间这些公共参数提取出来，然后封装 get、post、put、delete 几个方法，再结合业务逻辑，把每个接口写成独立函数。比如用户登录、获取列表、提交表单等，都单独封装。这样后期改接口地址或加 token 校验，只需要改一个地方，省心省力。但封装有个坑——别过度设计。我见过有人封装了五层，拦截器、重试机制、缓存策略全塞进去，结果出 bug 查半天。简单够用就好，别炫技。

请求失败的处理往往被新手忽略。很多人写完请求，只处理成功回调，失败就扔个 console.log。但用户不是开发者，他们看到“网络异常”这种提示，第一反应是“这 App 真垃圾”。所以，你得给用户一个友好的反馈：加载中的 loading 状态、失败时的重试按钮、断网时的离线提示。我习惯在封装层统一处理错误，比如状态码非 200 时，弹个 Toast 提示“服务器开小差了”，同时把错误日志上报到监控平台。这样用户感受好，排查问题也方便。有一次线上出现 500 错误，后台日志一片空白，但监控平台早就记录了，十分钟内就定位了问题。

性能优化这块，小程序请求有自己的脾气。并发限制：同一个域名最多并发 10 个请求，超过的会排队等待。如果页面刚加载就同时发十几个请求，后面的会卡住，体验极差。解决办法是分批加载，或者把不紧急的请求做延迟处理。还有数据缓存：对于不经常变动的数据，比如用户信息、配置参数，可以用 wx.setStorageSync 存起来，下次请求前先读缓存，没更新就别再发。我优化过一个首页，原来每次打开都要请求 5 个接口，加载要 3 秒；改成缓存策略后，首屏几乎秒开，用户反馈明显变好。

还有个小细节容易被忽略——请求头的设置。很多后端接口对 Content-Type 有严格要求，比如必须是 application/json，或者 application/x-www-form-urlencoded。如果传错了，后端解析不出来，直接返回 400。更坑的是，有些后端要求自定义 header，比如加个 X-Request-Id 用于链路追踪，或加 Authorization 用于鉴权。这些都得在前端封装时处理好。我遇到过最离谱的一次，后端说“你们前端传的 token 格式不对”，查了半天才发现是 header 里多了个空格。所以说，处理请求头时，细致一点总没错。

聊聊请求的生命周期管理。小程序页面有 onLoad、onShow、onHide 等生命周期，请求最好跟页面绑定。比如用户在 A 页面发起请求，还没返回就跳转到 B 页面，这时 A 页面的回调仍会执行，可能会报错。解决办法是在页面卸载时取消请求，或者用状态标记判断页面是否还在。wx.request 本身不支持取消，但可以用一个标志位来控制：页面卸载时把标志位设为 false，回调里判断后再执行后续逻辑。这样能避免很多奇怪的 bug，尤其是低配手机上复现的偶发问题。

写小程序请求，说难不难，说简单也不简单。它不像后端那样需要处理高并发、分布式，但也得考虑用户体验、代码维护和稳定性。我见过太多人，一开始图省事，直接在每个页面写 wx.request，结果项目大了，改个接口地址要翻几十个文件。也见过有人过度封装，把请求搞成黑盒子，出了问题根本不知道哪里报的错。所以，平衡点很重要——封装得够用，但别复杂到影响排查。就像做饭，盐放多了咸，放少了淡，恰到好处才好吃。下次面对一屏幕的接口调用，不妨先花十分钟想清楚请求怎么组织，后面能省下十个小时的改 bug 时间。