DateTime::format() 易出错，关键在时区设置、解析容错和对象有效性检查：需显式设时区、用 createFromFormat 替代构造函数、创建后判空。
DateTime::format() 是最常用也最容易出错的字符串转换方式
直接用 DateTime::format() 转字符串，不是所有格式都安全。比如 'Y-m-d H:i:s' 没问题，但用 'r'（RFC 2822）时，时区没设好会输出错误的偏移量；用 'U' 得到的是 Unix 时间戳整数，不是字符串日期——这点常被忽略。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 始终显式设置时区：
$date->setTimezone(new DateTimeZone('Asia/Shanghai'))，否则默认用date.timezone配置，线上和本地不一致极易翻车 - 避免用
date()函数混搭DateTime对象，比如date('Y-m', $date->getTimestamp())—— 多此一举且丢掉了时区上下文 - 需要 ISO 8601 格式时，优先用
$date->format('c')，它自动包含时区信息；别手写$date->format('Y-m-d\TH:i:sP')，P在 PHP 5.1.3+ 才支持，老环境会空字符串
从字符串创建 DateTime 对象时，parse 的模糊性必须警惕
new DateTime('2023-02-30') 不报错，而是自动归正为 2023-03-02；new DateTime('next Monday') 依赖当前系统时间，测试难复现；更隐蔽的是 new DateTime('01/02/2023') —— 斜杠分隔符下，PHP 默认按 m/d/Y 解析（美式），不是你预期的 d/m/Y。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 固定格式字符串，用
DateTime::createFromFormat()替代构造函数，例如：DateTime::createFromFormat('d/m/Y', '31/12/2023') - 解析用户输入前，先用
DateTime::getLastErrors()检查是否解析成功：$date = DateTime::createFromFormat('Y-m-d', $_POST['date']);
if (!$date || !empty(DateTime::getLastErrors()['warning_count'])) {
throw new InvalidArgumentException('日期格式错误');
} - 避免用
strtotime()转换后再传给DateTime，比如new DateTime('@' . strtotime($str))—— 会丢失毫秒、时区信息，且strtotime本身已废弃部分语法（如'last day of next month'在 PHP 8.2+ 行为变更）
时区处理不当是 DateTime 字符串转换中最隐蔽的坑
同一个 DateTime 对象，format('Y-m-d H:i:s') 和 format('c') 输出差异可能只在时区标识上，但若没调用 setTimezone()，format('c') 仍用默认时区，而数据库存的可能是 UTC，前端显示就差 8 小时。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 入库前统一转为 UTC：
$date->setTimezone(new DateTimeZone('UTC'))，再format('Y-m-d H:i:s') - 展示给用户前才转本地时区，且用明确的时区名（如
'Asia/Shanghai'），别用'+08:00'这种固定偏移——夏令时地区会失效 - 配置
date_default_timezone_set('UTC')在入口文件开头，比依赖php.ini更可控；但注意：DateTime构造时不传时区参数，才会 fallback 到这个默认值
format() 返回空字符串？检查对象是否创建失败
DateTime 构造失败时不会抛异常，而是返回 false，后续调用 format() 会触发 Call to a member function format() on bool 错误。但有些场景下（比如 DateTime::createFromFormat() 解析失败），返回的是 false，却没立刻报错，等到 format() 才崩，堆栈难定位。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有手动创建
DateTime的地方，加判空：$date = DateTime::createFromFormat('Y-m-d', $input);
if (!$date) {
// 处理错误
} - 不要依赖异常捕获兜底，因为
DateTime构造失败是静默的；try/catch对它无效，只有new DateTime('invalid')在极少数极端格式下才抛Exception，不可靠 - 单元测试里故意传非法字符串（如
'2023-13-01'、'abc'），验证你的校验逻辑是否真起作用
format() 看似简单，实际输出的字符串可能在任意环节悄悄偏离预期。 
