直接用file_put_contents记审计日志是高并发下的第一个坑，因LOCK_EX阻塞导致排队卡顿、丢日志、拖慢请求，且若日志路径在Web目录下易被下载泄露敏感信息；必须移至Web根目录外、禁用循环调用、每行加换行符、过滤用户输入，并用Monolog独立channel与结构化格式器确保可追溯性。
直接用 file_put_contents 记审计日志就是第一个坑
它看着简单，但高并发下会卡住、丢日志、拖慢整个请求。PHP 的 LOCK_EX 是阻塞锁，10 个并发写，9 个在排队等磁盘 IO；更危险的是，如果日志路径放在 Web 目录下（比如 /www/wwwroot/xxx/audit.log），攻击者能直接用浏览器下载日志，看到管理员账号和操作痕迹。
必须把日志路径挪到 Web 根目录外，例如：/var/log/myapp/audit.log；同时禁用 file_put_contents 在循环或高频动作里调用——哪怕加了 LOCK_EX，也扛不住真实流量。
- 每次写入后手动加
\n，否则多条日志挤成一行，grep失效 - 用户输入进日志前必须过滤：
filter_var($input, FILTER_SANITIZE_STRING)或至少htmlspecialchars() - 别把
echo、模板渲染、调试变量 dump 塞进审计日志——它只该记录「谁、何时、对什么、做了什么、成功与否」
用 Monolog 时为什么 %context% 不能直接打出来
Monolog 默认的 LineFormatter 把数组转成字符串 "Array"，你查不到具体参数。比如一条 data_delete 日志里，target_id 和 user_id 全被吞成 Array，根本没法追溯是谁删了哪条数据。
正确做法是自定义格式器，显式提取关键字段，或者用 JsonFormatter 输出结构化内容，再配合 logrotate 切割和 chattr +a 锁定日志文件防篡改。
立即学习“PHP免费学习笔记（深入）”；
- 审计日志必须单独 channel：
$auditLogger = new Logger('audit')，别和 debug/error 日志混用 - Handler 要绑定独立路径：
new StreamHandler('/var/log/myapp/audit.log', Logger::INFO) - 禁止把原始
$_POST或数据库连接对象塞进$context，容易泄露密码或敏感配置
宝塔面板的 request.log 为什么比界面里看的日志更可靠
面板 UI 上「安全 → 面板操作日志」页面会过滤 POST 参数、截断长 URL、不支持时间范围筛选——你想找「谁在 14:22 把 PHP 版本从 7.4 改成了 8.2」，界面里根本找不到完整记录。
真正完整的原始日志只存在 /www/server/panel/logs/request.log，每行含时间戳、IP、用户名、URL 和参数摘要（如 act=save_php&php_version=8.2）。但要注意：它只记录 Web 界面操作，不包括 SSH 命令或脚本调用。
- 启用前检查
/www/server/panel/data/config.json是否有"audit_log": true - 日志权限必须是
www用户可写：ls -l /www/server/panel/logs/request.log - 别依赖自动清理策略，
logrotate配置要保留至少 30 天，否则审计窗口太短
数据库操作审计最容易漏掉的三个点
很多人只盯着应用层日志，忘了数据库本身才是最终执行者。MySQL 通用日志（general_log）能抓全量 SQL，但它性能开销大，不适合长期开启；PDO 封装能记录参数，但若没做预处理，SQL 拼接里的恶意输入照样进日志——等于把漏洞行为原样存档。
SQLite 方案看似轻量，但 logs 表里如果没存 user_id 或 ip，就只剩「谁删了某条记录」却不知道「谁删的」，审计链条断裂。
- MySQL 开启
general_log仅限临时排查，生产环境建议用slow_query_log+ 条件过滤 - PDO 封装时，
execute()前必须记录绑定参数值，不能只记 SQL 模板 - 用 ProxySQL 或 MaxScale 做代理审计，才能绕过应用代码，捕获所有流量，包括 CLI 工具和定时任务
request.log 可被删，MySQL 日志可关，只有多源交叉比对（应用层 + 中间件 + 数据库 + 系统 auditd），才能堵住逃逸路径。 
