PHP时间戳转日期偏差±8小时的根本原因是默认时区为UTC而非本地时区，需用date_default_timezone_set('Asia/Shanghai')显式设置，避免依赖php.ini或框架未覆盖的配置。
PHP 时间戳转日期时出现 ±8 小时偏差？不是代码写错了，是 date_default_timezone_set() 没生效或设错了时区——绝大多数“时区错乱”问题，根子都在这里，而不是时间戳本身有问题。
为什么 date() 和 strtotime() 总差 8 小时？
PHP 默认时区是 UTC（协调世界时），不是你本地时区。哪怕服务器在中国大陆，date('Y-m-d H:i:s') 也按 UTC 输出，看起来就像比北京时间晚 8 小时。
- 检查当前默认时区：
date_default_timezone_get()，别只看 php.ini；运行时可能被覆盖 - 不要依赖 php.ini 的
date.timezone—— CLI 和 Web SAPI 可能加载不同配置，用phpinfo()看实际生效值 - 在脚本开头强制设置：
date_default_timezone_set('Asia/Shanghai')，而非'PRC'（已废弃，部分旧版本不识别） - 注意：Laravel、ThinkPHP 等框架通常在启动时已设好时区，手动再设可能被覆盖，优先查框架配置（如 Laravel 的
config/app.php中的'timezone'）
DateTime 类比 date() 更可靠吗？
是的，DateTime 显式携带时区信息，避免隐式依赖全局默认时区，更适合跨时区业务（如用户分布在不同时区）。
- 创建带时区的时间对象：
new DateTime('2024-06-01 12:00:00', new DateTimeZone('Asia/Shanghai')) - 转换时区不改时间值，只改表示：
$dt->setTimezone(new DateTimeZone('UTC')) - 从时间戳创建：
DateTime::createFromFormat('U', $timestamp)->setTimezone(new DateTimeZone('Asia/Shanghai'))，注意createFromFormat('U', ...)默认按 UTC 解析时间戳 - 避免直接传字符串给
new DateTime('2024-06-01')—— 它会按默认时区解释，行为不可控
MySQL 存储时间戳时，INT 和 TIMESTAMP 字段哪种更安全？
存时间戳用 INT（Unix timestamp）最可控；用 TIMESTAMP 字段会自动做时区转换，极易引发 PHP 与数据库之间的“感知差异”。
立即学习“PHP免费学习笔记（深入）”；
-
TIMESTAMP列：MySQL 接收时按当前 session 时区转成 UTC 存，查询时再按 session 时区转回 —— 如果 PHP 连接 MySQL 时没显式设SET time_zone = '+08:00'，就会错乱 -
INT列：纯粹存整数，无自动转换，PHP 读出来直接date('Y-m-d', $int)即可，前提是 PHP 时区已设对 - 如果必须用
TIMESTAMP，务必在 PDO 连接后执行：$pdo->exec("SET time_zone = '+08:00'")（或对应时区偏移） - 注意：
DATETIME不做时区转换，但它是字符串格式，PHP 处理时仍需注意解析时区上下文
线上环境时区突然失效？检查这三处
开发机正常、上线就错，大概率是部署环节漏掉了时区设定。
- CLI 脚本（如 cron）：不继承 Web 服务器的 php.ini，必须在脚本内调用
date_default_timezone_set() - Docker 容器：基础镜像（如
php:8.2-cli）默认时区是UTC，需在 Dockerfile 加ENV TZ=Asia/Shanghai && ln -snf /usr/share/zoneinfo/$TZ /etc/localtime - 云函数（如阿里云 FC、腾讯云 SCF）：运行环境时区不可靠，严禁依赖系统默认，每次函数入口都应显式设置
真正麻烦的从来不是“怎么转”，而是“在哪设、谁覆盖了它、什么时候被悄悄重置”。时区问题往往藏在初始化链路的缝隙里，而不是某一行 date() 调用上。
