Carbon 实例由 Eloquent 自动创建，无需手动 new；仅解析表单字符串时需 Carbon::parse()；慎用 format() 而优先 toDateString()；withTimezone() 返回新实例，setTimezone() 修改原实例；addDays() 默认可变，需 copy() 保留原值。
Carbon 在 Laravel 中不是“要学怎么装”的工具，而是模型一查出来就 ready-to-use 的日期对象——created_at、updated_at、$casts = ['published_at' => 'datetime'] 声明的字段，全都是 Carbon 实例，直接调方法就行。
Carbon 实例从哪来？别手动 new
绝大多数场景下，你根本不需要写 new Carbon() 或 Carbon::parse()：
- Eloquent 模型自动把
created_at、updated_at和$casts里声明为date/datetime的字段转成 Carbon 对象 - 直接写
$post->created_at->format('Y-m-d')合法且高效 - 只有解析表单提交的原始字符串（比如
"2026-05-02"）时，才需要Carbon::parse($input)或更安全的Carbon::createFromFormat('Y-m-d', $input) - 如果字段没被识别（如数据库类型是
TEXT，或没在$casts里声明），$model->foo->format()会报错：Call to a member function format() on string
format() vs toDateString()：性能和语义差别很大
format() 灵活但有开销；toDateString() 等快捷方法是硬编码输出，快且不易拼错：
-
$date->format('Y-m-d')走完整 PHP 格式解析流程，高频循环中（如列表页渲染 100 条记录）明显慢于$date->toDateString() -
toDateTimeString()返回"Y-m-d H:i:s"，toISOString()返回带微秒的 UTC 字符串，toFormattedDateString()返回"May 2, 2026"—— 选哪个取决于前端是否需要时间、是否要本地化 -
format()返回字符串，不再是 Carbon 对象；所有快捷方法也返回字符串，不改变原实例 - 大小写敏感：
'y'是两位年（"26"），'Y'是四位年（"2026"），写错不会报错，但结果不对
时区切换：withTimezone() 和 setTimezone() 行为完全不同
链式调用时一个字母之差，结果可能完全相反：
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
-
$date->setTimezone('UTC')直接修改原实例，后续所有操作都基于新时区 —— 危险，尤其在复用变量时 -
$date->withTimezone('UTC')返回新实例，原$date不变，适合链式：$date->withTimezone('Asia/Shanghai')->addDay() - 数据库存 UTC 是共识，显示时用
withTimezone($userTimezone)；若存的是本地时间（不推荐），才考虑setTimezone()校准 - 比较两个不同 timezone 的 Carbon 实例（如
$a->gt($b)）是安全的，Carbon 内部自动归一到 UTC；但用strtotime($a) > strtotime($b)就会出错
addDays() 类方法默认改原对象，不是返回新实例
这是最常踩的坑：你以为在“算”，其实你在“改”：
-
$date->addDays(7)修改了$date本身，下次再用它就不是原来的时间了 - 需要保留原值？必须先
copy()：$nextWeek = $date->copy()->addDays(7) - 在循环里反复
addDays(1)却没copy()，会导致后续迭代全部基于已被偏移的时间点 - 计算区间用
between($start, $end)，第三个参数控制端点是否包含；要遍历日期范围，用CarbonPeriod::create($start, $end)->toArray()，返回的是 Carbon 实例数组
真正复杂的地方不在语法，而在隐式行为：Carbon 默认 mutable、parse() 对非法输入静默兜底、时区标签和真实值容易混淆、微秒精度在 MySQL DATETIME 字段里被截断却不报错——这些细节不盯住，线上就容易出难以复现的时间逻辑 bug。
