Carbon 是 Laravel 时间处理默认底层，created_at 等字段自动转为 Carbon 实例；解析失败主因是传入 Collection 或空值，应改用 value()、first()->attr 或 pluck()；时间戳创建须指定时区，优先用 createFromTimestamp() 或 createFromTimestampUTC()；diffInDays() 与 diffInRealDays() 区分逻辑天数与日历天数；数据库存 UTC、显示转时区，需确保 MySQL 与 Laravel 时区配置一致。
Carbon 在 Laravel 中不是“可选工具”，而是时间处理的默认底层——所有 created_at、updated_at 字段自动转为 Carbon 实例，直接调用方法即可，无需手动 new 或 cast。
Carbon::parse() 报 “Could not parse” 是因为传了集合或空值
常见错误是把 Eloquent 的 get('created_at') 结果直接喂给 Carbon::parse()。它返回的是 Collection，不是字符串，例如：[{"created_at":"2021-11-20T15:14:28.000000Z"}]，parse() 无法解析这种结构。
- 要取单个值：改用
value('created_at')或first()->created_at - 要批量处理：用
pluck('created_at')得到字符串数组，再逐个Carbon::parse() - 永远先校验输入：
if (empty($input)) { throw new InvalidArgumentException('date string required'); } - 对格式确定的字符串（如表单提交的
"2024-03-15 14:30:00"），优先用Carbon::createFromFormat('Y-m-d H:i:s', $input)，比parse()更可靠
从时间戳创建 Carbon 实例时，new Carbon($ts) 很可能出错
传入整数时间戳时，new Carbon($timestamp) 默认按 PHP 本地时区解释该数值。如果服务器在 UTC，而你的时间戳本意是北京时间（如 1698768000 对应 2023-10-31 00:00:00 CST），结果会变成 UTC 时间点，即 2023-10-31 08:00:00 —— 偏移 8 小时。
- 安全做法：明确指定源时区，用
Carbon::createFromTimestamp($ts, 'Asia/Shanghai') - 若时间戳来自 MySQL 的
UNIX_TIMESTAMP()，它本质是 UTC 秒数，统一用Carbon::createFromTimestampUTC($ts) - 避免
Carbon::parse('@'.$ts)，它对时区不敏感，仍可能触发隐式本地时区转换 -
Carbon::now()->timestamp返回的是当前应用时区下的秒数，不是绝对 UTC 时间戳，别误当 UTC 存储
diffInDays() 和 diffInRealDays() 的区别直接影响业务逻辑
会员有效期、逾期判断、合同到期提醒等场景，必须区分“24 小时制天数”和“日历天数”。比如从 1 月 31 日到 3 月 1 日，diffInDays() 可能返回 30，但真实日历跨度只有 29 天（因 2 月天数少）。
立即学习“PHP免费学习笔记（深入）”；
-
$a->diffInDays($b)= 总小时数 ÷ 24 向下取整，忽略日期边界，适合粗略统计或性能敏感路径 -
$a->diffInRealDays($b)= 调用 PHP 原生DateInterval的日历算法，考虑大小月、闰年、夏令时跳变，业务关键计算必须用它 - 注意：两者都返回整数，若需带小数的精确小时差，用
diffInHours()或floatDiffInDays() - Eloquent 查询中不能直接用这些方法，得先取出数据再计算；想在数据库层做天数过滤，要用
whereRaw("DATEDIFF(NOW(), created_at) >= 30")（MySQL）
数据库存 UTC、显示转时区，但模型配置和 MySQL 设置必须一致
Laravel 默认将 created_at 等字段以 UTC 写入数据库，前提是 MySQL 的 time_zone 配置没被覆盖成 '+00:00' 或其他值。一旦不一致，就会出现写入/读取双偏移。
- 检查
config/database.php中 MySQL 配置项，删掉'timezone' => '+00:00'这类显式设置，让 MySQL 使用系统默认 - 确认
config/app.php的'timezone'是你要的显示时区（如'Asia/Shanghai'），Laravel 启动时会自动date_default_timezone_set() - 模型中不要手动调
setTimezone('UTC')，也别在$casts里写'created_at' => 'datetime:Y-m-d'这种带格式的 cast，它会触发额外时区转换 - 显示时用
$model->created_at->tz('Asia/Shanghai')->format('Y-m-d H:i')，而不是依赖模型自动转换
真正容易被忽略的是：Carbon 实例本身不携带“存储意图”，它只是个时间对象；时区转换、精度选择、输入校验、数据库配置——这四件事哪怕漏掉一个，都会在某个凌晨三点的生产报警里突然爆发。
