根本原因是时区不一致导致日期边界错位；需统一数据库会话时区、改用显式时间范围查询、聚合时用CONVERT_TZ转换、展示层用Carbon宏处理本地化，再逐层验证时间值。
统计每日数据时出现结果偏差，根本原因不是“时间算错了”，而是“一天的起止边界在不同时区下定义不同”。Laravel 11 默认用 UTC 存储时间，但 whereDate()、groupBy('date') 这类操作依赖 PHP 和数据库对“今天”的理解——若两者时区不一致，就可能把北京时间 10 月 20 日 00:00 的记录，错判为 UTC 时间 10 月 19 日 16:00，从而归入 19 号的统计组。
统一数据库连接层时区（关键第一步）
MySQL 的 CURDATE()、DATE() 函数受 session 时区影响。即使 Laravel 配置了 'timezone' => 'Asia/Shanghai'，数据库连接仍可能按 UTC 解析日期函数。
- 在
config/database.php的 MySQL 连接配置中，加入初始化命令：'options' => [PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = '+08:00'"] - 确认该配置生效：在 Tinker 中执行
DB::select("SELECT @@session.time_zone")[0]->{'@@session.time_zone'}，应返回+08:00或SYSTEM（且系统本身是东八区） - 注意：此设置仅对 MySQL 有效；PostgreSQL 用户需改用
SET TIME ZONE 'Asia/Shanghai'并确保连接复用机制兼容
避免 whereDate() 隐式转换，改用时间范围查询
whereDate('created_at', today()) 看似简洁，实则危险：它会把 today() 按应用时区生成一个日期字符串（如 "2026-10-20"），再交由数据库按 session 时区解析。一旦数据库 session 时区不是 +08:00，就会错位。
- 显式构造当日起止时间（UTC 存储前提下）：
$start = now('Asia/Shanghai')->startOfDay()->utc();<br>$end = now('Asia/Shanghai')->endOfDay()->utc();<br>Model::whereBetween('created_at', [$start, $end])->get(); - 若需按用户本地时区统计（如多时区后台），把
'Asia/Shanghai'替换为动态获取的用户时区，例如request()->user()?->timezone ?? 'Asia/Shanghai' - 聚合统计同理：
Model::selectRaw('DATE(CONVERT_TZ(created_at, "+00:00", "+08:00")) as date')->selectRaw('COUNT(*) as count')->groupBy('date')->get();
模型访问器 + Carbon 宏统一输出本地日期
日常展示用的“今日”、“昨日”等语义化标签，不应在 SQL 层硬编码时区，而应在 PHP 层做转换，保证逻辑清晰、可测试。
- 在
AppServiceProvider@boot中注册 Carbon 宏：Carbon::macro('toLocalDate', function ($timezone = null) {<br> return $this->tz($timezone ?? config('app.timezone'))->format('Y-m-d');<br>}); - 在模型中定义访问器：
public function getLocalDateAttribute()<br>{<br> return $this->created_at->toLocalDate();<br>} - 统计时直接分组：
Model::selectRaw('local_date as date')->selectRaw('COUNT(*) as count')->groupBy('date')->get();
（前提是已通过访问器或查询构造出local_date字段）
验证与调试建议
别只看最终数字，要逐层确认时间值是否符合预期：
- 查数据库原始值：
SELECT created_at, UNIX_TIMESTAMP(created_at) FROM models LIMIT 5;确认存的是纯时间戳，无隐含时区 - 查当前 session 时区：
SELECT NOW(), CURDATE(), @@session.time_zone; - Tinker 中对比：
now('Asia/Shanghai')->startOfDay()vsnow('UTC')->startOfDay()，确认差值是否为 8 小时 - 开启查询日志，观察生成的 SQL 是否含
CONVERT_TZ或明确的时间范围，而非模糊的DATE(created_at) = '2026-10-20'
