根本解法是在 Dockerfile 中通过 php.ini 的 date.timezone 明确设置时区，如 RUN echo 'date.timezone = Asia/Shanghai' >> /usr/local/etc/php/conf.d/docker-php-ext-timezone.ini，确保 PHP 启动前生效，而非依赖挂载 /etc/localtime 或环境变量 TZ。
容器内 PHP 时间戳与宿主机不一致
ThinkPHP 项目在 Docker 中生成的 date()、time() 或数据库写入的时间比宿主机快/慢几小时，本质是容器默认使用 UTC 时区，而宿主机通常是 Asia/Shanghai。PHP 不会自动读取宿主机时区，哪怕 docker run -v /etc/localtime:/etc/localtime:ro 挂载了，PHP 还是可能忽略它。
- 确认方式：在容器内执行
php -r "echo date('Y-m-d H:i:s e');"，看输出的时区标识（如UTC或Europe/London）是否符合预期 - 根本解法不是只挂载
/etc/localtime，而是要让 PHP 明确知道时区 —— 通过php.ini的date.timezone配置项 - 若用官方
php:apache或php:fpm镜像，date.timezone默认为空，PHP 会回退到 UTC
如何在 Dockerfile 中正确设置 PHP 时区
别依赖运行时挂载或宿主机环境变量覆盖，Dockerfile 内固化配置最可靠。尤其对 ThinkPHP 这类依赖 date_default_timezone_set() 或 ini 设置的框架，必须在 PHP 启动前生效。
- 在
Dockerfile中添加：RUN echo 'date.timezone = Asia/Shanghai' >> /usr/local/etc/php/conf.d/docker-php-ext-timezone.ini
- 不要用
ENV TZ=Asia/Shanghai+ln -sf /usr/share/zoneinfo/$TZ /etc/localtime组合 —— 这只影响系统级时间命令（如date），不影响 PHP 内部时区逻辑 - 如果已用
php.ini自定义文件，确保该文件被 PHP 加载（可通过php --ini查看扫描路径，优先级高的 conf.d 目录更稳妥） - 修改后务必重建镜像：
docker build -t myapp .，而不是仅docker-compose up --build（避免缓存跳过 RUN）
ThinkPHP 自身的时区配置要不要动
ThinkPHP 的 app.timezone 配置（如 config/app.php 中的 'timezone' => 'Asia/Shanghai'）只影响框架内部部分时间格式化逻辑（比如日志时间、think\facade\Date），它**不会覆盖 PHP 底层的时区设置**。也就是说，date('Y-m-d')、strtotime()、ORM 写入数据库的 NOW() 结果，仍由 PHP 的 date.timezone 决定。
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 建议保持 ThinkPHP 的
app.timezone与php.ini中的date.timezone一致，避免混淆 - 如果项目中大量使用
date_default_timezone_set('Asia/Shanghai')手动设置，应删掉 —— 容器里 PHP 已有全局时区，重复设置反而可能被后续代码覆盖或引发 warning - 验证方法：在控制器里打印
date_default_timezone_get()，应返回Asia/Shanghai，而非UTC
为什么 docker run --privileged 或 systemd-timesyncd 不能解决 PHP 时区问题
容器时间同步（如 NTP 校准）和 PHP 时区是两回事。前者解决的是“当前绝对时间是否准确”，后者解决的是“PHP 把这个绝对时间解释成哪个时区的时间”。即使容器时间毫秒级精准，只要 date.timezone 是 UTC，date('H:i') 就永远比北京时间晚 8 小时。
立即学习“PHP免费学习笔记（深入）”；
-
--privileged允许容器修改系统时钟，但 ThinkPHP 不需要也不应该这么做；且大多数生产环境禁止启用该参数 -
systemd-timesyncd或ntpd容器只对本容器的clock_gettime()系统调用有效，PHP 的time()函数底层虽调用它，但时区转换仍走自己的规则 - 真正需要同步的，是宿主机与容器的时区语义一致性，而不是时钟数值本身 —— 所以核心还是
date.timezone
date.timezone。挂载 /etc/localtime、改 TZ 环境变量、甚至开 NTP，都只是绕弯子。直接在 PHP 配置里写死时区，是最小侵入、最高确定性的做法。 
