carbon 在 laravel 中默认可用，是 php datetime 的增强封装；创建推荐静态方法如 now()、parse()、createfromtimestamp()；格式化用 format() 避免隐式转换；比较自动时区归一；adddays() 等默认可变，需 copy() 保留原值；eloquent 自动转 carbon，但数据库时区需统一为 utc。
Carbon 在 Laravel 中默认可用，不需要额外安装或配置；它本质是 PHP DateTime 类的增强封装，所有操作都基于 Carbon 实例，而非原始字符串或时间戳。
创建和解析时间：用对构造方法和静态工厂
别直接 new DateTime()，Laravel 已自动替换成 Carbon；但手动创建时优先用静态方法，语义清晰且容错更强：
-
Carbon::now()获取当前时间（带时区，受app.timezone配置影响） -
Carbon::parse('2024-03-15 14:30')解析任意格式字符串，支持中文、相对表达式（如'next Monday'） -
Carbon::createFromTimestamp(1710512000)从 Unix 时间戳构建，注意是秒级（不是毫秒） -
Carbon::create(2024, 3, 15, 14, 30, 0, 'Asia/Shanghai')精确控制年月日时分秒及时区
⚠️ 常见坑：Carbon::parse(null) 返回当前时间，不是 null；Carbon::parse('') 抛出 InvalidArgumentException；务必校验输入非空。
格式化与比较：避免 toString() 隐式调用和时区陷阱
输出格式推荐显式调用 format() 或 toDateTimeString()，不要依赖隐式 __toString() —— 尤其在 JSON 序列化或 Blade 中易出错：
-
$date->format('Y-m-d H:i:s')最可控，兼容所有 PHP 版本 -
$date->toDateString()/toTimeString()/toISOString()按需选用 - 比较两个
Carbon实例，直接用>、、<code>->eq()、->gt()等方法，它们自动处理时区归一化 - ⚠️ 关键点：两个不同
timezone的Carbon实例比较时，Carbon 内部会转为 UTC 再比，结果正确；但若用strtotime($a) > strtotime($b)，就可能因时区未归一而出错
增减与区间操作：慎用 addDays() 类方法的链式副作用
addDays()、subHours() 等方法默认修改原实例（mutable），不是返回新实例：
- 需要保留原值？用
copy()：$new = $date->copy()->addDays(7) - 想批量加减？用
add()+DateInterval：$date->add(new \DateInterval('P1M2D'))（1月2天） - 判断是否在某个范围内：
$date->between($start, $end, $equal = true)，第三个参数决定端点是否包含 - 获取区间内所有日期：
CarbonPeriod::create($start, $end)->toArray()，注意返回的是Carbon实例数组，不是字符串
⚠️ 坑：在循环中反复调用 $date->addDays(1) 而没 copy()，会导致后续迭代基于已被修改的时间，逻辑错乱。
数据库交互与序列化：Eloquent 自动处理 ≠ 你可忽略时区
Laravel 的 Eloquent 默认将 datetime 字段转为 Carbon 实例，但底层仍依赖 MySQL/PostgreSQL 的时区设置和 PHP 的 date.timezone：
- 数据库写入前，Carbon 会按模型的
$casts或$dates（旧版）自动转换，但前提是字段类型是datetime或timestamp - API 返回 JSON 时，
Carbon默认转成 ISO8601 字符串（如"2024-03-15T14:30:00+08:00"），前端可直接解析；若需统一 UTC 格式，可在模型中重写serializeDate()方法 - 从请求中接收时间字符串（如 API POST），建议用
Carbon::createFromRequest($request, 'published_at')或手动Carbon::parse($request->input('date'))，并 catchException处理非法输入
真正容易被忽略的是：MySQL 的 TIMESTAMP 类型会自动转为服务器时区存储，而 DATETIME 不会；如果应用跨多时区部署，务必统一数据库时区为 UTC，并在应用层用 Carbon 显式处理显示时区。
