用数据库触发器自动记录历史快照最省心，PHP仅需传递user_id、IP等元信息，避免并发丢变更和事务不一致问题。
用触发器自动记录历史快照最省心
PHP 本身不负责存历史，真正干活的是数据库。直接在 MySQL 或 PostgreSQL 里用触发器（TRIGGER）捕获 UPDATE 和 DELETE，比在 PHP 层拼 SQL 可靠得多——避免漏掉某个接口、绕过 ORM、或事务没提交就写日志。
常见错误是只监听 UPDATE，忘了 DELETE 也需要快照；还有人把历史表和主表放不同库，结果事务不一致，删了主表数据却没写进历史表。
- MySQL 触发器必须用
AFTER UPDATE，不能用BEFORE，否则取不到新值 - 历史表字段要包含
old_value、new_value、updated_at、updated_by（后者需 PHP 传入，比如从$_SESSION['user_id']） - 别把 JSON 字段整个 dump 进去，按字段粒度存变更项，否则查某次改了哪个字段会很慢
PHP 层该传什么给历史表
触发器拿不到 HTTP 请求上下文，所以 updated_by、ip_address、request_id 这些必须由 PHP 显式写入。最稳妥的方式是在事务开头先 INSERT INTO audit_log_meta 记一次操作元信息，再把生成的 log_id 透传给后续所有触发器。
容易踩的坑：有人用 $_SERVER['REMOTE_ADDR'] 直接入库，但 Nginx 反代后它永远是 127.0.0.1；也有人把用户 ID 写死成字符串 "admin"，结果权限系统升级后全乱套。
立即学习“PHP免费学习笔记（深入）”；
- 真实用户 ID 必须从已认证的 session 或 JWT payload 中取，不是从 POST 参数里读
- IP 要优先取
$_SERVER['HTTP_X_FORWARDED_FOR']， fallback 到$_SERVER['REMOTE_ADDR'] - 如果用 Laravel，别在模型事件里写历史——
saving事件发生在事务内，但触发器执行时机更晚，可能冲突
历史表查询慢？加对索引比优化 PHP 更管用
历史表增长极快，没索引的话，查「用户 A 修改过哪些字段」这种需求，SELECT * FROM user_history WHERE user_id = ? 一跑就锁表。重点不是 PHP 分页逻辑，而是数据库怎么扛住百万级记录。
典型错误是只给 user_id 加索引，但实际查询经常带时间范围 + 操作类型，比如「上周所有 status 字段修改」，单列索引完全无效。
- 复合索引顺序很重要：
(user_id, field_name, updated_at)比反过来快十倍 -
field_name值离散度高（比如有 50+ 字段名），就别加前缀索引，直接VARCHAR(64)全长索引 - PostgreSQL 用户注意：
pg_trgm扩展能加速模糊查字段名，MySQL 8.0+ 可用全文索引替代
不要用 PHP 数组 diff 做版本对比
有人在 PHP 里把旧数据 SELECT 出来，和新数据 array_diff_assoc() 一遍，再 insert 到历史表——这方法在并发场景下必然丢变更。两个请求同时读到同一版旧数据，各自算出“自己改了”，结果只记了一次。
真正安全的做法是让数据库自己比：MySQL 8.0+ 用 JSON_CONTAINS_PATH() 配合 JSON_EXTRACT()，或者干脆用触发器里的 OLD.column_name != NEW.column_name 判断是否真变了。
- 即使字段值从
null改成""，也要视为变更，别用==判断，用IS NOT DISTINCT FROM（PostgreSQL）或NULLIF()包一层（MySQL） - 日期字段小心时区：PHP 写入
2024-05-01 12:00:00，数据库存的是 UTC，触发器读OLD.created_at时可能已经是另一天 - 大文本字段（如
TEXT）别进历史表，只记md5(content)或长度变化，否则历史表体积爆炸
字段版本控制真正的复杂点不在 PHP 怎么写，而在历史数据要不要参与业务逻辑——比如「回滚到上一版」需要重建外键约束，而不仅是还原字段值。这点很容易被忽略。
