根本原因是php运行时的时区（date.timezone）与系统时区不一致，导致date()等函数返回时间偏差；crontab按系统时间触发，而php脚本内时间解析依赖自身时区配置，二者基准不同引发逻辑错乱。
PHP脚本里date()返回时间不对，但服务器系统时间正确
根本原因是PHP运行时的时区（date.timezone）和系统时区不一致，而crontab调用PHP脚本时默认继承系统环境，但PHP内部仍按自己的时区解析时间。比如服务器设为Asia/Shanghai，而php.ini里是UTC，date('Y-m-d H:i')就会比预期慢8小时。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先确认PHP实际生效的时区：
php -r "echo date_default_timezone_get();" - 检查是否被脚本内
date_default_timezone_set()覆盖——哪怕只调用一次，后续所有date()都受其影响 - 不要依赖
/etc/localtime或timedatectl的结果来判断PHP行为，它只管自己那套 - 若用
php-fpm，注意www.conf里可能有单独的php_admin_value[date.timezone]，优先级高于php.ini
crontab执行PHP脚本，定时逻辑错乱（如该02:00跑的任务提前到01:00）
典型于夏令时切换期或跨时区部署场景：crontab按系统本地时间触发，但PHP脚本里用strtotime('today 02:00')却按PHP时区算，两者基准不同就偏移。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 统一用UTC写crontab，并在PHP中显式指定时区：
date_default_timezone_set('Asia/Shanghai');，避免隐式依赖 - 别写
0 2 * * *这种“每天2点”，改用0 2 * * * /usr/bin/php -d date.timezone=Asia/Shanghai /path/to/script.php - 如果任务依赖数据库时间（如
NOW()），确认MySQL的time_zone也设为+08:00或Asia/Shanghai，否则PHP和DB时间基准不一致 - 用
date -u和php -r "echo date('Y-m-d H:i:s e');"同时对比，能快速定位偏差来源
使用Carbon或DateTime类时，new DateTime()结果不符合预期
Carbon默认使用PHP配置的时区，但构造时若传入字符串（如new DateTime('2024-01-01')）且无时区标识，会按当前date.timezone解释；而new DateTime('2024-01-01 UTC')则强制按UTC解析——混用极易出错。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 始终显式指定时区：
new DateTime('2024-01-01', new DateTimeZone('Asia/Shanghai')) - Carbon用户可全局设置：
Carbon::setTestNow(Carbon::now('Asia/Shanghai'))用于测试，但生产环境更推荐构造时传参 - 避免
Carbon::parse('2024-01-01')这种写法——它依赖当前上下文时区，不可靠 - 从数据库读取时间戳后转Carbon，优先用
Carbon::createFromFormat()并指定原始时区，而不是直接new Carbon($db_time)
docker容器里PHP时区始终不对
Docker镜像（尤其alpine系）默认不安装tzdata，或/etc/timezone缺失，导致date.timezone设了也无效，date()仍回退到UTC。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 基础镜像加装时区数据：
RUN apk add --no-cache tzdata && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime（Alpine） - 在
php.ini中明确写date.timezone = Asia/Shanghai，不要只靠环境变量TZ - 如果用
docker-compose.yml，除了environment: {TZ: Asia/Shanghai}，还得挂载时区文件：volumes: ['/etc/localtime:/etc/localtime:ro'] - 验证方式：
docker exec -it your-php-container php -r "var_dump(date_default_timezone_get(), date('Y-m-d H:i:s e'));"
时区问题最麻烦的不是设不对，而是部分环节对了、部分环节没对，表面看时间正常，一到跨天或计划触发就露馅。盯住date_default_timezone_get()的返回值，比任何文档都准。
