Carbon 默认集成于 Laravel，时区由 config/app.php 的 'timezone' 控制，实例化如 now() 或 new Carbon() 均默认遵循该配置；格式化须用 PHP date() 风格符号；数据库建议存 UTC，展示时再转目标时区；Carbon 2.x 起需注意方法行为与本地化差异。
Carbon 是 Laravel 默认集成的时间处理库，不需要额外安装，直接用 Carbon 类或辅助函数 now()、today() 即可操作时间。但很多人踩坑在时区没设对、格式化符号记混、或误用静态方法导致意外结果。
Carbon 实例化与默认时区怎么设才生效
Laravel 的全局时区由 config/app.php 中的 'timezone' => 'Asia/Shanghai' 控制，Carbon 实例默认会读取这个配置。但注意：Carbon::now() 和 now() 都受其影响，而 new Carbon() 也一样——除非显式传入时区。
- 正确设置项目统一时区：改
config/app.php，不是靠每次 new 时硬写new Carbon('now', 'Asia/Shanghai') - 临时切换时区用
Carbon::now('UTC')或->tz('UTC')，后者是链式切换，不改变原实例时区 - 别用
Carbon::createFromFormat('Y-m-d', '2024-01-01')不带时区参数——它会按当前应用时区解析，容易在跨时区部署时出错
常用格式化写法和易错符号
Carbon 继承 PHP DateTime，所以用的是 date() 风格格式符，不是 moment.js 那套。比如 'Y-m-d H:i:s' 没问题，但写成 'YYYY-MM-DD hh:mm:ss' 就完全不识别。
-
->format('Y-m-d H:i:s')→"2024-05-20 14:30:45"（24 小时制） -
->format('y-m-d g:i A')→"24-05-20 2:30 PM"（12 小时制 + AM/PM） -
->toDateString()→"2024-05-20"（只日期，不推荐用于存储，类型丢失） -
->toISOString()→"2024-05-20T14:30:45.000000Z"（带微秒，后端 API 传 ISO 标准首选） - 别用
->toDateTimeString()返回"2024-05-20 14:30:45"——它不带时区信息，前端解析可能按本地时区误读
时区转换要分清「显示转换」和「存储转换」
数据库里建议统一存 UTC（Laravel 迁移中用 $table->timestamp('published_at')->useCurrent(); 默认就是 UTC），展示时再转目标时区。否则多时区用户查数据会乱。
- 入库前转 UTC：
$post->published_at = now()->utc(); - 查出来转用户时区：
$post->published_at->tz('Asia/Tokyo')->format('Y-m-d H:i') - 用
->setTimezone('Europe/London')是修改原对象时区（会变时间值），->tz('Europe/London')是返回新实例（推荐） - 别在模型的
casts里写'published_at' => 'datetime:Y-m-d'——这会让取值时自动 format 成字符串，失去 Carbon 实例能力
Carbon 版本差异带来的兼容性注意点
Laravel 9+ 默认用 Carbon 2.x，而 Carbon 2 和 1 在部分方法行为上不同。例如：
-
Carbon::yesterday()在 2.x 返回昨天 00:00:00 的实例；1.x 可能返回相对今天减 1 天，但精度模糊 -
->diffForHumans()在 2.x 默认使用本地化语言（需配Carbon::setLocale('zh')），1.x 默认英文 - Laravel 10 已弃用
Carbon::parse()的模糊字符串解析（如'last monday'），建议改用明确构造：Carbon::now()->startOfWeek()->subWeek()
use Carbon\Carbon;
// 推荐：明确、可控、跨版本稳定
$nextMonday = Carbon::now()->startOfWeek()->addDays(1);
// 不推荐：依赖自然语言解析，Carbon 2.x 可能报错或行为不一致
$nextMonday = Carbon::parse('next monday');
真正麻烦的不是语法，而是时区逻辑嵌在业务流里——比如定时任务用 now() 生成时间，但队列 worker 运行在 UTC 服务器，没显式调 ->utc() 就直接入库，第二天凌晨三点的数据就变成当天零点。这种 bug 往往上线一周才暴露。
