carbon::parse() 解析失败常因输入格式不规范而静默回退到当前时间，应优先用 createfromformat() 并校验 isvalid()；now() 与 today() 行为不同，范围查询需用 wherebetween；withtimezone() 返回新实例，settimezone() 修改原实例；diffindays() 结果符号取决于参数顺序。
Carbon::parse() 解析字符串失败的常见原因
直接传入不规范的时间字符串，比如 "2024-02-30" 或 "2024/13/01"，Carbon::parse() 不会报错，而是静默回退到当前时间——这很容易掩盖逻辑 bug。
- 优先用
Carbon::createFromFormat()显式指定格式，比如Carbon::createFromFormat('Y-m-d H:i:s', $input)，解析失败会抛InvalidArgumentException - 若必须用
parse()，建议配合->isValid()校验：Carbon::parse($input)->isValid() - 注意时区：
parse()默认使用应用配置的时区（app.timezone），不是服务器本地时区，也不是 UTC
Carbon::now() 和 Carbon::today() 的行为差异
Carbon::now() 返回带具体时分秒的当前时间，Carbon::today() 只保留年月日，时分秒全为 0 —— 看似简单，但用错会导致数据库查询漏数据或缓存失效。
- 做「今日订单统计」这类范围查询时，别写
whereDate('created_at', Carbon::today())，它等价于WHERE DATE(created_at) = '2024-05-20'，无法走created_at字段索引 - 更高效写法是：
whereBetween('created_at', [Carbon::today(), Carbon::tomorrow()->subSecond()]) -
Carbon::today()不接受参数；要指定时区得用Carbon::today('Asia/Shanghai')
withTimezone() 和 setTimezone() 的区别在哪
这两个方法都改时区，但一个返回新实例，一个修改原实例——混用容易引发意外的时间偏移。
-
$dt->withTimezone('UTC')：返回新Carbon实例，原$dt不变 -
$dt->setTimezone('UTC')：直接修改$dt自身，后续所有操作都基于新时区 - 链式调用时尤其注意：
Carbon::now()->setTimezone('UTC')->addDay()是先改时区再加一天；而Carbon::now()->withTimezone('UTC')->addDay()是先加一天再转成 UTC（结果不同） - 数据库字段是
datetime类型且存的是本地时间时，setTimezone()更安全；若存的是 UTC，则统一用withTimezone()转换显示
diffInDays() 为什么有时返回负数
这个方法计算两个时间点的天数差，但顺序错了就会出负值——不是 bug，是设计如此。很多人在条件判断里直接用 diffInDays() > 0，却没意识到谁减谁。
-
$a->diffInDays($b)等价于$b->diffInDays($a)的相反数，即$b - $a的天数 - 想确保非负，用
abs($a->diffInDays($b))；但更推荐语义明确的$a->lessThan($b)或$a->greaterThan($b)做判断 - 跨月计算要注意：2 月 28 日到 3 月 1 日，
diffInDays()返回 2（不是 1），因为它是按 24 小时整数倍算的，不是日历日
事情说清了就结束。Carbon 表面简单，但时区、解析容错、不可变性这些点，一不留神就在生产环境里埋下时间错位的坑。
