datetime 必须严格遵守规则：构造需 try/catch、优先用 createfromformat、format 格式符大小写敏感（m 月/i 分）、时区须显式传入、diff 用 %r%a 获取带符号天数、gettimestamp 返回 utc 秒数。
DateTime 类不是“怎么用”的问题，而是“必须按哪几条规则用，否则一定出错”。它不像 date() 那样容忍模糊输入，稍不注意就会抛异常、返回错值、或在时区上悄悄翻车。
new DateTime() 构造失败的三种典型现象
传空字符串、非法日期（如 "2023-02-30"）、或含歧义时区信息（如 "2023-01-01 12:00:00 +0530" 在某些 PHP 版本下解析失败）时，new DateTime() 不会返回 false，而是直接抛 Exception。这不是 bug，是设计——它拒绝沉默失败。
- 永远用
try/catch包裹构造逻辑，尤其处理用户输入或数据库字段时 - 对固定格式字符串（如
YYYYMMDD），优先用DateTime::createFromFormat('Ymd', $str)，它返回false而非异常，便于判断 - 避免依赖自动识别：像
"10/05/2023"在不同地区可能被当成m/d/Y或d/m/Y，必须显式指定格式
format() 里最常写错的五个格式符
format() 不报错，但写错就输出错得离谱。比如把分钟写成 m（月份），结果日期变成 "2023-10-24 15:10:45" → "2023-10-24 15:10:45"（m 是 10 月，不是 10 分钟）。
-
m是月份，i才是分钟；s是秒，S是英文序数后缀（"st"/"nd"） -
H（24 小时制）和h（12 小时制）混用会导致上午/下午全乱，比如"h:i A"和"H:i"输出时间完全不同 -
d（带前导零）和j（无前导零）影响对齐，但不报错；中文场景下直接写"Y年m月d日"没问题，format()不处理中文，只透传 -
u返回微秒（6 位），要毫秒得手动floor($dt->format('u') / 1000) - 年份用
Y（4 位），别用y（2 位）——后者在解析时间戳时可能误判为 19xx 年
时区不是“设一次就完事”，而是每次构造都得确认
date_default_timezone_set('Asia/Shanghai') 只影响未显式指定时区的 new DateTime() 调用，但它不改变已有对象的时区上下文，也不保证字符串解析逻辑一致。更危险的是：如果字符串本身含时区（如 "2023-01-01T12:00:00Z"），PHP 会优先按字符串里的时区解析，忽略全局设置。
- 生产环境所有
new DateTime()都应显式传入DateTimeZone对象：new DateTime('now', new DateTimeZone('Asia/Shanghai')) - 从 MySQL
DATETIME字段读出的值无时区信息，必须按存储时区解释，不能假设是本地时间 -
getTimestamp()返回的是 UTC 秒数，跟当前对象时区无关——这是唯一真正中立的值，跨时区计算差值时应优先用它 - 调用
setTimezone()不是“换显示”，而是真转换时间值，比如北京时间 10:00 转纽约时区，会变成前一天 21:00
diff() 计算天数差时，别直接读 $interval->days
$date1->diff($date2)->days 看起来直白，但它只返回总天数，不包含年月部分的归一化。比如 2023-01-01 到 2024-01-01 的 days 是 365，但若中间有闰年或跨月计算，days 可能漏掉进位逻辑；更严重的是，它不反映方向（正负）。
- 要用
$interval->format('%r%a')，%r表示符号（+/-），%a是总天数，才能准确表达“早/晚几天” - 两个日期相减，若需严格按日历天数（而非 24 小时块），确保两者在同一时区下构造，否则
diff()会先做时区转换再算差 - 对
YYYYMMDD字符串，先用DateTime::createFromFormat('Ymd', $str)解析，再diff()，比直接new DateTime($str)更可控 - 需要毫秒级精度差值？
diff()不支持，得用getTimestamp()和getMicrotime()手动算
diff() 忘了加 %r。这些点不盯死，调试成本远高于写代码本身。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
