不能直接用 md5() 或 sha1() 存订单日志，因为它们是单向哈希函数，不可逆，无法还原原始日志内容，而订单日志需审计、对账、客服查询，必须可解密；哈希适合存密码，不适合需还原的日志。
为什么不能直接用 md5() 或 sha1() 存订单日志
这两个函数是单向哈希，不是加密 —— 你存进去的是“张三下单 100 元”，哈希后变成一串固定长度字符串，但完全无法还原原始内容。订单日志通常需要后续审计、对账、客服查询，必须能解密回明文。用哈希等于主动丢数据，不是加密，是自废武功。
常见错误现象：md5($log) 存库后发现查不到原始操作人、金额、时间戳，只能靠猜；或者误以为加盐（md5($log . $salt)）就算安全，其实仍不可逆、无保密性。
- 哈希适合存密码，不适合存需还原的日志
- 日志加密核心诉求：可逆、可控密钥、抗重放、防篡改（最好附带完整性校验）
- PHP 7.2+ 推荐走
openssl_encrypt()/openssl_decrypt()，别碰已废弃的mcrypt_*
用 openssl_encrypt() 加密订单日志的最小可行写法
关键不是“能不能用”，而是选对算法、模式、密钥和 IV。推荐 AES-256-CBC：兼容性好、PHP 原生支持、硬件加速普遍。别用 ECB 模式（相同明文块加密结果一样，极易被模式分析），也别手动生成 IV 并硬编码。
$log = "order_id=ORD-2024-789;user_id=U1002;amount=299.00;status=paid;time=2024-06-15 14:22:03";
$key = hash('sha256', 'your_app_secret_key_here', true); // 32字节密钥
$ivlen = openssl_cipher_iv_length($cipher = 'AES-256-CBC');
$iv = openssl_random_pseudo_bytes($ivlen); // 每次加密都用新 IV
$encrypted = openssl_encrypt($log, $cipher, $key, OPENSSL_RAW_DATA, $iv);
$storage_data = base64_encode($iv . $encrypted); // IV 和密文拼一起再 base64
注意：$iv 必须和密文一起保存，否则无法解密；base64_encode() 是为了安全存入数据库（避免二进制乱码或截断）；OPENSSL_RAW_DATA 表示输出原始字节，不是 base64，这样你才能自己控制编码方式。
立即学习“PHP免费学习笔记（深入）”；
解密时必须严格还原 IV 和密钥推导逻辑
解密失败十有八九是 IV 错位或密钥不一致。从 $storage_data 中拆出 IV 和密文是关键一步，漏掉一个字节就全崩。
$storage_data = '...'; // 从数据库读出的 base64 字符串
$decoded = base64_decode($storage_data);
$ivlen = openssl_cipher_iv_length('AES-256-CBC');
$iv = substr($decoded, 0, $ivlen);
$ciphertext = substr($decoded, $ivlen);
$key = hash('sha256', 'your_app_secret_key_here', true);
$log = openssl_decrypt($ciphertext, 'AES-256-CBC', $key, OPENSSL_RAW_DATA, $iv);
容易踩的坑：
- 密钥字符串没统一用
hash(..., true)（返回二进制），而用了默认false（返回十六进制字符串），导致密钥长度错成 64 字节 - 从 base64 解码后没检查
$decoded === false（base64 损坏时会返回 false，继续 substr 就出错） - 数据库字段类型设太小：AES-256-CBC 加密后长度 ≈ 原始长度 + 16 字节（padding）+ IV 长度（16），再加 base64 膨胀约 33%，
VARCHAR(512)往往不够，建议TEXT或至少VARCHAR(1024)
要不要加 MAC 防篡改？订单日志场景强烈建议加
单纯加密只能防偷看，不能防日志被恶意替换（比如把 status=paid 改成 status=refunded 再重新加密）。订单审计要求“不可抵赖”，得验证完整性。
最简方案：加密后，用同一密钥派生另一个 key，计算 HMAC-SHA256：
$hmac_key = hash_hkdf('sha256', $key, 32, 'hmac-key'); // PHP 7.5+；低版本可用 hash('sha256', $key . 'hmac') 截取 32 字节
$hmac = hash_hmac('sha256', $iv . $encrypted, $hmac_key, true);
$final_storage = base64_encode($iv . $encrypted . $hmac); // 最后 32 字节是 HMAC
解密前先校验 HMAC，不匹配就拒绝处理——这步不能省。生产环境订单日志一旦被中间人或内鬼篡改，没有 MAC 就毫无察觉。
真正麻烦的不是加解密本身，而是密钥轮换、IV 管理、HMAC 校验顺序、以及日志解密失败时的降级策略（比如记录告警但不中断主流程）。这些细节没对齐，加密就只是心理安慰。
