DateTime类是现代PHP项目处理日期时间的首选，date()仅适用于单次本地时区简单格式化；涉及时区、计算、解析等必须用DateTime，且需警惕构造陷阱与时区转换规范。
PHP 里处理日期时间，date() 函数够用但脆弱，DateTime 类才是现代项目的实际选择——尤其涉及时区、加减、格式互转或跨日计算时，date() 容易出错且难以维护。
什么时候该用 date()，什么时候必须换 DateTime
date() 适合单次、无状态、本地时区的简单格式化，比如写日志时间戳：date('Y-m-d H:i:s')。但它不保存时区信息，所有计算都基于当前 date_default_timezone_set() 设置，且无法链式操作。
DateTime 必须用于以下场景：
- 需要明确指定时区（如
new DateTime('2024-06-01', new DateTimeZone('Asia/Shanghai'))） - 做日期加减（
$dt->modify('+3 days')或$dt->add(new DateInterval('P2M'))） - 比较两个不同来源的时间（数据库时间 vs 用户提交时间）
- 解析模糊字符串（如
'next Monday'、'last day of next month'）
用 date() 硬算跨月/跨年日期，极易漏掉闰年、月末天数差异等边界问题。
立即学习“PHP免费学习笔记（深入）”；
DateTime 构造时的三个常见陷阱
构造 DateTime 对象看似简单，但参数稍有偏差就会得到意外结果：
- 传空字符串或
null：会默认取当前时间，但时区是系统默认值，不是 UTC —— 显式传'now'更清晰 - 只传日期（如
'2024-05-20'）：它会被解释为「当天 00:00:00」，但时区取决于构造上下文，不是 UTC；建议补上时区：new DateTime('2024-05-20', new DateTimeZone('UTC')) - 传 Unix 时间戳（如
@1716220800）：必须带@前缀，否则会被当作文本解析成错误日期
错误示例：new DateTime(1716220800) → 解析为公元 1716 年；正确写法：new DateTime('@1716220800')。
格式化输出：别再混用 date() 和 DateTime::format()
一旦用了 DateTime 对象，就应统一用其 format() 方法输出，而不是再拿 date() 去套 $dt->getTimestamp() —— 多此一举还可能丢失毫秒或时区上下文。
-
$dt->format('Y-m-d H:i:s')是标准做法 - 需要 ISO 8601 格式？直接
$dt->format(DateTimeInterface::ISO8601)（注意是接口常量） - 想输出带毫秒？
DateTime默认不存毫秒，需用DateTimeImmutable+microtime(true)手动构造，或改用DateTimeImmutable::createFromFormat()配合u格式符
特别注意：DateTime::format() 不受 date_default_timezone_set() 影响，它只按对象自身绑定的时区输出。
时区转换和存储前的必做动作
Web 应用最常踩的坑：用户看到的是本地时间，数据库存的却是服务器时区时间，导致查询错乱。正确流程是：
- 接收用户输入（如表单时间）后，立刻用用户时区构造
DateTime对象 - 立即转成 UTC：
$dt->setTimezone(new DateTimeZone('UTC')) - 存 UTC 时间戳或 ISO 字符串到数据库
- 读取时，从 UTC 转回用户时区再输出
不要依赖 MySQL 的 TIMESTAMP 自动时区转换，PHP 层控制更可靠。另外，DateTimeZone::listIdentifiers() 可查可用时区列表，避免硬写 'GMT+8' 这类非法标识符。
真正难的不是语法，而是每次构造、解析、转换时，是否清楚当前对象绑定的时区是什么、modify() 是否改变了它、format() 输出是否符合预期——这些细节不盯住，线上时间错几小时都查不出原因。
