PHP和JavaScript时区需显式统一：PHP用date_default_timezone_set('Asia/Shanghai')，JS依赖后端传ISO 8601带时区时间；全链路应以UTC存储传输，仅展示层转换。
PHP 和 JavaScript 的时区默认不一致，直接用 date() 或 new Date() 会出错——后端存的是 UTC 或服务器本地时间，前端显示却按浏览器时区解析，结果差几个小时是常态。
PHP 里别依赖系统时区，显式设置 date_default_timezone_set()
很多 PHP 脚本靠服务器 /etc/timezone 或 php.ini 的 date.timezone 配置，但一旦部署到不同环境（比如 Docker 容器没配、云函数无权改 ini），date() 就悄悄退回到 UTC 或报警告。必须在逻辑入口（如 index.php 或框架中间件）第一行主动设：
date_default_timezone_set('Asia/Shanghai');注意：Asia/Shanghai 是标准写法，不能写成 GMT+8 或 UTC+8——PHP 不认这种偏移字符串；也不要用 PRC，它已被弃用且行为不稳定。
- 常见错误：在类方法里重复调用
date_default_timezone_set()，多次设置无害但没必要，且可能被后续代码覆盖 - 如果项目要支持多时区用户，不要全局设死，而应在用户登录后根据其偏好动态设，并用
DateTimeZone实例做转换 -
date_default_timezone_get()可用于调试，但别在生产逻辑里依赖它的返回值作分支判断
JavaScript 拿不到 PHP 的时区设置，得靠后端传标准时间戳或 ISO 字符串
JS 运行在浏览器，完全不知道 PHP 设了什么时区。试图用 Intl.DateTimeFormat().resolvedOptions().timeZone 读浏览器时区再发给后端对齐？不可靠——用户可能开了代理、改了系统时间、或用旧版 Safari（不支持该 API）。稳妥做法是：后端统一输出带时区信息的时间表示。
立即学习“PHP免费学习笔记（深入）”；
- 推荐用 ISO 8601 格式：PHP 中用
(new DateTime())->format('c')（输出类似2024-05-22T14:30:00+08:00），JS 里new Date('2024-05-22T14:30:00+08:00')能正确解析为本地等效时间 - 避免只传 Unix 时间戳（如
1716388200）：JS 的new Date(1716388200 * 1000)没问题，但一旦后端没说明这是“哪个时区的秒数”，就埋下歧义——它本质是 UTC 秒数，但开发者常误以为是“服务端本地时间秒数” - 如果必须传时间戳，API 文档里明确写清：“所有时间戳均为 UTC 自 1970-01-01 起的秒数”
前后端都用 UTC 存储和传输，仅展示层做时区转换
最不容易出错的方案：数据库字段用 DATETIME 存 UTC 时间（不是 TIMESTAMP，后者在 MySQL 里会自动转时区）；PHP 写入前强制转 UTC：
$dt = new DateTime($input, new DateTimeZone('Asia/Shanghai'));
$dt->setTimezone(new DateTimeZone('UTC'));
$utcString = $dt->format('Y-m-d H:i:s');读取时也统一转回用户时区（或前端传来的时区标识）：
$dt = new DateTime($dbRow['created_at'], new DateTimeZone('UTC'));
$dt->setTimezone(new DateTimeZone('Asia/Shanghai'));
echo $dt->format('Y-m-d H:i:s'); // 供模板直接输出- 别在 SQL 里用
NOW()或CURTIME()：它们依赖 MySQL 服务器时区，和 PHP 时区不一致时，数据就乱了 - 前端展示时间时，用
toLocaleString()并指定timeZone选项，而不是靠toString()或手动加减小时 - 日志记录时间务必打 UTC，否则排查跨时区问题时会浪费大量时间
真正难的不是设对一个时区，而是让整个链路（输入 → 存储 → 查询 → 传输 → 渲染）每一步都明确自己处理的是哪个时区的时间。漏掉任意一环，比如 API 返回了没带时区的 2024-05-22 14:30:00，前端就只能靠猜——而猜，永远是时区问题的起点。
