多数据库场景下Yii时间戳需统一用DATETIME+PHP层控制，禁用数据库自动更新；各连接须显式设时区；行为类应动态适配字段名与类型；跨库同步需传递源库时间戳并校验一致性。
Yii框架多数据库场景下，时间戳行为不能简单复用默认配置——不同数据库对 TIMESTAMP 类型的自动更新机制、时区处理、精度支持（如 MySQL 5.6+ 支持微秒，PostgreSQL 默认带时区）差异明显，直接套用 TimestampBehavior 容易导致创建/更新时间错乱、跨库查询结果不一致、甚至写入失败。
统一用 DATETIME + PHP 层控制
放弃依赖数据库自动更新 TIMESTAMP 字段，改用 DATETIME（或 TIMESTAMP WITHOUT TIME ZONE）类型，并在 PHP 层完全接管时间赋值。这样可规避 MySQL 的隐式时区转换、PostgreSQL 对 TIMESTAMP WITH TIME ZONE 的强制归一化等陷阱。
- 数据库建表时统一使用
DATETIME，不设DEFAULT CURRENT_TIMESTAMP或ON UPDATE CURRENT_TIMESTAMP - 模型中启用
TimestampBehavior，value固定为new \yii\db\Expression('NOW()')（适用于 MySQL）或new \yii\db\Expression("CURRENT_TIMESTAMP")（兼容 PostgreSQL） - 若需毫秒级精度（如日志、审计），改用
date('Y-m-d H:i:s.u')并确保字段类型为DATETIME(6)或TIMESTAMP(6)
多数据库连接需独立配置 time zone
Yii 应用只有一个全局 timeZone 配置，但多个数据库连接可能运行在不同时区服务器上（例如主库在阿里云上海，从库在 AWS 新加坡）。此时仅靠 date_default_timezone_set() 不够，必须为每个 DB 连接显式设置时区。
- 在
config/db.php中为每个Connection实例添加'on afterOpen' => function ($event) { $event->sender->createCommand("SET time_zone = '+08:00'")->execute(); } - 若使用读写分离，主库和从库的时区指令应保持一致，避免
created_at写入主库是2026-08-17 13:54:00，但从库查出来变成2026-08-17 05:54:00 - 验证方式：执行
SELECT @@time_zone, NOW(), SYSDATE()，确认三者返回时间逻辑一致
行为类需适配字段存在性与类型差异
不同数据库的表结构未必都含 created_at/updated_at。硬编码字段名会报错；更麻烦的是，有些库用 create_time，有些用 ts_created，还有些只存 Unix 时间戳整数。
- 不要在基类
behaviors()中写死字段名，改用动态判断：if ($this->hasAttribute('created_at')) { ... } - 对整型时间戳字段（如
created_time int(11)），value应改为time()而非Expression('NOW()')，否则 MySQL 会尝试把字符串转整数，导致 0 值 - 推荐封装一个轻量行为类，根据当前模型的属性类型自动选择赋值方式（字符串格式 or 整数格式），无需每个模型重写
跨库同步时的时间一致性校验
当使用双写或消息队列做多库同步时，源库和目标库的时间戳可能因网络延迟、消费者处理耗时而出现毫秒级偏差。业务若依赖“精确顺序”，需额外保障。
- 在同步消息体中附带源库写入时的
created_at值（不是当前时间），目标库严格按此值写入，而非调用本地NOW() - 对关键操作（如订单支付成功时间），在源库生成一个全局单调递增的逻辑时间戳（如基于 Redis INCR 或雪花 ID 的时间部分），作为排序依据，绕过系统时钟不可靠问题
- 定期跑脚本比对主从库同一条记录的
updated_at差值，超阈值（如 500ms）即告警
