DateTimeImmutable 创建后不可修改，所有操作返回新实例，与 DateTime 的根本区别在于不可变性；需显式赋值，构造时注意时区处理，互转需谨慎，排序和函数传参更安全。
DateTimeImmutable 创建后不能修改，所有操作都返回新对象
这是它和 DateTime 最根本的区别：一旦创建，任何方法（比如 modify()、add()、sub()）都不会改变原对象，而是返回一个全新的 DateTimeImmutable 实例。如果你习惯写 $dt->modify('+1 day') 后直接用 $dt，那在 DateTimeImmutable 下会出错——原变量还是旧时间。
正确做法是显式赋值：
$dt = new DateTimeImmutable('2024-01-01');
$dt = $dt->modify('+1 day'); // 必须重新赋值
$dt = $dt->add(new DateInterval('P1M'));
常见错误现象：DateTimeImmutable::modify(): Cannot modify immutable object —— 实际上这个错误并不存在，PHP 不会报这个错，但你的逻辑会静默失效：时间没变，你还以为变了。
构造时传入时区或格式字符串要小心默认行为
DateTimeImmutable 构造函数不传时区时，会使用 date_default_timezone_get() 的结果；但如果传了含时区的字符串（如 '2024-01-01T12:00:00+08:00'），它会以该时区为准，不会自动转成本地时区。
立即学习“PHP免费学习笔记（深入）”；
- 想明确用 UTC？写
new DateTimeImmutable('2024-01-01', new DateTimeZone('UTC')) - 想解析用户输入的 '2024-01-01' 并按系统时区解释？直接传字符串即可，但确保
date_default_timezone_set()已设好 - 想解析 '2024-01-01 12:00' 却没指定格式？别依赖
__construct()自动识别，用DateTimeImmutable::createFromFormat()更可靠
容易踩的坑：用 new DateTimeImmutable('now') 在 CLI 和 Web 环境下可能因默认时区不同而得到不同结果，建议显式指定时区。
与 DateTime 互转要注意“不可变性”是否被意外打破
你可以用 DateTimeImmutable::createFromMutable() 把一个 DateTime 转成不可变对象，也可以用 DateTimeImmutable::createFromFormat() 直接创建不可变实例。但反向转换（DateTimeImmutable → DateTime）没有内置方法，得手动 new：
$immutable = new DateTimeImmutable('2024-01-01');
$mutable = new DateTime($immutable->format('c'), $immutable->getTimezone());
注意：$immutable->format('c') 会丢失微秒精度（如果有的话），且 DateTime 构造时若时区对象是动态生成的（比如从 $immutable->getTimezone() 拿到的），要确保它不是 UTC 以外的时区别名歧义问题（如 'Asia/Shanghai' 安全，'CST' 不安全）。
性能影响：频繁互转本身开销不大，但一旦转成 DateTime，后续操作就可能无意中修改原时间逻辑，破坏不可变语义。
在数组排序、函数式处理中它天然更安全
比如你有一组时间要排序，用 DateTimeImmutable 可避免副作用：
$times = [
new DateTimeImmutable('2024-01-03'),
new DateTimeImmutable('2024-01-01'),
new DateTimeImmutable('2024-01-02'),
];
usort($times, fn($a, $b) => $a <=> $b); // 安全，无修改风险
而用 DateTime 时，如果某个排序回调里不小心调用了 $a->modify()，整个数组就乱了。
另一个典型场景是作为函数参数传递：你传一个 DateTimeImmutable 进去，完全不用担心它在函数内部被改掉——这点在长调用链、多层封装或第三方库集成时特别关键。
复杂点在于：PHP 类型声明无法强制“不可变”，IDE 和静态分析工具对 DateTimeImmutable 的方法返回类型推断有时不准，所以靠命名（如 $createdAt）、文档和团队约定来守住这层语义，比靠语言机制更实际。
