date() 用本地时区，gmdate() 强制 UTC，故结果不同；前者适合本地展示，后者用于 HTTP 头、Cookie 等需 UTC 的场景，且不受 date_default_timezone_set() 影响。
date() 和 gmdate() 输出结果为什么不一样
因为 date() 用的是服务器本地时区（或 date_default_timezone_set() 设置的时区），而 gmdate() 强制用 UTC 时间，不考虑任何时区偏移。
常见错误现象：同一台机器上，date('Y-m-d H:i:s') 返回 "2024-05-20 15:30:45"，gmdate('Y-m-d H:i:s') 却返回 "2024-05-20 07:30:45"——这说明当前时区是 UTC+8，差了 8 小时。
- 使用场景：
date()适合展示给本地用户看的时间（比如后台日志、用户界面）；gmdate()适合生成 HTTP 头（如Last-Modified）、Cookie 过期时间、跨时区统一时间戳比对 - 参数完全一致，格式字符串、时间戳参数（第二个可选参数）行为一模一样，唯一区别就是时区基准
- 性能无差异，两者都是纯函数调用，不涉及 I/O 或系统调用
不设时区时 date() 行为不可靠
PHP 5.4+ 默认时区是 UTC，但很多老环境或未显式配置的服务器仍可能 fallback 到系统时区（如 /etc/timezone 或 date.timezone 未设置），导致 date() 结果在不同机器上不一致。
容易踩的坑：date('c') 在没设时区时可能输出 "2024-05-20T15:30:45+08:00"，也可能输出 "2024-05-20T15:30:45+00:00"，取决于环境，而 gmdate('c') 永远带 +00:00。
立即学习“PHP免费学习笔记（深入）”；
- 务必在项目启动时调用
date_default_timezone_set('Asia/Shanghai')，别依赖默认值 - 如果需要 UTC 时间，优先用
gmdate()，而不是date()配合date_default_timezone_set('UTC')——后者会影响其他地方的date()调用，全局副作用大 -
gmdate()不受date_default_timezone_set()影响，它是硬编码走 UTC 的
和 DateTime 类混用时要注意时区继承
DateTime 对象自带时区信息，date() 和 gmdate() 是纯函数，不感知对象状态。混用时容易误以为“用了 DateTime 就安全了”，其实不然。
示例：$dt = new DateTime('2024-01-01'); echo date('Y-m-d', $dt->getTimestamp()); —— 这里 date() 仍按当前默认时区格式化，不是 $dt 的时区。
- 正确做法：用
$dt->format('Y-m-d')，它尊重对象自身的时区 - 若必须用
gmdate()，可用$dt->setTimezone(new DateTimeZone('UTC'))->format('Y-m-d H:i:s')，比直接传getTimestamp()更可靠 - 从数据库读取时间戳（如 MySQL
UNIX_TIMESTAMP()）再喂给date()，要确认该时间戳是本地时间还是 UTC 时间——错配会导致固定偏差 8 小时（或其他时区差）
HTTP 响应头里必须用 gmdate()
HTTP 规范明确要求 Last-Modified、Expires、Cache-Control: max-age 等时间字段必须用 RFC 1123 格式且基于 GMT（即 UTC）。用 date() 输出会违反标准，部分代理或浏览器可能拒绝缓存或报错。
错误示例：header('Last-Modified: ' . date(DATE_RFC1123, $ts)); —— 如果当前时区不是 UTC，这个头就错了。
- 正确写法：
header('Last-Modified: ' . gmdate(DATE_RFC1123, $ts)); -
DATE_RFC1123本身不含时区符号，gmdate()保证时间值是 UTC，所以组合起来才合规 - 同理，
setcookie()的$expires参数是 Unix 时间戳（UTC 秒数），但 cookie 字符串里的Expires=字段仍需用gmdate()格式化
真正麻烦的不是记不住哪个函数该用，而是忘了“时间值”和“时间显示格式”是两回事——gmdate() 不改变时间值，只确保格式化动作锚定在 UTC 基准上。一旦漏掉，问题往往出现在跨时区部署或 CDN 缓存环节，查起来费劲。
