微信小程序与H5端读取图片的ArrayBuffer内容不一致，因小程序平台会自动解码图像为RGBA像素数据，导致MD5计算错误；应统一转base64再转Uint8Array，或使用js-md5直接处理Uint8Array。
微信小程序和 H5 端读取图片得到的 ArrayBuffer 内容不一致，直接丢给 CryptoJS.MD5() 会算出固定错误值（比如 487f7b22f68312d2c1bbc93b1aea445b），这不是 crypto-js 本身的问题，而是 ArrayBuffer 数据来源不同导致的二进制内容差异。
uni-app 中 FileReader 与 FileSystemManager.readFile 返回的 ArrayBuffer 不等价
浏览器用 FileReader.readAsArrayBuffer(file) 读的是原始文件字节流；微信小程序用 uni.getFileSystemManager().readFile() 读的是临时路径下的文件——但这个“临时路径”在 iOS 和 Android 上行为不一致，且部分版本会自动解码 PNG/JPEG 为 RGBA 像素数据（尤其 iOS），导致 ArrayBuffer 内容被篡改。
- 现象：同一张图，在 H5 算出正确 MD5，在小程序里始终固定不变
- 本质：小程序端读到的不是原始二进制，而是经过平台内部处理后的图像数据（类似 canvas getImageData 后的结果）
- 验证方法：打印
arraybuffer.byteLength，对比 H5 和小程序是否一致；不一致就说明数据已失真
正确做法：统一走 base64 → Uint8Array 路径
绕过平台对 ArrayBuffer 的隐式处理，把图片转成 base64 字符串再转回字节数组，能保证两端输入一致。关键点是：必须用 uni.getFileSystemManager().readFile() 读取后调用 uni.arrayBufferToBase64()，而不是直接传 res.data 给 crypto-js。
- H5 端：用
FileReader读取后，e.target.result是ArrayBuffer，先转 base64：const base64 = btoa(String.fromCharCode(...new Uint8Array(e.target.result))) - 小程序端：用
uni.arrayBufferToBase64(res.data)得到 base64 字符串 - 两端都执行：
const bytes = atob(base64).split('').map(c => c.charCodeAt(0))→ 得到Uint8Array - 再交给
CryptoJS.lib.WordArray.create(bytes)计算 MD5
更轻量、更兼容的替代方案：用 js-md5 直接处理 Uint8Array
js-md5 支持直接传 Uint8Array，无需依赖 crypto-js 子模块，体积小、无 Node.js 兼容问题，且多端表现一致。
- 安装：
npm install js-md5 - 使用：
import md5 from 'js-md5'; const hash = md5(new Uint8Array(bytes)); - 注意：不能传 base64 字符串进去，必须是字节数组；传字符串会按 UTF-8 编码再哈希，结果错乱
- 如果已有 crypto-js，确保只引入子模块：
import MD5 from 'crypto-js/md5'，避免全量包触发小程序构建警告
上传前校验 MD5 的实际落地建议
别在前端“硬算”大图 MD5——10MB 图片在低端安卓机上可能卡顿 2–3 秒。真实项目中应分场景处理：
- 小图（
- 大图或批量上传：前端跳过 MD5，改用服务端返回的预签名 URL + 上传后回调校验（如 OSS 的
Content-MD5header 校验） - 必须强校验时：优先用 SHA256（
js-sha256），MD5 已不适合安全敏感场景 - 调试技巧：把算出的
Uint8Array前 32 字节用console.log([...bytes.slice(0,32)].map(b => b.toString(16).padStart(2,'0')).join(''))打印出来，对比两端是否一致
真正容易被忽略的点是：小程序里 filePath 必须是本地临时路径（tempFilePaths），不能是网络地址或 base64 字符串；而 H5 的 file 对象也必须来自 input[type=file] 或 uni.chooseImage，不能是 canvas.toDataURL() 生成的 base64——后者已经过编码压缩，不再是原始字节。
