最稳妥方案是用 openssl_encrypt 配合 aes-128-cbc 或 aes-256-gcm 加密 json_encode 后的字符串，key 和 iv 必须严格符合长度与随机性要求，加密后 base64 编码传输，解密时顺序执行反向操作并校验参数一致性。
PHP 里用 openssl_encrypt 加密 JSON 字符串最稳妥
直接上结论：别用自定义 XOR 或 base64 做“假加密”，真要防明文传输，必须用 openssl_encrypt 配合 AES-128-CBC 或 AES-256-GCM。JSON 是纯文本，加密前先 json_encode 得到字符串，再整体加密，不是对数组结构操作。
常见错误是把 json_encode 后的字符串拿 base64_encode 包一层就当加密——这不算加密，只是编码，抓包一解就露馅。
-
openssl_encrypt要求明确指定 cipher、key、iv，缺一不可；用 AES-128-CBC 时 key 必须是 16 字节，不是“随便写个密码字符串” - iv 必须随机生成且每次不同，不能硬编码，但得和密文一起传给接收方（比如拼在密文前或用 JSON 封装）
- 加密后结果是二进制，必须用
base64_encode转成可传输字符串，解密时反向操作
解密失败报 “Failed to decrypt data” 或 “IV length mismatch” 怎么办
这类错误几乎都出在 iv 和 key 的长度/来源不一致。PHP 的 openssl_decrypt 对参数极其敏感，尤其 iv 长度必须严格匹配 cipher 要求（如 AES-128-CBC 要 16 字节）。
- 别用
md5($password)当 key——它输出 32 字符 hex，但 AES-128-CBC 要的是 16 字节原始字节，得用hex2bin(md5($password))或更稳妥的hash('sha256', $password, true) - iv 不能从 $_GET 或固定字符串读取，必须用
random_bytes(16)生成，且解密时用同一个 iv（所以通常和密文一起存或传） - 如果加密端用的是 GCM 模式，解密端没传
$tag参数或长度不对，也会直接失败——GCM 的 tag 是认证关键，不是可选
JSON 加密后体积暴涨，影响 API 响应怎么办
加密本身会让数据变大：AES-CBC 加密后 + PKCS#7 填充，base64 编码再放大 ~33%。如果原本 JSON 就几 KB，加密后可能翻倍，尤其移动端弱网下明显卡顿。
立即学习“PHP免费学习笔记（深入）”；
- 优先压缩再加密：用
gzencode压缩 JSON 字符串，再加密——但注意解密端必须按“解密 → gzdecode”顺序，顺序错就全乱 - 避免重复加密：不要对每个字段单独加密再拼 JSON，而是整包加密，减少 header 开销
- 如果只是防前端调试窥探，考虑用 HTTPS + 前端混淆（如字段名映射），比服务端加密更轻量；加密只用于真正需要保密的字段（如 token、用户 ID）
用 openssl_encrypt 时 PHP 版本和扩展依赖
PHP 5.3+ 内置 openssl 扩展，但低版本（如 5.3–5.5）不支持 AEAD 模式（如 AES-256-GCM），openssl_encrypt 调用会报错或静默失败。
- 检查是否启用：
extension_loaded('openssl')必须返回 true，否则函数不存在 - 确认可用 cipher：
openssl_get_cipher_methods()查看是否有aes-128-cbc，旧环境可能只有des-ede3-cbc（不推荐） - PHP 7.1+ 才完整支持 GCM 的
$tag参数；低于此版本强行传 tag 会被忽略，失去完整性校验
