必须用 DateTime 对象而非字符串比较跨年日期，因字符串比较在 m/d/Y 格式下会乱序；应使用 DateTime::createFromFormat 解析并验证，再通过时间戳或对象比较进行循环和查询。
ThinkPHP 5.1 里用字符串比较两个跨年日期（比如 "12/25/2024" 和 "1/5/2025"）做循环控制，必然乱序——根本不是 TP 的问题，而是 PHP 字符串比较在日期场景下完全不可靠。
字符串比较 "12/25/2024" 返回 false
PHP 按字典序逐字符比对："12/..." 开头是 '1'，"1/5/2025" 开头也是 '1'，接着比第二位：'2' vs '/'。ASCII 中 '/'（47）小于 '2'（50），所以 "1/5/2025" 被判定“更小”，导致 "12/25/2024" > "1/5/2025" 成立。循环直接跳过或提前终止。
- 所有
m/d/Y格式字符串（如"1/1/2025"、"12/31/2024"）跨年时都可能触发该问题 -
strtotime()解析后若未显式验证，可能返回false，后续date()输出空字符串，加剧逻辑错乱 - TP5.1 的
whereTime()等查询方法内部也依赖时间戳或 DateTime，不解决源头字符串比较，查询条件也会出错
必须用 DateTime 对象而非字符串做循环判断
TP5.1 原生不提供日期范围遍历工具，但可安全复用 PHP 内置的 DateTime + DateInterval。关键点是：对象间比较自动按真实时间大小进行，且支持毫秒级精度。
- 用
DateTime::createFromFormat('m/d/Y', $str)替代strtotime($str)，避免美式格式歧义（"01/02/2025"是 1月2日还是2月1日？） - 务必检查返回值：
if (!$start || !$end) { throw new InvalidArgumentException('日期解析失败'); }，否则空对象参与比较会静默转为1970-01-01 - 循环体中用
$current->add(new DateInterval('P1D'))，不要用strtotime('+1 day')——后者在夏令时切换日可能跳两天或卡住
TP5.1 分页 + 跨年日期范围查询容易漏数据
如果在 whereTime('create_time', 'between', [$startStr, $endStr]) 中传入字符串，且 $startStr = "12/15/2024"、$endStr = "1/10/2025"，框架底层仍会调用 strtotime()。一旦解析失败或顺序颠倒，between 条件实际变成 create_time BETWEEN 0 AND 0 或反向区间，查不到任何记录。
立即学习“PHP免费学习笔记（深入）”；
- 正确做法：先转成时间戳再传入，
whereTime('create_time', 'between', [strtotime($startStr), strtotime($endStr)])，但前提是确保strtotime解析成功 - 更稳方案：手动构造时间戳范围，
where('create_time', '>=', $startObj->getTimestamp())->where('create_time', 'getTimestamp()) - 注意数据库字段类型：若
create_time是datetime，直接传时间戳会被隐式转换；若是int存储，则必须用时间戳
真正要警惕的不是“跨年”，而是任何把日期当字符串操作的惯性思维——哪怕只差一天，"1/1/2025" 和 "12/31/2024" 在字符串比较里也可能颠倒。DateTime 对象才是唯一可信的锚点。
