日常 MD5 用 js-md5，要同时做 AES 加解密就选 crypto-js；前者体积小、无环境依赖、多端兼容，后者功能全但体积大、需注意子模块引入和 Node.js 兼容性问题。
uni-app里该选 js-md5 还是 crypto-js
直接说结论：日常 md5 用 js-md5，要同时做 aes 加解密就选 crypto-js。前者体积更小（仅 3kb 左右），纯 md5 场景启动快、无副作用；后者功能全但体积大（20kb+），在小程序里可能触发代码包超限警告。
常见错误现象：crypto-js 在微信小程序中报 Cannot find module 'crypto' 或 H5 正常但 App 端加密结果不一致——本质是它默认依赖 Node.js 环境的 crypto 模块，而 uni-app 多端运行时并不提供。
-
js-md5是纯 JS 实现，无环境依赖，H5 / 微信小程序 / App（v2/v3）全部开箱即用 -
crypto-js需确保只调用其浏览器兼容子模块，比如import MD5 from 'crypto-js/md5'，避免引入crypto-js/core全量包 - 如果项目已装
crypto-js且只用 MD5，可继续用；但新项目建议从js-md5起手，后续再按需叠加 AES
MD5 加密必须加盐，否则等于没加
单纯对密码 md5('123456') 是典型的安全反模式。MD5 本身不可逆，但彩虹表一查一个准，'123456' 的 MD5 值全球开发者都背得出来。
真实使用场景下，后端通常要求「前端加盐 + 后端再加盐 + 多次哈希」，至少做到前端层面不裸传明文或弱哈希。
- 盐值不能写死，比如
md5(password + 'abc')—— 盐一旦泄露，所有用户密码批量失效 - 推荐用动态盐：拼接用户名、时间戳、设备 ID（
uni.getSystemInfoSync().deviceId）、或服务端下发的一次性 salt - 示例：
const salt = this.username + Date.now().toString().slice(-6); const hash = md5(this.password + salt); - 注意：盐值需和加密结果一起传给后端，否则后端无法校验
在 main.js 全局挂载 md5 函数最省事
登录页、注册页、修改密码页……到处都要 MD5，每个 .vue 文件都 import md5 from 'js-md5' 不仅重复，还容易漏更新版本或路径出错。
实操建议：在 main.js 中统一挂载，所有组件内直接用 this.$md5()，干净又可靠。
- 安装后，在
main.js顶部加：import md5 from 'js-md5'; Vue.prototype.$md5 = md5;（v2）或const app = createSSRApp(App); app.config.globalProperties.$md5 = md5;（v3） - 组件中调用：
this.$md5('hello')，无需再 import - 注意兼容性：App 端若用 nvue 页面，
this上下文不共享 Vue 实例，仍需局部 import；H5 和小程序页面才真正受益于全局挂载
AES 加密别硬套后端示例，先确认模式和填充方式
很多同学复制后端给的 Java/PHP 示例代码，直接粘贴进 uni-app，结果加密结果对不上——大概率是 mode（CBC/ECB）、padding（Pkcs7/ZeroPadding）、iv（是否固定/是否 base64 编码）三者之一不一致。
尤其注意：uni-app 的 crypto-js 默认 padding 是 Pkcs7，而部分 Java 后端用的是 ZeroPadding；iv 若用字符串而非 WordArray，也会导致解密失败。
- 务必和后端对齐这三项：
mode、padding、iv类型（如CryptoJS.enc.Utf8.parse('16-byte-iv-str')） - 避免用 ECB 模式（不安全），优先用 CBC，并确保每次请求生成随机
iv，和密文一起传输 - 小程序中 AES 加密若报错
encrypt is not a function，检查是否漏引crypto-js/aes子模块，而不是只引了crypto-js根包
真正麻烦的从来不是“怎么写那几行加密代码”，而是前后端对齐加盐逻辑、AES 参数、以及多端运行时的环境差异。加盐方式、IV 生成策略、密钥管理——这些细节没对齐，写得再漂亮也白搭。
