DateTimeImmutable不可变但需显式赋值新对象，跨月计算自动回跳至月末，时区必须显式指定，避免与DateTime混用。
用 DateTimeImmutable 做时间运算，原对象确实不会变——这是它的设计目标。但很多开发者以为“只要用了 Immutable 就万事大吉”，结果在链式调用、时区混用、月份增减等场景里照样踩坑。问题不在于类本身，而在于对“不可变”的理解偏差和边界细节的忽略。
链式调用没保存新对象，等于白算
很多人写成这样：
✘ 错误写法$date = new DateTimeImmutable('2026-10-01');
$date->modify('+3 days'); // 返回新对象，但没赋值给变量
echo $date->format('Y-m-d'); // 输出仍是 2026-10-01
因为 modify()、add()、sub() 都返回新实例，**不赋值就丢失结果**。这不是 Bug，是故意设计——强制你显式接收。
✅ 正确做法：
立即学习“PHP免费学习笔记（深入）”；
- 每次运算后必须重新赋值：
$date = $date->add(new DateInterval('P3D')); - 或用函数式风格一次性链到底：
$new = (new DateTimeImmutable())->add(...)->sub(...)->setTime(...);
跨月计算时，日期“自动回跳”被当成 bug
比如从 2026-01-31 加一个月：
$date = new DateTimeImmutable('2026-01-31');
$new = $date->modify('+1 month');
echo $new->format('Y-m-d'); // 输出 2026-02-28（不是 2026-03-03 或报错）
这是因为 2 月没有 31 日，PHP 自动取当月最后一天。连续加两个月更明显：
- 2026-01-31 → +1M → 2026-02-28
- 2026-02-28 → +1M → 2026-03-28（不是 2026-03-31）
这不是 DateTimeImmutable 特有，DateTime 也一样，但 Immutable 容易让人误以为“逻辑更安全”，反而疏于验证边界日期。
时区未显式指定，本地时区悄悄介入
如果没传 DateTimeZone，且又没设全局时区：
$date = new DateTimeImmutable('2026-10-03 14:00:00'); // 无时区参数
echo $date->getTimezone()->getName(); // 可能是 system 默认时区（如 Europe/Berlin），也可能警告
尤其在容器或 CLI 环境中，date_default_timezone_get() 可能返回 UTC 或空，导致同一段代码在不同环境解析出不同绝对时刻。
✅ 安全做法：
- 始终显式传入时区：
new DateTimeImmutable('2026-10-03 14:00:00', new DateTimeZone('Asia/Shanghai')) - 存储和内部运算用 UTC，仅展示前转本地时区
混用 DateTime 和 DateTimeImmutable，引用语义混乱
有人把 DateTimeImmutable 转成 DateTime 再操作：
$immutable = new DateTimeImmutable('2026-10-03');
$mutable = DateTime::createFromImmutable($immutable);
$mutable->modify('+1 day'); // ✅ 修改了 $mutable
echo $immutable->format('Y-m-d'); // ✅ 还是 2026-10-03 —— 看似安全
但问题在后续：如果把 $mutable 又转回 immutable，或与其他模块共享，就可能因类型混用导致逻辑断裂。更隐蔽的是，某些旧库或框架接口只接受 DateTime，强制转换后容易忽略“可变性”已回归。
✅ 推荐策略：
- 项目统一使用
DateTimeImmutable，避免双向转换 - 对接老接口时，用
DateTimeImmutable::createFromMutable()而非反向，确保源头可控
