Carbon非Laravel专属但被默认集成，应优先用parse()而非new构造、用$casts自动转换时间字段、注意时区配置与数据库类型匹配。
Carbon 不是 Laravel 专属库，但 Laravel 默认集成它；直接用 Carbon 类即可操作日期，无需额外“实现”——你真正需要的是理解它怎么改写原生 DateTime 行为、何时该用 parse() 而非构造函数、以及为什么 ->toDateString() 比 ->format('Y-m-d') 更安全。
Carbon 构造时别乱传字符串：用 parse() 而非 new Carbon() 直接传参
很多人写 new Carbon('2024-03-15') 看似能跑，但遇到 '15/03/2024' 或 'tomorrow' 就崩。PHP 原生 DateTime 解析规则模糊，Carbon 继承了这点，但提供了更可控的入口。
-
Carbon::parse('next Monday')—— 支持自然语言，且自动处理时区（基于date_default_timezone_set()或 Laravel 配置） -
new Carbon('2024-03-15')—— 依赖底层DateTime解析器，'15/03/2024'在某些 PHP 版本下会被当成m/d/Y导致错误 - 明确格式时用
Carbon::createFromFormat('d/m/Y', '15/03/2024')，比parse()更严格，失败时抛InvalidArgumentException
Laravel 中时间字段自动转 Carbon 实例：靠 $casts 和访问器，不是靠手动 new
模型里定义 protected $casts = ['created_at' => 'datetime']; 后，$user->created_at 返回的就是 Carbon 实例，不是字符串。这是 Eloquent 自动做的，不用你在控制器里反复 Carbon::parse($request->date)。
- 数据库字段类型必须是
DATETIME/TIMESTAMP，否则 cast 失效（比如存成VARCHAR的 '2024-03-15'，cast 后仍是字符串） - 想让自定义字段也自动转 Carbon，加到
$casts：'published_at' => 'datetime' - 如果字段名不标准（如
post_date），且不想改数据库，可用访问器：public function getPostDateAttribute($value) { return $value ? Carbon::parse($value) : null; }
时区处理最容易翻车：别只设 app.timezone，还要看 date_default_timezone_set() 和 MySQL 的 time_zone
Laravel 配置 config/app.php 中的 'timezone' => 'Asia/Shanghai' 只影响 Eloquent 模型输出和 now()，不影响底层 PHP 时间函数或 MySQL 查询结果。
立即学习“PHP免费学习笔记（深入）”；
- MySQL 连接初始化时建议显式设置时区：
DB::statement("SET time_zone = '+08:00'");（放在AppServiceProvider的boot()里） - Carbon 实例默认使用 PHP 默认时区，可通过
Carbon::setTestNow()或Carbon::now('Asia/Shanghai')强制指定 - 存储时间前务必确认：是存 UTC（推荐）还是本地时区？Laravel 默认用本地时区存，若服务器时区和业务时区不一致（比如服务器在 UTC，业务在 Asia/Shanghai），就会差 8 小时
Carbon 的复杂点不在 API 多，而在它把 PHP 原生时间处理的隐式行为显性化了——比如 ->addDays(1) 是按日历加，不是加 86400 秒；->startOfDay() 会把时分秒归零但保留时区偏移。这些细节不踩一次坑很难记住。
