MySQL建表时用DATETIME配DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP最稳妥，PHP插入时不传时间字段由数据库自动生成，更新时显式设updated_at=NOW()并统一时区可避免8小时偏差。
MySQL建表时如何加 created_at 和 updated_at 时间戳字段
直接在建表语句里用 TIMESTAMP 或 DATETIME 配合默认值和自动更新最稳妥，避免 PHP 层拼时间字符串出错。
-
TIMESTAMP自动时区转换（存 UTC，查本地时区），DATETIME原样存储，无时区处理 —— 若项目跨时区且依赖数据库自动维护，优先选TIMESTAMP - MySQL 5.6.5+ 支持
DATETIME的DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP，不必强求TIMESTAMP - 一个表最多只能有一个
TIMESTAMP字段带CURRENT_TIMESTAMP默认值（旧版本限制），DATETIME没这限制
CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );
PHP插入数据时不手动传时间戳的几种写法
让数据库自己填时间，PHP 就别碰 created_at / updated_at 字段，否则容易覆盖、不一致或触发时区混乱。
- INSERT 语句里完全不提这两个字段：
INSERT INTO users (name) VALUES ('Alice') - 用 PDO 时，绑定参数也跳过它们：
$stmt->execute(['name' => 'Bob']) - Laravel Eloquent 默认自动处理，但需确认模型里没显式赋值给
created_at—— 检查是否误写了$model->created_at = date('Y-m-d H:i:s')
PHP更新数据时正确触发 updated_at 自动更新
关键不是 PHP 怎么写，而是 SQL 语句有没有真正“修改”到行 —— 如果 SET 的字段值和原值一样，MySQL 8.0+ 默认不会触发 ON UPDATE（除非开启 sql_mode=TRADITIONAL 或改用 UPDATE ... SET updated_at = NOW() 显式更新）。
- 安全做法：更新时显式设置
updated_at = NOW()，尤其用于软删除、状态切换等可能值不变的场景 - 用 PDO 执行：
$pdo->prepare("UPDATE users SET status = ?, updated_at = NOW() WHERE id = ?")->execute([$status, $id]) - ORM 如 ThinkPHP 的
save()默认会写updated_at，但 CodeIgniter 3 的update()不会，得自己加'updated_at' => date('Y-m-d H:i:s')
时区不一致导致时间戳看起来“慢8小时”的原因和修复
不是 PHP 错，也不是 MySQL 错，是两边时区没对齐。常见组合：PHP 设了 date_default_timezone_set('Asia/Shanghai')，但 MySQL 的 time_zone 还是 +00:00。
立即学习“PHP免费学习笔记（深入）”；
- 查 MySQL 当前时区：
SELECT @@global.time_zone, @@session.time_zone; - 临时改会话时区：
SET time_zone = '+08:00';（仅当前连接有效） - 永久生效要改 MySQL 配置文件
my.cnf，加default-time-zone = '+08:00'并重启 - 更推荐统一用 UTC 存储，PHP 层用
DateTime转换显示 —— 避免后期国际化踩坑
updated_at 变；其次是 MySQL 时区和 PHP 时区各自设了一套，结果日志里时间对不上。这两处一错，排查起来比加字段本身花的时间多得多。 
