thinkphp默认log::write()不能用于安全审计，因其不带user_id、action等上下文，日志混存于runtime/log/且无结构化字段，无法按用户、时间、操作精准检索，更缺失脱敏控制与数据快照，导致“谁在何时删了谁”完全不可追溯。
ThinkPHP 默认的 Log::write() 不能用于安全审计——它不带用户上下文、不可检索、无法关联请求链路，查起来等于翻废纸。
为什么不能用 Log::write() 记审计日志
默认日志写到 runtime/log/ 下，混着错误、调试、SQL 日志一起存，字段全是字符串，没 user_id、没 action、没脱敏控制。出问题时你连“谁在什么时间删了哪个用户”都捞不出来。
- 查不到人：日志里没有认证态标识，
session('user_id')在 CLI 或 API 场景直接报错或返回空 - 筛不动：所有内容塞进一个
content TEXT字段，没法按admin_id或created_at加索引加速查询 - 留不住痕：没记录操作前快照，删完用户只剩一条“DELETE FROM user WHERE id=123”，原始邮箱、角色全丢
AuditMiddleware 怎么拿准用户 ID 和动作语义
中间件是唯一能稳定捕获真实上下文的位置，但必须绕过常见陷阱：
- 别直接调
Auth::id()—— 若 Auth 服务未注册或 token 验证失败，会返回null；应先判空：$adminId = Auth::id() ?: ($request->attr('user')['id'] ?? null) - 别解析 URL 判断动作 ——
$request->url()易被伪造；改用$request->rule()->getModule().'/'.$request->rule()->getController().'/'.$request->action() - 别信任
X-Forwarded-For—— 必须结合Request::isFromTrustedProxy()校验，否则攻击者可伪造 IP；稳妥写法：$ip = $request->ip() ?: $_SERVER['REMOTE_ADDR'] ?? '0.0.0.0'
敏感操作日志必须包含哪些字段
只记 URL + IP 是无效日志。真正可审计的字段要拆解、脱敏、可索引：
-
admin_id：整型，非空则为有效用户 ID，否则设为NULL（禁用字符串类型） -
action：固定格式module/controller/action，长度限制VARCHAR(100)，建索引 -
params：用array_filter($params, function($k) { return !in_array($k, ['password', 'token', 'sign']); }, ARRAY_FILTER_USE_KEY)过滤后再json_encode()；MySQL 5.7+ 建议设为JSON类型 -
before_data：仅对DELETE/UPDATE操作启用，查一次原记录，例如UserModel::find($params['id'])，只取用户名、邮箱、状态等不可变字段 -
session_id：不是session_id()函数返回值，而是$request->session()->getId()，同一 IP 多账号场景下唯一区分依据
数据库表结构和写入时机怎么避坑
表设计和落库时机直接影响审计可用性：
- 字段
created_at和admin_id必须建联合索引，否则按人查一周操作会慢到超时 - 不要在
handle()里同步写日志 —— 主流程卡住就拖垮整个请求；推荐用think\facade\Queue::push()异步写入，失败自动重试 - 异常路径必须补漏：控制器抛异常时
after()不触发，得在app/exception/Handle.php的render()里判断是否为敏感路由，并补写status = "failed"日志 - 禁止用
Db::table('user')->delete()这类裸 SQL —— 它绕过中间件，也绕过你的审计；高危操作强制走封装好的 Service 方法，里面主动触发日志
审计日志真正的难点不在“怎么记”，而在“记下来之后能不能快速定位到人、事、数据变更”。字段拆解、索引设计、异步落库、异常兜底——少做一步，回溯时就要多花三小时。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
