DateTime 修改原对象，DateTimeImmutable 总是返回新实例；前者调用 add() 等方法会就地修改，后者返回新对象且自身不变，影响逻辑安全与 bug 风险。
DateTime 修改原对象，DateTimeImmutable 总是返回新实例
这是最核心的区别，直接影响代码逻辑和 bug 风险。用 DateTime 时，调用 modify()、add()、sub()、setDate() 等方法会直接改掉当前对象的内部时间值；而 DateTimeImmutable 的同名方法从不修改自身，一定返回一个全新的对象。
常见错误现象：
- 循环中反复
$dt->modify('+1 day')，结果每次都是在上一次修改后的值上再加，不是从原始时间开始算 - 把同一个
DateTime实例传给多个函数，其中一个调用了add()，其他地方拿到的已是被改过的值 - 想链式调用但误以为
modify()返回的是新对象，实际它返回的是$this（还是那个被改过的对象）
实操建议：
- 默认优先用
DateTimeImmutable，尤其在函数参数、数组元素、类属性中存储时间时 - 只有明确需要「就地更新」且后续不再依赖原始值时，才考虑
DateTime - 若必须用
DateTime又怕被意外修改，得手动clone $dt，但不如直接用DateTimeImmutable干净
两者方法签名几乎完全一致，但行为语义不同
DateTime 和 DateTimeImmutable 都实现 DateTimeInterface，所以所有读取类方法（如 format()、getTimestamp()、diff()）行为完全一样；所有修改类方法（如 add()、setISODate()、setTimezone()）也都有同名同参版本——只是前者改自己，后者返新实例。
立即学习“PHP免费学习笔记（深入）”；
注意几个典型场景：
-
$dt->add(new DateInterval('P1D'))：对DateTime是就地加一天；对DateTimeImmutable是返回加了一天的新对象，$dt本身不变 -
DateTime::createFromFormat()和DateTimeImmutable::createFromFormat()都存在，返回对应类型的实例，别混用 - 静态工厂方法如
createFromImmutable()和createFromMutable()可双向转换，但会丢失不可变性或引入可变风险
微秒精度和时区处理无差异，但 clone 行为不同
两者都支持微秒（format('Y-m-d H:i:s.u')），都完整支持 DateTimeZone，时区转换逻辑完全一致。真正影响行为的是 clone 操作：
-
clone一个DateTime对象，得到的是独立副本，后续修改互不影响 -
clone一个DateTimeImmutable对象，其实没意义——它本来就不变，克隆前后是等价的两个不可变值 - 更关键的是：
DateTimeImmutable的add()等操作天然就是“安全 clone + 修改”的组合，省去显式clone步骤
性能上，DateTimeImmutable 每次操作都新建对象，内存开销略高；但在绝大多数 Web 场景下这点开销可忽略，换来的是逻辑清晰和可预测性。
别在函数返回值里偷偷改 DateTime 实例
这是最容易被忽略的坑：如果一个函数接收 DateTime 参数并调用了 modify()，调用方很可能不知道原始对象已被污染。
示例对比：
$now = new DateTime();
function addWeek(DateTime $dt) {
return $dt->modify('+7 days'); // 返回 $dt 自身，但已改
}
addWeek($now);
echo $now->format('Y-m-d'); // 输出的已是 7 天后，不是原始时间
换成 DateTimeImmutable 就安全得多：
$now = new DateTimeImmutable();
function addWeek(DateTimeImmutable $dt) {
return $dt->add(new DateInterval('P7D')); // 返回新实例，$now 不变
}
$nextWeek = addWeek($now);
echo $now->format('Y-m-d'); // 始终是原始时间
复杂点在于：一旦项目里混用两者，类型提示（type hint）和 IDE 支持容易出错；更麻烦的是，有些老库或框架返回的是 DateTime，你得立刻转成 DateTimeImmutable 再操作，否则边界处就埋了雷。
