最稳妥做法是在PHP日志逻辑中用date('Y-m-d H:i:s')或time()主动获取服务器当前时间，并统一设置时区为Asia/Shanghai；存文本用DATETIME字段，存整型用INT(10)；批量日志复用同一时间戳。
PHP 订单日志里加时间戳，最稳妥的做法是用 date() 或 time() 生成当前时间，而不是依赖数据库自动填充或客户端传入 —— 后者容易被篡改或时区错乱。
订单日志写入时直接生成时间戳
在记录日志的 PHP 逻辑中（比如下单成功后调用 logOrderAction()），应主动获取服务器当前时间。推荐用 date('Y-m-d H:i:s')，可读性强；若需高精度或后续做时间计算，可用 time() 存整型时间戳。
-
date('Y-m-d H:i:s')适合写进文本日志、数据库DATETIME字段，人眼可读 -
time()返回的是 Unix 时间戳（秒级整数），适合存INT(10)字段，节省空间且便于计算（如“7 天内订单”） - 避免用
microtime(true)写日志 —— 毫秒级对订单审计无实质意义，反而增加存储和排查复杂度
注意时区设置，别让日志时间“跳来跳去”
PHP 默认时区是 UTC，如果服务器在东八区但没显式设时区，date() 会输出 UTC 时间，导致日志比实际晚 8 小时。必须在脚本开头或配置中统一设定：
date_default_timezone_set('Asia/Shanghai');
这个调用要放在所有 date() 调用之前；如果用 Composer 加载框架（如 Laravel），通常已在启动文件里处理，但自写日志逻辑仍需自查。
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖
php.ini的date.timezone—— 有些共享主机不允许修改，且易被忽略 - 不要在每次日志写入前都调用
date_default_timezone_set()—— 重复设置无效，还可能触发警告 - 验证是否生效：临时加一行
var_dump(date('Y-m-d H:i:s'));看输出是否符合本地营业时间
数据库字段类型要匹配时间戳格式
如果日志表用 MySQL，字段类型选错会导致截断或报错：
- 存
date('Y-m-d H:i:s')→ 字段类型必须是DATETIME或TIMESTAMP（注意TIMESTAMP有自动时区转换行为） - 存
time()→ 字段类型必须是INT(10) UNSIGNED，不能是TINYINT或VARCHAR - 插入时别漏掉字段：SQL 中明确写出时间字段名，例如
INSERT INTO order_log (order_id, action, created_at) VALUES (?, ?, ?)，参数对应time()或date()结果
批量写日志时别反复调用 time() 获取同一时刻
一个订单可能触发多条日志（如“创建”“支付回调”“发货”），如果每条都单独调用 time()，在毫秒级并发下可能出现顺序倒置（比如“发货”时间戳比“支付”还早）。应提前取一次时间，复用：
$now = time(); logOrderAction($orderId, 'created', $now); logOrderAction($orderId, 'paid', $now); logOrderAction($orderId, 'shipped', $now);
尤其在微服务或异步队列场景下，更要避免分散取时 —— 时间源不一致会让问题排查变得模糊。
真正难的不是加时间戳，而是确保所有日志的时间源统一、时区明确、字段类型不越界。线上出过问题的，十有八九卡在时区没设或 DATETIME 字段被误建为 DATE。
