PHP必须显式调用date_default_timezone_set('Asia/Shanghai')，不可依赖系统时区；MySQL需单独配置default-time-zone='+08:00'并用DATETIME类型存储时间，避免TIMESTAMP自动时区转换。
PHP date_default_timezone_set() 必须显式调用
PHP 不会自动继承系统时区，哪怕 /etc/timezone 或 date 命令显示正确，date()、strtotime() 等函数仍可能返回 UTC 时间或报 Warning: date(): It is not safe to rely on the system's timezone settings。必须在脚本开头（或框架的统一入口）显式设置：
-
date_default_timezone_set('Asia/Shanghai')—— 推荐用 IANA 时区名，而非+08:00或PRC - 避免用
ini_set('date.timezone', ...)，它在某些 SAPI（如 CLI）下可能不生效 - 若使用 Composer 自动加载，可在
vendor/autoload.php顶部加该调用，确保所有依赖都受控
MySQL 服务端时区 ≠ PHP 时区，需分别确认
MySQL 默认使用系统时区启动，但可通过 SELECT @@global.time_zone, @@session.time_zone; 查看实际值。常见陷阱是：PHP 设了 Asia/Shanghai，但 MySQL 返回 SYSTEM（即系统时区），而系统时区可能是 UTC —— 导致 NOW() 和 date() 差 8 小时。
- 临时修复：连接后执行
SET time_zone = '+08:00';（推荐用偏移量而非时区名，避免 MySQL 未加载 tzdata） - 持久方案：在
my.cnf的[mysqld]段添加default-time-zone = '+08:00'，然后重启 MySQL - 注意：
CONVERT_TZ(NOW(), '+00:00', '+08:00')性能较差，别在 WHERE 条件里滥用
PDO 连接时自动设置时区最稳妥
靠应用层每次查询前 SET time_zone 容易遗漏，尤其 ORM 或长连接复用场景。PDO 支持在 DSN 中附加 timezone 参数（MySQL 5.7+ / 8.0），或通过 PDO::MYSQL_ATTR_INIT_COMMAND 初始化：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
$pdo = new PDO(
'mysql:host=localhost;dbname=test;charset=utf8mb4',
$user,
$pass,
[
PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = '+08:00'",
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]
);
- 该命令在每次新连接建立时执行，不受连接池或复用影响
- 若用 Laravel，可在
config/database.php的mysql.options中加入对应项 - 不要依赖
SET NAMES utf8mb4同时设时区，二者应分开明确控制
时间字段类型选 DATETIME 而非 TIMESTAMP 更可控
TIMESTAMP 会自动转为 UTC 存储、查询时再转回 session time_zone，看似省事，实则埋雷：当 DBA 修改全局时区、或应用跨时区部署时，同一数据可能被解释成不同本地时间；且 TIMESTAMP 范围仅到 2038 年。
立即学习“PHP免费学习笔记（深入）”；
- 一律用
DATETIME存储“业务意义的时间”（如订单创建时间、发货时间） - 插入前由 PHP 格式化为
'Y-m-d H:i:s'字符串（已按date_default_timezone_set()处理好） - 查询结果中的
DATETIME值直接输出即可，无需额外转换 —— 因为它就是你存进去的那个本地时间点
Intl.DateTimeFormat 都各自维护一套时区上下文，一旦某处漏设或设错，时间就悄悄漂移。最保险的做法是：PHP 和 MySQL 全局统一用 +08:00（而非时区名），所有时间操作都在服务端完成，数据库只存无歧义的字符串格式时间。 
