whereBetween仅做闭区间比较，不处理时间精度与时区；常见错误包括日期无时分秒、Carbon未调用startOfDay/endOfDay、字符串格式错误致静默失败；正确做法是统一时区并显式处理时间边界。
whereBetween 用法和常见错误
直接用 whereBetween 是最常用也最容易翻车的方式。它只做简单闭区间比较，不自动处理时间精度，也不感知时区。
- 数据库字段是
datetime类型，但传入的值只有日期（如'2024-05-01'），MySQL 会补成'2024-05-01 00:00:00'，查不到当天下午的数据 - PHP 的
Carbon实例如果没显式调用startOfDay()或endOfDay()，默认带当前秒级时间，范围可能漏掉边界 - MySQL 严格模式下，传字符串日期但格式不对（比如带中文分隔符），会静默转成
0000-00-00，查询结果为空且无报错
正确写法示例：
$start = Carbon::parse($request->input('start'))->startOfDay();
$end = Carbon::parse($request->input('end'))->endOfDay();
<p>Model::whereBetween('created_at', [$start, $end])->get();
Laravel 10+ 中 whereDate 和 whereTime 的分工
当只需要按「日期部分」筛选（比如统计某天订单数），别硬套 whereBetween。Laravel 提供了更精准的 whereDate 和 whereTime，它们生成的 SQL 更干净，也避免了时区换算干扰。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
-
whereDate('created_at', '2024-05-01')→ 对应 SQLDATE(created_at) = '2024-05-01'，适合索引优化（但注意：函数索引需 MySQL 5.7+） -
whereTime('created_at', '>=', '09:00:00')单独筛时间段，和日期解耦，适合排班、营业时段类逻辑 - 二者不能链式组合出完整 datetime 范围（比如
whereDate(...)->whereTime(...)不等价于whereBetween），因为底层是两个独立 WHERE 条件
时区不一致导致查不到数据
开发环境 PHP 时区设为 Asia/Shanghai，但 MySQL 服务器时区是 UTC，whereBetween 传进去的 Carbon 时间会被自动转换，而数据库字段存的可能是 UTC 时间，结果两边对不上。
- 先确认 MySQL 当前时区：
SELECT @@time_zone;，再看表字段实际存的是什么（用SELECT created_at FROM xxx LIMIT 1直接看原始值） - 统一策略：要么全用 UTC 存储（推荐），PHP 端用
Carbon::createFromFormat(..., 'UTC')构造；要么 Laravel 配置'timezone' => 'Asia/Shanghai'并确保 MySQL 也设为同一时区 - 临时调试技巧：在查询前加
dd($start->toDateTimeString(), $end->toDateTimeString());，对比输出和数据库里存的值是否在同一时区
性能差？可能是没走索引
用 whereBetween 却发现慢，大概率是字段没走索引，或者用了函数导致索引失效。
- 检查执行计划：
EXPLAIN SELECT * FROM orders WHERE created_at BETWEEN ? AND ?，看key列是否为NULL - 如果字段类型是
timestamp，且 MySQL 版本 - 避免在字段上套函数：
whereRaw("DATE(created_at) = ?")必然不走索引；换成whereDate()生成的 SQL 在新版本 Laravel 中已优化为可索引形式
边界情况多，比如跨年、夏令时切换日、数据库字段允许 NULL——这些不会报错，但会让结果少几条，得盯着原始数据比对。
