微信小程序如何优雅封装请求，告别重复代码与混乱逻辑

写代码这事，最怕的就是重复。尤其是微信小程序里的网络请求，刚入门的同学可能觉得不就是 wx.request 吗，写完就行了。但项目一复杂起来，同一个接口调三次，每次还得写同样的 header、同样的 loading、同样的错误处理，那画面简直不忍直视。今天咱们就来聊聊，怎么把这堆重复逻辑封起来，让代码清爽得像刚擦过的玻璃。

先说说最基础的痛点。很多小程序的请求代码长什么样呢？每个页面里直接怼上 wx.request，success 里写数据处理，fail 里写 toast 提示，complete 里关 loading。一个页面三五个接口，复制粘贴改改参数，看着好像挺快。但问题来了——如果有一天后端改了接口前缀，你得一个个页面去改；如果想统一加个 token 校验，又得翻遍所有文件。这哪是写代码，这是给人添堵。所以封装的第一步，就是把这些公共逻辑抽出来，做个统一的请求函数，而不是让每个页面都直接调 wx.request。

那这个统一函数长什么样呢？简单说，就是把 wx.request 包一层，把每次都要写的配置项——比如 baseUrl、header、超时时间——提前设好。然后暴露一个函数，外面调用时只需要传 url、method、data 这些变化的部分。比如写个叫 request 的函数，内部把 token 从 storage 里取出来塞到 header 里，再统一处理一下状态码——401 跳登录，200 走成功，其他弹错误。这样每个页面的调用代码就从七八行缩成了两三行，而且所有请求的行为都是一致的，改一处全变。

但光有一个 request 函数还不够。你会发现，很多接口返回的数据结构类似，都包在 data 字段里，或者都有个 code 字段表示业务状态。这时候就需要加一层拦截器。拦截器说白了就是请求发出去之前和响应回来之后，让你有机会插一脚。请求前可以拼参数、加 loading；响应后可以统一解析数据、弹错误提示。这比在每个调用处都写一遍 if 判断要优雅得多。可以用 Promise 把整个过程串起来，让调用者只关心业务数据，错误和异常交给拦截器兜底。

再说说更实际的问题——loading 和错误处理。很多同学喜欢在每个请求里自己调 wx.showLoading 和 wx.hideLoading，结果就是 loading 满天飞，用户点一下按钮弹三个圈。理想的做法是在封装层统一控制 loading 的开关。比如用个计数器，请求开始加一，结束减一，计数器归零时才真正关闭 loading。这样即使同时发起三个请求，也只会在第一个请求开始时弹出 loading，在最后一个请求结束时关闭它。错误处理也一样，别让每个页面都写 toast，封装层统一弹，除非某个页面有特殊需求，再提供自定义错误回调的入口。

还有一个容易被忽视的点——请求的取消。用户在小程序里操作，点了按钮请求还没回来，又点了一下。如果不处理，前一个请求的回调可能会覆盖后一个的结果，甚至两个请求都成功导致数据错乱。可以在封装层为每个请求生成唯一标识，维护一个请求池。新请求发起时，如果发现相同标识已经在池中，就先用 abort 方法取消旧请求，再发新请求。这样既省流量，又避免竞态问题，用户体验也会好很多。

代码写到这里，其实已经相当完备了。但如果想让团队用得更顺手，还可以再加一层高阶封装。比如针对常见的 CRUD 操作，做成独立的模块——create、read、update、delete 各一个函数，内部自动拼路径、处理参数。再比如针对分页列表，封装一个通用的分页请求函数，自动管理 page 和 pageSize，自动处理加载更多和下拉刷新的逻辑。这样业务层的人根本不需要关心底层怎么发请求，拿来就能用，出问题也只需要在封装层定位，效率翻倍。

说几句实在的。封装不是一蹴而就的事，也不是越复杂越好。刚开始，只需要把重复的配置抽出来，加上统一的 loading 和错误处理就行了。等业务复杂了，再慢慢加拦截器、取消机制、分页模块。别一开始就搞个上百行的框架，结果连自己都看不懂。记住一句话：好的封装让调用者写更少的代码，做更多的事，同时让维护者一眼就能看出逻辑。把请求封装好后，小程序开发至少爽一半。