日志脱敏必须在加密前完成，先对原始结构化数据中的phone、id_card等字段用哈希+盐等方式脱敏，再用openssl_encrypt加密；IV须每次随机生成并随密文存储，避免复用或可预测值。
日志脱敏必须在加密前完成
加密不能代替脱敏，反过来也一样。用 openssl_encrypt 直接加密含明文手机号的日志，等于把敏感信息锁进一个带钥匙的保险箱——但钥匙（密钥）一旦泄露，所有数据瞬间还原。真正安全的做法是先擦除/替换敏感字段，再加密整个日志体。
常见错误现象：file_put_contents('log.enc', openssl_encrypt($raw_log, 'AES-256-CBC', $key, 0, $iv)) —— 这样加密后，日志里仍存有 "phone":"138****1234" 这类“伪脱敏”内容，而 **"138****1234" 不是脱敏，是掩码，它可被逆向推测或撞库还原**。
- 脱敏操作必须作用于原始结构化数据（如
$log_array），而非加密后的二进制流 - 推荐在写入日志前、序列化前处理：对
phone、id_card、email等键做正则替换或哈希截断 - 避免用固定掩码（如全替成
"***"），优先用单向哈希+盐（如hash_hmac('sha256', $phone, $salt)）保留可关联性又不可逆
PHP中用 openssl_encrypt 加密日志要注意 IV 复用风险
IV（初始化向量）不是密码，但它的重复使用会让相同明文生成相同密文，破坏语义安全性。日志场景下尤其危险：如果每天固定时间写一条格式相似的调试日志（如 {"level":"debug","msg":"start"}），IV 复用就等于给攻击者送出了可比对的密文样本。
使用场景：批量归档旧日志时，容易为省事用同一个 $iv 变量循环加密多条记录。
立即学习“PHP免费学习笔记（深入）”；
- 每次调用
openssl_encrypt必须生成新 IV：$iv = random_bytes(openssl_cipher_iv_length('AES-256-CBC')) - IV 无需保密，但必须和密文一起存储（比如拼在密文前、或存为 JSON 字段），否则无法解密
- 不要用
time()或自增 ID 当 IV —— 它们可预测，等同于无 IV - 注意：PHP 7.4+ 支持
OPENSSL_RAW_DATA标志，返回二进制；若存文本，记得base64_encode整个结果（含 IV）
敏感字段识别不能只靠 key 名匹配
日志结构千变万化，仅靠判断 $key === 'phone' 会漏掉大量真实敏感数据。比如框架日志可能把用户标识藏在 context.user_id、meta.client_ip、甚至 SQL 错误消息的 message 字段里。
性能影响：逐字段正则扫描全文本，比遍历数组键慢 3–5 倍；但为了安全，这步不能跳过。
- 先做结构化解析（
json_decode($line, true)或unserialize），再递归遍历数组，对值做模式匹配（如中国手机号/^1[3-9]\d{9}$/） - 对非结构化日志行，用
preg_replace_callback扫描整行，匹配后替换为哈希值，而非简单星号 - 配置项
$sensitive_patterns应支持动态加载（如从config/sanitize.php读取），避免硬编码在加密函数里 - 注意：IP 地址脱敏要留段（如
192.168.1.1 → 192.168.1.*），但需区分内网/公网，公网 IP 建议哈希
解密归档日志时，openssl_decrypt 报错 error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
这个错误几乎全是 IV 或密钥不匹配导致，和“数据损坏”无关。日志归档周期长，最容易出问题的是密钥轮换后忘了更新解密脚本，或者 IV 存储格式和读取方式不一致（比如存了 base64 但解密时直接当二进制用了）。
兼容性影响：PHP 版本升级（如 7.3 → 8.1）可能默认启用更严格的 OpenSSL 配置，旧密文若用弱填充模式（如无 PKCS#7）会直接失败。
脱敏规则和加密参数一旦上线，后续任何调整（比如换密钥、改 IV 生成方式）都会导致历史日志无法解密。别指望“以后再统一迁移”，归档日志的解密能力必须从第一行开始就稳定。
