必须由用户主动选择文件后用filereader读取arraybuffer，再交web crypto api解密；因浏览器禁止file://协议下所有fetch跨源请求，即使同目录也会触发net::err_failed或cors错误。
不能直接读取本地加密文件，必须由用户主动选择文件，再用 FileReader 读取原始数据，最后用 Web Crypto API 解密。整个流程绕不开用户交互和浏览器安全限制。
为什么不能用 fetch('file://') 读加密文件
浏览器禁止所有 file:// 协议下的跨源请求，哪怕文件就在同目录下，也会触发 CORS 错误或 net::ERR_FAILED。这不是代码问题，是协议层硬性拦截。加密文件哪怕只是个 .enc 后缀，也得走 File API 这条合规路径。
读取 + 解密两步不能合并
FileReader 只负责把文件变成 ArrayBuffer 或字符串，它不做解密；Web Crypto API 负责解密，但它不接触文件路径。两者必须分步协作：
- 用户通过 或拖放选中加密文件
- 用 reader.readAsArrayBuffer(file) 获取原始字节（避免文本编码干扰）
- 在 reader.onload 中拿到 ArrayBuffer，传给 crypto.subtle.decrypt()
- 解密后得到明文 ArrayBuffer，再根据类型转成 Blob、TextDecoder.decode() 或 URL.createObjectURL()
解密前要确认结构是否匹配
加密时怎么封装，解密时就得怎么拆。常见结构有三类：
- IV + 密文 + AuthTag（GCM 推荐）：解密前需从 ArrayBuffer 开头截出 12 字节 IV，末尾取 16 字节 Tag，中间为密文
- Base64 JSON 包裹：如 { "iv": "base64", "data": "base64", "salt": "base64" }，需先 JSON.parse，再 Base64 解码各字段
- 服务端预加密格式：比如 CryptoJS AES-CBC 输出的 OpenSSL 兼容格式，需用对应算法和填充方式（如 Pkcs7）还原
安全细节不能跳过
解密失败常因忽略关键约束：
- 页面必须运行在 HTTPS 或 localhost，否则 crypto.subtle 会静默不可用
- 密钥导入要用 importKey("jwk" 或 "raw")，权限必须含 "decrypt"，否则报错
- IV 绝对不可复用，每次加密都应新生成；解密时若 IV 错位 1 字节，整个结果全乱
- 大文件解密易卡顿，可考虑分块处理（Web Crypto 不原生支持流式，需手动切片+拼接）
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
