ThinkPHP5.1中循环日期查询返回空数组的常见原因不是数据真为空，而是日期条件没生效——如字符串拼接含空格、时区不一致、字段类型不匹配、Carbon未格式化等导致SQL日期比较失效。
ThinkPHP5.1中循环日期查询返回空数组的常见原因
不是数据真为空，而是日期条件没生效——where里用字符串拼接或变量未格式化，导致 SQL 生成了无效的日期比较，数据库查不到任何记录，select()自然返回空数组 []。
- 直接拼接字符串：
where('create_time', '>=', $date . ' 00:00:00')，若$date是'2026-08-06'还行，但若来自表单未 trim 或含空格（如" 2026-08-06 "），MySQL 会静默转成0000-00-00，匹配失败 - 用 PHP
date()但时区未设：date('Y-m-d H:i:s')在 CLI 环境下可能用系统默认时区（如 UTC），而数据库存的是东八区时间，造成「看起来是今天，实际查昨天」 - 字段类型不匹配：数据库
create_time是DATE类型，却传入带时分秒的字符串，MySQL 会截断但不报错，逻辑上可能漏掉当天首尾几条 - 使用 Carbon 但未调用
toDateTimeString()：$start->addDays(-7)返回的是 Carbon 实例，直接丢进where()会被转成字符串，但某些版本 TP5.1 对对象处理不稳定，建议显式调用->format('Y-m-d H:i:s')
如何验证日期条件是否真正生效
别只看 select() 返回值，先确认 SQL 是否按预期生成。在查询前加一行调试：
Db::name('log')->where('create_time', '>=', $start)->fetchSql(true)->select();
它会返回原始 SQL 字符串，复制到 MySQL 客户端执行，看是否有结果。如果 SQL 手动执行有数据，说明是框架层面问题；如果没有，就是日期值本身或字段类型不匹配。
- 检查字段类型：
DESC log确认create_time是DATETIME还是DATE，前者需完整时间，后者只比对年月日 - 统一用
strtotime()校验输入：var_dump(strtotime($date));返回false就说明日期字符串非法（如'2026/08/06'在部分系统不被识别） - 避免依赖隐式转换：TP5.1 不会自动把
'2026-08-06'补全为'2026-08-06 00:00:00'，必须自己补全或改用BETWEEN
安全写法：用 whereTime 替代手拼日期
whereTime 是 ThinkPHP5.1 内置的日期专用方法，自动处理类型适配和边界，比裸 where 更可靠。
立即学习“PHP免费学习笔记（深入）”；
- 查某天全部：
whereTime('create_time', 'today')或whereTime('create_time', '2026-08-06') - 查最近 7 天：
whereTime('create_time', '>=', '-7 days')（注意引号内是字符串，不是变量） - 查某月范围：
whereTime('create_time', 'between', ['2026-08-01', '2026-08-31']) - 它底层会根据字段类型自动选择
DATE()包裹或直接比较，规避字符串解析歧义
循环中日期递增出错导致全空
写 for 或 while 循环逐天查数据时，最容易踩的坑是日期变量被反复覆盖或未 clone，导致所有迭代都查同一个日期。
- 错误写法：
$day = strtotime('2026-08-01'); for ($i=0; $iwhereTime('create_time', $sqlDay)->select(); $day += 86400; }—— 看似没问题，但如果$day在中间被其他逻辑修改过，就不可靠 - 推荐用 Carbon（需安装）：
$start = Carbon::parse('2026-08-01'); for ($i = 0; $i copy()->addDays($i); $list[] = Db::name('log')->whereTime('create_time', $day->toDateString())->select(); } - 更轻量方案：用
date_create()+modify()，每次新建对象，避免引用污染
日期类问题最难 debug 的地方在于：SQL 不报错、PHP 不报错、返回空数组也合法——你得主动去挖 SQL 和字段类型，而不是盯着 if (empty($list)) 想办法兜底。
