php时区配置未生效需检查date.timezone是否被覆盖：确认php.ini中设为asia/shanghai，排除运行时date_default_timezone_set()干扰，验证thinkphp配置不替代php底层时区，同步校准mysql与系统时钟。
PHP 时区配置没生效？检查 date.timezone 是否被覆盖
ThinkPHP 启动后时间仍不对，大概率是 PHP 层时区没真正生效。不是写了 date.timezone = Asia/Shanghai 就万事大吉——它可能被 php.ini 多个位置、或运行时调用的 date_default_timezone_set() 覆盖。
实操建议：
- 在项目入口（如
public/index.php）顶部加一行var_dump(date_default_timezone_get()); die;，确认实际生效的时区 - 检查是否在 ThinkPHP 配置（如
config/app.php）里手动调用了date_default_timezone_set('PRC')——PRC已废弃，必须用Asia/Shanghai - 云服务器上可能有多个
php.ini（CLI 和 FPM 独立），用php --ini和phpinfo()分别查加载路径
ThinkPHP 自带时区配置 vs PHP 底层时区
ThinkPHP 的 default_timezone 配置项（在 config/app.php 中）只影响框架内部分时间格式化逻辑（比如 think\facade\Date），不改变 date()、time() 或数据库写入行为。它不能替代 PHP 的 date.timezone。
实操建议：
- 务必优先在
php.ini中设好date.timezone = Asia/Shanghai，而不是依赖框架配置 - 如果使用
Carbon或DateTime类，它们默认读取 PHP 时区，和 ThinkPHP 配置无关 - 数据库时间字段（如
datetime）写入时若用date('Y-m-d H:i:s')，结果取决于 PHP 时区，不是数据库时区
MySQL 时区和 PHP 不一致导致时间错乱
PHP 显示正确，但数据库里存的时间比实际早/晚 8 小时，常见原因是 MySQL 服务端时区仍是 SYSTEM（常对应 UTC），而系统时间却已校准为 CST。
实操建议：
- 登录 MySQL 执行
SELECT @@global.time_zone, @@session.time_zone;，确认不是SYSTEM或+00:00 - 临时设置：执行
SET GLOBAL time_zone = '+8:00';（重启失效） - 永久设置：在
/etc/mysql/my.cnf的[mysqld]下加default-time-zone = '+8:00'，然后重启mysqld - 注意：修改 MySQL 时区不影响已存数据，只影响后续读写；历史时间字段不会自动转换
云服务器系统时间漂移或未同步
即使 PHP 和 MySQL 都配对了，某天发现日志时间突然跳变，可能是系统时间本身不准。尤其低配云服务器（如腾讯云轻量、阿里云共享型）容易因 CPU 资源争抢导致时钟漂移。
实操建议：
- 运行
timedatectl status，看System clock synchronized:是否为yes - 如果否，先装
chrony（推荐）或ntpd：apt install chrony（Ubuntu/Debian）或yum install chrony（CentOS） - 启动并启用：
systemctl enable chrony && systemctl start chrony - 验证：
chronyc tracking查偏移量，chronyc sources -v查 NTP 源是否正常
复杂点在于：PHP 时区、MySQL 时区、系统时钟三者要各自独立校准，又得彼此对齐。少一个环节，就可能在定时任务、日志分析、订单超时判断上出隐蔽问题。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
