订单评价日志应优先写入数据库，因其具备可查、可关联、可回溯特性；需与order_id、user_id等字段精确对齐，避免文件日志丢失上下文或难以聚合分析。
订单评价日志该写到数据库还是文件
优先写进数据库，不是因为“高大上”，而是因为可查、可关联、可回溯。评价日志本质是业务动作的审计线索，必须能和 order_id、user_id、score、content 精确对齐。写文件容易丢失上下文（比如没记录操作时间戳或 IP），也难做聚合分析（如“近 7 天差评率”）。
常见错误：用 file_put_contents() 追加文本日志，但没加锁，高并发下日志错乱；或只记了 content，漏掉 created_at 和 ip，出问题后无法定位。
- 数据库表建议至少包含：
id、order_id、user_id、score、content、ip、created_at - 避免在事务外单独 insert 日志 —— 若评价逻辑失败，日志却写成功，数据不一致
- 不要用
datetime字段存毫秒级时间，PHP 写入时用date('Y-m-d H:i:s')即可，MySQL 5.6+ 支持datetime(3)可选，但多数场景不需要
PHP 中记录评价日志的典型位置
不是在前端提交接口里直接写日志，而是在评价业务逻辑确认生效后、事务 commit 前的那一刻。比如用户调用 /api/v1/orders/{id}/review，控制器收到请求后，应先校验权限、订单状态、是否已评价，再执行评价更新，最后写日志 —— 这三步最好在一个数据库事务里完成。
示例结构（Laravel 风格，但原理通用）：
立即学习“PHP免费学习笔记（深入）”；
DB::transaction(function () use ($order, $data) {
$order->update(['status' => 'reviewed', 'score' => $data['score']]);
OrderReviewLog::create([
'order_id' => $order->id,
'user_id' => auth()->id(),
'score' => $data['score'],
'content' => $data['content'] ?? '',
'ip' => request()->ip(),
'created_at' => now(),
]);
});
关键点：
- 日志模型
OrderReviewLog必须和主业务表在同一个数据库连接、同一事务中 - 不要在模型的
saved或updated事件里自动写日志 —— 容易误触发（比如后台修改订单状态也触发） - 若用原生 PDO，请确保
$pdo->beginTransaction()包裹全部操作，且异常时$pdo->rollback()
日志内容要防什么
评价内容（content）是用户输入，直接入库有风险：XSS（虽然后台日志不渲染，但导出查看时可能被浏览器执行）、SQL 注入（如果拼接 SQL 而非预处理）、超长截断（MySQL TEXT 虽够用，但 PHP 层应限制长度防 DOS）。
- 入库前用
mb_substr($content, 0, 1000, 'UTF-8')截断，避免过长影响性能 - 不用
strip_tags()—— 用户可能真想输入「」这类符号，只需过滤 script 标签即可，推荐preg_replace('/ - IP 地址别信
$_SERVER['REMOTE_ADDR']—— 如果用了 CDN 或 Nginx 反代，得从X-Forwarded-For或X-Real-IP取，但必须白名单校验可信代理头 - 敏感字段如
user_id绝对不能记录为明文昵称或手机号，只存数字 ID
要不要异步写日志
一般不需要。评价本身是低频、强一致操作（用户点了“提交评价”，必须立刻知道成功与否），同步写入日志延迟可接受（毫秒级）。强行异步（如投 MQ、写 Redis 再异步落库）反而增加复杂度和失败路径。
唯一适合异步的场景：你已有统一日志服务（如 ELK），且要求所有业务日志走统一通道。此时可用 file_put_contents('php://stderr', json_encode([...])) 输出结构化日志，由日志采集器收集 —— 但注意：这不能替代数据库审计日志，只是补充。
容易踩的坑：
- 用
curl异步调用日志接口 —— PHP 默认同步阻塞，除非显式设CURLOPT_TIMEOUT_MS且服务端极快，否则拖慢主流程 - 用
ignore_user_abort(true)+fastcgi_finish_request()—— 请求已返回，但日志写失败无感知，丢失数据 - 把日志当缓存用，删旧日志时误删了关键审计记录
真正要省心的做法：建好带索引的 order_review_log 表，定期归档（按月分表或导出压缩），别试图用“轻量方案”绕开结构化存储。
