datetimeimmutable 所有修改方法均返回新对象，原对象不变；常见错误是忽略返回值、dateinterval 格式错误、时区切换后误用 modify、月底加月非对称。
DateTimeImmutable 的所有修改方法（如 modify、add、sub、setTimezone）都返回新对象，原对象始终不变——这是它和 DateTime 最本质的区别。踩坑不是因为“不会改”，而是误以为“会改”，结果在链式调用或变量复用时丢了中间值。
为什么 $date->modify('+1 day') 后 $date 还是旧时间？
因为 modify 不改变 $date 本身，只返回新实例。新手常写成：
$date = new DateTimeImmutable('2026-10-01');
$date->modify('+1 day'); // ❌ 忘记接收返回值
echo $date->format('Y-m-d'); // 输出 2026-10-01，不是 2026-10-02
正确做法必须显式赋值：
$date = $date->modify('+1 day');- 或一步到位：
$nextDay = $date->modify('+1 day'); - 若用于条件分支，别漏掉所有分支的赋值，否则某条路径下变量仍是原始值
DateTimeImmutable::sub() 传错 DateInterval 格式直接抛异常
PHP 8.3 起，sub() 对非法 DateInterval 字符串不再返回 false，而是抛出 DateInvalidOperationException。常见错误包括：
- 用空格代替
T：写成'P1D 1H'而非'P1DT1H' - 漏写前缀：写成
'1D'而非'P1D'（P表示 period） - 使用不支持的相对单位：如
'P1WEEK'或'next monday'—— 这些只适用于modify()，不被DateInterval接受
建议统一用 DateInterval::__construct() 构造，避免字符串解析风险：
$interval = new DateInterval('P1D');
$newDate = $date->sub($interval); // ✅ 安全
时区切换 setTimeZone() 后 format() 输出变了，但 getTimestamp() 没变
setTimezone() 只改时区元数据，不改变底层绝对时刻（即 Unix 时间戳）。所以：
-
$date->getTimestamp()在setTimezone()前后完全一致 -
$date->format('Y-m-d H:i:s')会按新时区渲染，看起来“时间变了”，其实是同一时刻的不同表达 - 常见误用：先
setTimezone('Asia/Shanghai')，再modify('+1 hour')，以为加的是本地时间——其实加的是该时区下的逻辑小时，可能跨 DST 边界，行为不如用 UTC 统一运算稳定
推荐做法：内部统一用 new DateTimeImmutable('now', new DateTimeZone('UTC')) 开始，所有计算在 UTC 下完成，仅在输出前才切换时区。
modify('+1 month') 在月底行为诡异，别依赖它做精确周期计算
modify() 处理月份增减时采用“滚动到当月最后一天”策略，导致非对称结果：
$date = new DateTimeImmutable('2026-01-31');
echo $date->modify('+1 month')->format('Y-m-d'); // 2026-02-28
echo $date->modify('+2 months')->format('Y-m-d'); // 2026-03-28 —— 注意：不是 31 号
这不是 bug，是设计如此。如果业务需要“每月同日”（如订阅续费），应改用 add(new DateInterval('P1M')) 并配合 setDate() 手动校正，或直接用日期字符串拼接 + createFromFormat() 控制逻辑。
真正容易被忽略的点是：这种非对称性在测试中很难覆盖——你得专门测 1 月 31 日、3 月 31 日、12 月 31 日等边界输入，否则上线后才发现账单日期漂移了两天。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
