fetch 不处理加密解密，需手动解析响应体后再解密；必须先用 text() 或 arraybuffer() 读取原始数据，避免“body 已被使用”错误；支持 base64、aes、自定义混淆等解密方式，并建议通过拦截器封装自动解密逻辑。
Fetch 本身不处理加密解密，它只负责发起请求和接收原始响应；解密必须在拿到 Response 后，手动对响应体内容做解析和解密操作。关键在于：先正确读取响应数据（如 text() 或 arrayBuffer()），再用对应算法（如 AES、RSA、Base64 等）还原明文。
先读取原始响应体，避免“Body 已被使用”错误
Fetch 的响应体是流式、一次性消耗的。如果直接调用 response.json()，后续就无法再读取原始密文了。所以解密前必须用合适的方法获取原始字节或字符串：
- 若响应是 Base64 编码字符串（如
{"data": "YmFzZTY0IGVuY29kZWQ="}），用response.text()获取字符串，再提取并解码 - 若响应是二进制密文（如 AES 加密后的字节流），用
response.arrayBuffer()获取原始字节，再传给解密函数 - 若需同时校验和解密（比如先看
code字段再决定是否解密），可用response.clone()复制一份响应，分别用于检查状态和解密
常见解密场景与对应处理方式
不同加密形式需要匹配不同的解密逻辑，不能一概而用 .json()：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
-
Base64 密文：用
CryptoJS.enc.Base64.parse(str).toString(CryptoJS.enc.Utf8)或原生atob()（注意 UTF-8 兼容性） -
AES/ECB 或 AES/CBC 加密：需完整密钥、IV（如有）、填充方式（如 PKCS7）。推荐用
crypto-js或 Web Crypto API（window.crypto.subtle.decrypt） - 自定义混淆或轻量加密（如异或、移位、简单替换）：直接写 JS 函数逆向还原，通常从网页源码中定位解密函数后复用逻辑
-
签名验证 + 解密分离：先校验
sign字段（如 MD5、HMAC），再对data字段解密，失败时统一抛错
解密后还原成标准响应结构
解密完成，应把结果重新组织为业务可消费的数据格式：
- 若解密结果是 JSON 字符串（如
"{\"code\":0,\"data\":{\"id\":1}}"），需JSON.parse()转为对象 - 若解密后是二进制（如图片、PDF），可用
new Blob([uint8Array])构造，再生成 URL 预览或下载 - 建议封装统一解密函数，接收
response和配置（如algorithm: 'aes-ecb',key: 'xxx'），返回 Promise
结合拦截器实现自动解密
在二次封装的 Fetch 中，可把解密逻辑注入响应拦截器，做到请求发出后自动处理：
- 响应拦截器收到
{ response, data }后，检查响应头或响应体中是否存在encrypted: true标识 - 根据接口约定（如路径含
/v2/secure或返回字段含cipher）触发对应解密流程 - 解密失败（如密钥错误、格式不符）时，仍抛出带
response原始信息的 Error，方便上层捕获并提示“解密异常” - 保留未加密接口的直通能力——通过配置项（如
decrypt: false）跳过解密步骤
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
