日志加密前必须确保log.level非debug且app_debug=false，否则敏感信息明文泄露；推荐在logserviceprovider中重写file驱动的write方法，仅对error/warning加密，并严格管理密钥与iv。
日志加密前必须确认 log.level 不是 debug
线上环境开启 debug 会导致敏感信息（如 SQL、POST 数据、用户 token）直接写入日志明文，加密也白搭。ThinkPHP 默认线上用 error 或 warning，但很多项目上线后忘了关 APP_DEBUG 或没重置 log.level。
实操建议：
- 检查
config/log.php中'level' => env('LOG_LEVEL', 'error')，确保环境变量LOG_LEVEL在线上为error或warning - 确认
APP_DEBUG=false且app_status=production已生效（可通过Env::get('app_status')验证） - 临时加一行日志测试：
Log::warning('test_' . uniqid());，再查日志文件是否只含 warning 及以上
用 think\facade\Log 的 write 方法拦截并加密日志内容
ThinkPHP 日志底层走 think\log\driver\File，但不建议直接改驱动类——升级易覆盖。更稳妥的是在写入前用 Log::listen() 或自定义日志处理器。
实操建议（推荐）：
- 在
app/provider/LogServiceProvider.php的register()中注册加密处理器：
use think\log\driver\File;
use think\log\Logger;
$this->app->bind('log', function ($app) {
$logger = new Logger($app);
$logger->setDriver(new class extends File {
protected function write($message, $type)
{
// 仅对 error/warning 加密，info/debug 跳过（避免影响调试）
if (in_array($type, ['error', 'warning'])) {
$message = openssl_encrypt($message, 'AES-128-CBC',
config('log.encrypt_key'), 0,
substr(config('log.encrypt_iv'), 0, 16));
}
return parent::write($message, $type);
}
});
return $logger;
});
-
log.encrypt_key和log.encrypt_iv需配置在config/log.php，且必须是线上独立管理的密钥（不要硬编码） - 注意：加密后日志不可读，排查问题需配套解密脚本，别指望直接
tail -f
解密日志时 openssl_decrypt 报 data length is not a multiple of block length
这是 CBC 模式下最常见错误，本质是加密输出被截断或换行符干扰。ThinkPHP 日志默认按行写入，而 openssl_encrypt 输出 base64 字符串，若日志中混入未加密行（比如 info），解密器会把多行拼一起解，必然失败。
实操建议：
- 解密脚本必须逐行处理，跳过非加密行（例如匹配开头是否为
U2FsdGVkX1这类 base64 AES 前缀） - 用
trim()清除每行末尾换行和空格，否则base64_decode失败 - IV 必须和加密时完全一致，建议从配置读取并固定为 16 字节，别用
random_bytes(16)动态生成（否则无法解） - 示例解密片段：
$line = trim($line);
if (substr($line, 0, 12) === 'U2FsdGVkX1') {
$decrypted = openssl_decrypt(base64_decode($line), 'AES-128-CBC',
config('log.encrypt_key'), 0, substr(config('log.encrypt_iv'), 0, 16));
echo $decrypted . "\n";
}
加密日志后 Log::record() 和 Log::save() 行为异常
ThinkPHP 的 Log::record() 是内存暂存，Log::save() 才真正写盘。如果在 record 阶段就加密，会导致重复加密（save 时再走一遍加密逻辑）；如果只在 save 阶段加密，又可能漏掉 record 中的 error 信息。
实操建议：
- 放弃修改
record，专注在日志驱动的write()或save()入口统一加密 - 禁用自动保存（
'realtime_write' => false），改用Log::save()显式触发，便于控制加密时机 - 切勿在
App::after()或中间件里调用Log::save()—— 此时请求已结束，部分上下文（如 session）可能失效，导致加密 key 获取失败
密钥管理、加密粒度、解密可用性，这三块只要有一块松动，整个方案就退化成假安全。线上日志加密不是加个函数就行，得盯住每一行落盘前的状态。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
