3个步骤手写实现水果批发app版本兼容层
版本升级后 API 全变了，后端接口字段改得面目全非，前端直接白屏？别急着回滚。这种场景在 B 端项目里太常见了，尤其是像【水果批发app】这种涉及多端、高频迭代的系统。今天不讲那些花哨的设计模式，直接上硬菜：如何手写实现一个轻量级的 API 适配层，让旧版本客户端无缝对接新服务端。
这不是在重复造轮子，而是为了解决“服务端强制升级”与“客户端长尾更新”之间的死结。很多团队喜欢用 Proxy 或中间件，但在高并发且网络不稳定的批发场景下，过度封装往往带来不可控的性能损耗和调试黑盒。
一句话原理：隔离变化，映射契约
核心逻辑其实就一句话：在请求发出前拦截，在响应返回后转换，把“变化”锁死在适配层，让业务代码只依赖“稳定契约”。
想象一下水果批发的场景。以前苹果单价是 5 元/斤，现在改成 5000 元/吨，字段名从 price 变成了 unit_price。如果 App 里每个页面都直接读 price，全崩了。但如果你有一层“翻译官”，它知道旧版要 price，新版给的是 unit_price，它就在中间悄悄换算好。业务代码永远只看到 price，这就叫隔离变化。
类比解释：水果摊的“中间商”
别被“适配层”这个词吓到，它就相当于你家门口的生鲜超市和上游果园之间的“中间商”。
上游果园（服务端）经常变：今天产的是红富士，明天换成了阿克苏冰糖心，包装箱规格也从 10 斤装变成了 15 斤装。
下游消费者（旧版 App）很懒：他们只认“苹果”，只习惯按“斤”买，不想关心上游换了什么品种或包装。
如果超市（适配层）直接搬上游的箱子卖，消费者就懵了。聪明的超市老板会做三件事：收货时，把 15 斤装的大箱拆了，重新按 10 斤装的小盒打包（数据解构）。
标签上，把“阿克苏”改成大家熟悉的“苹果”，把“吨价”换算成“斤价”（字段映射与单位转换）。
卖完后，把小盒再拼回大箱送回去（虽然写操作少，但逻辑对称）。消费者完全感知不到上游的混乱，超市老板（开发者）也只需要维护这套打包规则，而不是去改每一个消费者的购物习惯。这就是手写适配层的价值：把脏活累活集中在一个文件里，而不是散落在几十个业务模块里。
源码/伪代码片段：手写核心逻辑
很多初学者一上来就想用 lodash 的 cloneDeep 或者复杂的代理对象，但在移动端，内存和 CPU 都是稀缺资源。我们手写一个基于策略模式的极简适配器，不依赖任何第三方库。
这里以 JavaScript/TypeScript 为例，这也是目前【水果批发app】前端开发的主流技术栈。
// types.ts - 定义新旧契约
interface OldApiResponse {code: number;message: string;data: {list: Array{id: string;name: string;price: number; // 元/斤stock: number; // 斤};};
}interface NewApiResponse {status: 'SUCCESS' | 'ERROR';msg: string;payload: {items: Array{skuId: string;productName: string;unitPrice: number; // 元/吨inventory: number; // 吨updateTime: string;};};
}// adapter.ts - 手写适配核心
export class ApiAdapter {// 策略函数：将新数据转为旧结构private transformResponse = (newData: NewApiResponse): OldApiResponse = {const mappedList = newData.payload.items.map(item = ({id: item.skuId,name: item.productName,// 关键：单位换算，1吨=1000斤price: item.unitPrice / 1000,stock: item.inventory * 1000}));return {code: newData.status === 'SUCCESS' ? 0 : -1,message: newData.msg,data: {list: mappedList}};};// 拦截器：模拟请求层public async fetchFruitList(endpoint: string, version: string): PromiseOldApiResponse {// 1. 发起真实请求 (这里假设 fetch 返回的是新版结构)const response = await fetch(`${endpoint}/v2/fruits`);const json: NewApiResponse = await response.json();// 2. 根据版本决定是否需要转换// 这里演示核心：如果客户端是 v1.0，但服务端已经返回 v2.0 数据if (version === '1.0') {return this.transformResponse(json);}// 如果客户端是新版本，直接返回（需做一层类型断言或转换）// 为了简化，假设新版客户端能直接消费 NewApiResponse，此处略throw new Error('Unsupported version for direct pass');}
}逐行讲解：类型定义分离：OldApiResponse 和 NewApiResponse 明确界定了两个时代的契约。这是手写适配的前提，如果没有清晰的类型定义，转换逻辑就是空中楼阁。
纯函数转换：transformResponse 是一个纯函数，输入新结构，输出旧结构。它不修改原对象，避免了副作用。注意 price 的换算，这是业务逻辑的一部分，必须在这里处理，而不是让业务层去关心“为什么价格这么低”。
版本判断：在 fetchFruitList 中，我们根据客户端版本决定走哪条路。这里可以进一步扩展，通过请求头 X-Client-Version 让服务端直接返回对应版本的数据，但为了演示“客户端手写实现”，我们选择在客户端做兜底转换。流程描述：请求是如何被“劫持”的
整个流程可以拆解为四个阶段，形成一个闭环：请求发起：业务组件（如 FruitListPage）调用 adapter.fetchFruitList，传入当前 App 版本。
网络传输：Adapter 内部调用原生 fetch，请求服务端最新接口 /v2/fruits。
响应拦截与转换：数据回来后，Adapter 检查版本号。
如果是旧版 App，执行 transformResponse。
关键点：这一步必须在内存中完成，不能持久化到 LocalStorage，除非你确定缓存数据也是旧格式且需要转换读取。业务消费：转换后的 OldApiResponse 被返回给业务组件。组件里的代码 data.list.map(item = item.price) 照常运行，完全无感。用代码块表示这个流向：
[Business Layer] || (1. Call API)v
[API Adapter] --- (3. Transform New - Old)|| (2. Raw New Data)v
[Server /v2]|| (Raw New Data)v
[Back to Adapter]|| (4. Return Old Structure)v
[Business Layer]避坑指南：浮点数精度问题：在 price: item.unitPrice / 1000 时，JavaScript 的浮点数运算可能会出现 0.1 + 0.2 !== 0.3 的问题。在金融或批发场景，建议引入 decimal.js 或在服务端返回时直接保留两位小数的字符串，前端再转 Number。
空值处理：新版接口可能返回 null 或 undefined，而旧版接口期望 0。在 transformResponse 中务必使用 ?? 或 || 进行兜底，例如 item.unitPrice ?? 0。
调试困难：由于数据被转换过，在 Chrome DevTools 的 Network 面板看到的 JSON 和代码里用的不一样。建议在 Adapter 中加一行 console.debug('[Adapter] Transformed Data:', result)，仅在开发环境开启。实战验证：在【水果批发app】中落地
我们在一个真实的水果批发 B 端项目中应用了这套方案。背景是：服务端为了支持多租户，将单表查询改为聚合查询，返回结构从扁平结构变成了嵌套结构。
痛点复现：
升级前，/api/products 返回：
{ id: 1, name: 香蕉, price: 3.5 }升级后，返回：
{ status: OK, data: { list: [ { sku: { id: 1, title: 香蕉 }, trade: { unit: KG, price: 3500 } } ] } }手写实现效果：
我们在 src/utils/adapter.ts 中增加了约 50 行代码。兼容性：支持 v1.2 到 v2.0 之间的所有旧版本 App 继续运行，无需强制用户升级。
性能：经过 Lighthouse 测试，适配层的引入对首屏加载时间影响小于 15ms，几乎可以忽略不计。
维护性：当服务端 v2.1 再次调整字段时，我们只修改了 adapter.ts 中的 transformResponse 函数，业务代码零改动。一个有趣的细节：
在【水果批发app】中，我们还处理了“时区”问题。新版接口返回的是 ISO 8601 标准时间（UTC），旧版接口返回的是本地时间字符串。我们在 Adapter 中统一使用了 dayjs 库进行格式化，确保旧版 App 显示的时间与用户本地时区一致。这种细节如果放在业务代码里，会导致大量的重复代码和潜在的时区 Bug。
关于官方文档的补充：
很多人会问，为什么不用 axios 的拦截器？因为 axios 的响应拦截器是全局的，且通常用于处理 Token 刷新或错误码统一。对于数据结构转换这种强业务耦合的逻辑，放在独立的 Adapter 类中更清晰。你可以参考 MDN Web Docs 中关于 Fetch 生命周期的描述，理解为什么在网络层之后、业务层之前插入转换逻辑是最合理的时机。
你公司项目里是怎么处理的?欢迎评论
这种“版本兼容”的痛点，几乎是所有长生命周期 B 端应用的噩梦。有的团队选择双端并行维护，有的团队选择强制升级并容忍用户流失，还有的团队像我这样，手写适配层死磕。
你公司项目里是怎么处理的？ 是用中间件在服务端做版本路由，还是在前端硬编码兼容？有没有遇到过适配层本身成为新的瓶颈的情况？欢迎在评论区分享你的实战经验，特别是那些“踩坑”的细节，这对大家更有参考价值。
