直接在DAO写日志会导致业务与审计强耦合，修改日志逻辑需遍历多处DAO易漏改；应使用SplSubject/SplObserver实现事务提交后的异步解耦日志，注意脱敏、上下文注入、非阻塞写入及日志与DB一致性补偿。
为什么直接在DAO里写日志会埋雷
硬编码日志逻辑到每个 insert()、update() 方法里，会导致业务代码和审计职责强耦合。一旦要加字段（比如记录操作人IP）、换存储方式（从文件切到Elasticsearch），就得改十几处DAO——漏改一处，日志就断档。观察者模式在这里不是炫技，是解耦刚需。
用SplSubject + SplObserver实现轻量观察者
PHP内置的 SplSubject 和 SplObserver 足够用，不用引入框架或自建接口。关键点在于：数据库操作类（如 UserDao）实现 SplSubject，日志处理器（如 DbAuditLogger）实现 SplObserver，触发时机必须是事务提交后（否则日志记了但DB回滚，数据不一致）。
实操建议：
-
attach()应在DAO初始化时调用，避免每次操作都重复绑定 -
notify()必须放在commit()成功之后，不能在execute()后立刻触发 - 传递给
update()的参数建议是关联数组，包含['action' => 'insert', 'table' => 'users', 'sql' => 'INSERT ...', 'params' => [...]]，别传原始SQL字符串（含敏感值）
class UserDao implements SplSubject {
private $observers = [];
private $pdo;
public function attach(SplObserver $observer) {
$this->observers[] = $observer;
}
public function insert($data) {
$stmt = $this->pdo->prepare("INSERT INTO users (name) VALUES (?)");
$stmt->execute([$data['name']]);
$this->pdo->commit(); // 确保已提交
$this->notify(['action' => 'insert', 'table' => 'users', 'params' => $data]);
}
public function notify($data) {
foreach ($this->observers as $observer) {
$observer->update($this, $data);
}
}
}
日志内容必须脱敏且带上下文
直接记录 $_SERVER['REMOTE_ADDR'] 不可靠（可能被代理覆盖），应由入口层统一注入用户标识；密码、身份证号等字段必须在日志前做掩码处理，例如把 'id_card' => '110101199001011234' 转成 'id_card' => '110101******1234'。否则审计日志本身就成了高危泄露源。
立即学习“PHP免费学习笔记（深入）”；
常见错误现象：
- 日志里出现
password: '$2y$10$...'—— 密码哈希也不该明文记 - 没记录事务ID或请求ID，导致无法关联同一操作的多条日志
- 时间用
date('Y-m-d H:i:s')，没带时区，查问题时对不上运维系统时间
性能陷阱：日志写入不能阻塞主流程
同步写文件或发HTTP请求到日志服务，会拖慢DB操作。实际做法是：在 update() 里只把日志数据推到内存队列（如 array_push($this->logBuffer, $data)），再由单独的异步进程（如 pcntl_fork() 子进程或消息队列消费者）批量落盘。若用Redis作缓冲，注意设置过期时间防堆积。
性能影响要点：
- 单次
file_put_contents(..., FILE_APPEND)在高并发下会锁文件，必须用fopen()+fwrite()+fflush()配合flock() - MySQL的
general_log开关虽简单，但开启后QPS跌30%+，仅适合临时排查，不可用于生产审计 - 别在观察者里做复杂格式化（如生成HTML报告），那是下游ETL的事
最易被忽略的是事务边界和日志持久化的先后顺序——日志写失败，业务不能回滚；但日志写成功而DB回滚，就必须有补偿机制（比如日志中标记“pending”状态，由后台任务核对）。这点没人提，但线上出过事故。
