PHP用DateTime算跨年天数，别用strtotime
跨年日期差容易出错，根本原因是strtotime在处理“2023-12-31 to 2024-01-02”这类边界时，会因时区、夏令时或默认时间（如午夜）隐式补全而偏差1天。直接用DateTime对象+diff()才是可靠路径。
- 必须显式创建两个
DateTime对象，避免字符串隐式解析：$start = new DateTime('2023-12-31'); $end = new DateTime('2024-01-02'); $days = $start->diff($end)->days; // 正确：3 - 如果输入是年/月/日分离的整数（比如表单提交），先拼成
Y-m-d格式字符串再传入DateTime，别拼strtotime("{$year}-{$month}-{$day}") -
diff()返回的DateInterval对象里，days是总天数，d只是“日”部分（例如32天会返回d=2），跨年场景下只认days
注意DateTime默认时区影响结果
没设时区时，DateTime按date_default_timezone_get()走，本地服务器时区若为Asia/Shanghai没问题，但部署到UTC服务器上，new DateTime('2023-12-31')实际是2023-12-31T00:00:00+00:00，和你预期的东八区午夜不是同一时刻——跨年计算可能差1天。
- 统一强制设时区：
$start = new DateTime('2023-12-31', new DateTimeZone('Asia/Shanghai')); $end = new DateTime('2024-01-02', new DateTimeZone('Asia/Shanghai')); - 不要依赖
date_default_timezone_set()全局设置，它可能被其他代码覆盖；每个DateTime构造时显式传DateTimeZone更稳 - 如果业务逻辑本身与时区无关（比如纯日历天数），也建议固定用
UTC，避免本地环境干扰
需要包含起止日？别手算±1
用户常说的“从A日到B日共几天”，常指含头含尾的日历天数（如1号到3号是3天）。但$a->diff($b)->days算的是严格间隔（3号减1号=2天）。这个1天之差是高频翻车点。
- 含头含尾就加1：
$inclusiveDays = $start->diff($end)->days + 1 - 但注意：如果
$start > $end（比如用户输反了），diff()仍返回正数，得先判断顺序：if ($start > $end) { [$start, $end] = [$end, $start]; } $inclusiveDays = $start->diff($end)->days + 1; - 别用
strtotime($end) - strtotime($start)再除86400——浮点误差+闰秒+时区会让结果不可靠
性能敏感场景：避免重复创建DateTime对象
批量计算成百上千个跨年区间时，反复new DateTime($str)有开销，尤其字符串解析阶段。
立即学习“PHP免费学习笔记（深入）”；
- 如果日期格式固定（如全是
Y-m-d），可用DateTimeImmutable::createFromFormat()跳过自动推断：$start = DateTimeImmutable::createFromFormat('Y-m-d', '2023-12-31'); $end = DateTimeImmutable::createFromFormat('Y-m-d', '2024-01-02'); -
DateTimeImmutable比DateTime稍快，且避免意外修改原对象；但两者diff()行为一致 - 极端情况（如日志分析），可退到
sscanf()手动拆年月日再算儒略日序数，但99%场景没必要
跨年计算真正麻烦的从来不是算法，而是时区隐含假设、起止日语义模糊、以及不同函数对“同一天”的定义差异——盯住DateTime构造时的时区和diff()->days的语义，比调任何封装函数都管用。
