Laravel怎么使用Carbon处理时间_Laravel常用日期格式化与时区转换【方法】

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 CarbonCarbon;  // 推荐：明确、可控、跨版本稳定 $nextMonday = Carbon::now()->startOfWeek()->addDays(1);  // 不推荐：依赖自然语言解析，Carbon 2.x 可能报错或行为不一致 $nextMonday = Carbon::parse('next monday');

真正麻烦的不是语法，而是时区逻辑嵌在业务流里——比如定时任务用 now() 生成时间，但队列 worker 运行在 UTC 服务器，没显式调 ->utc() 就直接入库，第二天凌晨三点的数据就变成当天零点。这种 bug 往往上线一周才暴露。