PHP 8.3 中应以 UTC 为数据库时间基准，应用层显式转换时区。需明确数据库与 PHP 各自时区职责，避免隐式依赖；推荐写入前转 UTC、读取后按需转本地时区，确保跨环境一致性。
PHP 8.3 中通过 database（如 MySQL）获取时间时，要确保与 PHP 时区一致，关键不是“让数据库去匹配 PHP”，而是**明确各层时区职责、统一时间基准，并在必要处显式转换**。直接依赖数据库自动适配 PHP 时区是不可靠的，尤其在跨环境部署时极易出错。
确认数据库自身的时区设置
MySQL 默认不读取 PHP 的时区，它有自己的时区配置：
- 查当前会话时区：
SELECT @@session.time_zone;—— 常见返回SYSTEM（即系统时区）或具体值如+08:00 - 查全局时区：
SELECT @@global.time_zone; - 若返回
SYSTEM，则实际取决于 Linux 系统时区（timedatectl status），而非 PHP 的date.timezone - 不建议设为
SYSTEM，应显式设为'+08:00'或'Asia/Shanghai'（MySQL 8.0+ 支持 IANA 名，但需加载时区表）
PHP 侧避免隐式依赖数据库时区
用 PDO 或 mysqli 执行 NOW()、CURDATE() 等函数时，结果受 MySQL 服务端时区影响，和 PHP 当前 date_default_timezone_get() 无关。所以：
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
- 不要写
$time = $pdo->query("SELECT NOW()")->fetchColumn();然后直接当北京时间用 —— 它可能来自 UTC 或其他偏移 - 改用
date('Y-m-d H:i:s')获取 PHP 侧当前时间（前提是已设对默认时区），更可控 - 若必须用数据库时间，应在 SQL 中显式转换：
SELECT CONVERT_TZ(NOW(), '+00:00', '+08:00');或SELECT CONVERT_TZ(NOW(), 'UTC', 'Asia/Shanghai');
存储与读取策略：推荐 UTC 基准 + 应用层转换
最健壮的做法是绕过“让两边一致”的纠结，转而建立清晰分工：
立即学习“PHP免费学习笔记（深入）”；
- 数据库字段类型优先用
TIMESTAMP（自动按服务器时区存取）或统一用DATETIME存储 UTC 时间 - 写入前，PHP 将时间转为 UTC：
(new DateTime())->setTimezone(new DateTimeZone('UTC'))->format('Y-m-d H:i:s') - 读取后，按用户/业务需要转为本地时区：
$dt->setTimezone(new DateTimeZone('Asia/Shanghai')) - 这样，无论 MySQL 是 UTC 还是 CST，PHP 都能精确控制输入输出，不被服务端配置绑架
框架与 ORM 场景（如 Laravel）
现代框架通常自带时区处理逻辑，但需检查是否启用：
- Laravel 中，
config/app.php的'timezone' => 'Asia/Shanghai'会影响模型时间自动转换，但仅限 Eloquent 的created_at/updated_at等字段 - 原生 SQL 查询（
DB::select()）仍走数据库原生逻辑，不受该配置影响 - 可在数据库连接配置中加
'options' => [PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = '+08:00'"]，强制会话级时区（注意：只对当前连接生效）
