最稳妥的审计方案是组合使用 Laravel Observer、MySQL 触发器和 PDO 拦截：Observer 覆盖 PHP 层增删改恢复全链路并兼容事务，触发器兜底直连数据库修改，PDO 拦截捕获原始 SQL 与参数；三者协同确保日志与数据在事务回滚、CLI、队列、直连等异常下仍一致。
直接用 Observer 监听模型事件是最稳妥的起点，它不依赖第三方、不污染业务逻辑、能覆盖增删改恢复全链路，且天然兼容 Laravel 事务机制。
用 Laravel Observer 记录真实字段变更
很多人在 updating 或 save() 里写日志，结果事务回滚了但日志已落库，造成数据与日志不一致。正确做法是监听 eloquent.updated 等事件，在事件处理器中调用 $model->getChanges() —— 它只返回真正被修改的字段，不是所有脏字段。
- 必须监听
created、updated、deleted、restored四个事件，软删除恢复（restored）常被遗漏 -
$model->getOriginal()在updated里拿不到旧值，得提前在retrieved事件中缓存 - 别在 Observer 里调用
$model->save()或触发其他模型操作，否则可能递归监听或破坏事务隔离 - 日志写入必须走独立数据库连接或异步队列，不能写进同一事务里的主库同表，否则死锁风险高
MySQL 触发器捕获绕过 PHP 的修改
当有人用命令行、Navicat 或其他语言直连数据库改数据时，PHP 层日志就失效了。这时候只有数据库原生触发器能兜底。但写错会直接让 INSERT/UPDATE 报错 ERROR 1362: Can't update table 'xxx' in stored function/trigger。
- INSERT 触发器只能读
NEW.*，DELETE 只能读OLD.*，UPDATE 两者都有——必须分别判空，不能无条件引用OLD.id - 别用
CONCAT拼接所有字段，字段多时容易超max_allowed_packet；改用JSON_OBJECT('name', OLD.name, 'email', NEW.email) - 审计表建议用
ARCHIVE引擎，写入快、压缩率高，适合只追加不查询的场景 -
USER()返回的是 MySQL 用户名（如app@localhost），不是业务用户；需配合SET @modified_by = ?在 PHP 中预设变量再由触发器读取
PHP 层拦截 PDO 执行并提取上下文
如果项目没用 Eloquent，或者需要记录原始 SQL 和参数（比如批量插入的每条 row_id），就得从 PDO 底层下手。但只监听 execute() 不够，prepare 后没 execute 的语句、带占位符的动态 SQL 都容易漏。
立即学习“PHP免费学习笔记（深入）”；
- 用
PDO::setAttribute(PDO::ATTR_STATEMENT_CLASS, ['MyStatement'])注入自定义 Statement 类 - 在
execute()前解析$this->queryString和绑定参数，用正则提取表名（如INSERT INTO `users`）和主键值（如VALUES (?, ?)对应的 ID） - 批量 INSERT 场景下，
row_id不是单个值，得结合参数数量和主键位置推算，不能硬写$params[0] - 记录 IP、请求路径、用户 ID 这些上下文，得从全局可访问的地方取，比如 Laravel 的
request()->ip()或auth()->id()，但 CLI 和队列任务里这些可能为空，得 fallback 到get_current_user()或日志标记为system
审计表设计和查询避坑点
日志表建得不合理，查起来就慢，甚至拖垮主库。见过太多人把审计表和主表放一起、加一堆 JOIN、没索引还天天 SELECT *。
- 审计表必须独立，字段至少含：
table_name、operation（INSERT/UPDATE/DELETE）、row_id、changed_fields（JSON 格式）、modified_by、created_at - 必建联合索引：
INDEX (table_name, operation, created_at)，按表+操作类型+时间范围查最常见 - 禁止在审计表上做
JOIN主表查用户名——主表万一被删或改结构，审计就崩；用户信息应在写入时就冗余存进modified_by_name - JSON 字段别用
WHERE JSON_CONTAINS(changed_fields, '"name"')全表扫描，要用 MySQL 5.7+ 的虚拟列 + 函数索引加速特定字段查询
真正难的不是记下“谁改了什么”，而是保证日志和数据在各种异常路径下依然一致：事务回滚、CLI 脚本、队列重试、管理员直连、跨服务调用……这些边缘 case 一旦漏掉一个，审计就失去可信度。
