最轻量方式是用 session_start() + $_session 记录操作上下文，需在输出前调用、避免存敏感字段；持久化可用 file_put_contents() 追加 json 日志；合规审计须建库表并确保字段完整、json 安全及事务原子性；异常日志需提前登记上下文至全局变量。
用 session_start() + $_SESSION 记录操作上下文最轻量
PHP 自身没有“操作快照”机制，得靠开发者在关键节点手动存状态。最常用也最稳妥的方式，是在用户登录后调用 session_start()，然后把操作前后的关键字段塞进 $_SESSION，比如：$_SESSION['audit_before'] = ['user_id' => 123, 'balance' => 98.5];，操作完成后写入 $_SESSION['audit_after']。这种方式不依赖数据库或外部服务，适合中小项目快速落地。
常见错误是忘记在每次请求开头调用 session_start()，导致 $_SESSION 为空；或者在异步请求（如 AJAX）中没传 session cookie，造成上下文丢失。
- 必须在输出任何内容前调用
session_start()，否则报错headers already sent - 敏感字段（如密码、token）绝不能进
$_SESSION，审计日志只存业务标识和变更值 -
$_SESSION生命周期默认是会话级，关浏览器就清空，不适合长期追溯 —— 真要留痕得落库
用 json_encode() + file_put_contents() 快速落地审计日志文件
如果不想搭数据库表，又需要持久化记录，直接写文件是最简单路径。核心是把操作前后状态用 json_encode() 序列化，再用 file_put_contents() 追加到日志文件。注意别用 file_put_contents($file, $data) 覆盖写，得加 FILE_APPEND 标志。
典型使用场景是后台管理系统的增删改操作，比如编辑用户资料时，先读原数据，再保存新数据，中间把差异打点进日志。
- 路径必须可控，避免写到 web 可访问目录，推荐
/var/log/php-audit/或项目外的logs/目录 - 日志内容里务必包含
$_SERVER['REQUEST_URI']、$_SERVER['REMOTE_ADDR']和date('c')，否则查问题时找不到上下文 - 高并发下多个请求同时写同一文件可能丢行，加
LOCK_EX是底线：file_put_contents($file, $line, FILE_APPEND | LOCK_EX)
用 mysqli 或 PDO 插入结构化审计表要注意字段设计
真正要用于合规审计（比如等保、ISO27001），日志必须可检索、不可篡改、带完整元信息。这时候就得建表，用 mysqli 或 PDO 插入。重点不在怎么插，而在字段怎么设：除了 user_id、action、before_data、after_data，还必须有 ip、uri、created_at 和 trace_id（用于串联一次完整请求链路）。
容易踩的坑是把 before_data 和 after_data 设成 VARCHAR(255) —— 实际 JSON 可能超长，至少要用 TEXT；另一个是没对 before_data/after_data 做 json_encode() 后的 htmlspecialchars() 或 addslashes() 处理，导致 SQL 报错或注入风险。
- 别用
serialize()存状态，跨 PHP 版本或扩展缺失时无法反解，json_encode()是唯一安全选择 - 插入前检查
json_last_error() === JSON_ERROR_NONE，避免无效 JSON 写进数据库 - 表引擎必须是
InnoDB，开启事务保证日志和主业务操作原子性（例如：主表更新失败，审计日志也不能写入）
用 register_shutdown_function() 捕获异常时的上下文断层
有些操作失败后才想补记日志，比如转账中途抛出异常。这时不能只依赖正常流程里的记录点，得用 register_shutdown_function() 拦截脚本终止时刻。但它拿不到当前作用域变量，$_SESSION 也可能已销毁，所以必须提前把关键上下文存到全局数组或静态属性里。
典型错误是直接在 shutdown 函数里读 $user 或 $order 变量 —— 它们早没了。正确做法是在业务逻辑开头就做类似 $GLOBALS['audit_context'] = ['action' => 'transfer', 'from' => 1001, 'to' => 1002]; 的登记。
- shutdown 函数里只能用
error_get_last()判断是否真出错了，不能无条件写日志 - 别在 shutdown 里连数据库或发 HTTP 请求，超时或失败会导致整个脚本挂死
- 如果用了 OPcache 或 Swoole，
register_shutdown_function()行为可能异常，得单独验证
上下文记录最难的不是存，而是“什么时候该存、存哪些字段、谁有权删”。很多团队卡在字段粒度上：存太细拖慢性能，存太粗查不出问题。建议从一个核心操作（比如“修改用户手机号”）开始，只存 user_id、old_phone、new_phone、ip、ua 这五个字段，跑通再扩。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
