Carbon::parse() 有时返回 null 是因非法时间字符串被静默处理为当前时间而非报错，应改用 createFromFormat() 或前置校验；format() 性能低于 toDateString() 因后者省去格式解析；队列中 now() 需放 handle() 内实时获取；存 datetime 要注意微秒截断与字段精度匹配。
Carbon::parse() 为什么有时返回 null 而不是报错
Carbon 默认对非法时间字符串（比如 "2023-02-30" 或空字符串）会静默转成当前时间，而不是抛异常——这容易掩盖输入校验问题。实际开发中，你得主动加防护。
- 用
Carbon::createFromFormat()替代parse()，它在格式不匹配时直接抛InvalidArgumentException - 如果必须用
parse()，先用正则或filter_var($input, FILTER_VALIDATE_REGEXP, ['options' => ['regexp' => '/^\d{4}-\d{2}-\d{2}.*$/']])做前置校验 - 注意时区：
parse("12:00")在 Laravel 的app.timezone下解析，不是服务器本地时区
format() 和 toDateString() 的性能差异在哪
format() 是 PHP 原生 DateTime::format() 的封装，每次调用都走完整格式化流程；而 toDateString()、toTimeString() 这类快捷方法是 Carbon 内部硬编码的固定格式输出，少一层解析开销。
- 高频循环里格式化日期（如列表页每行一个日期），优先用
toDateString()而非format('Y-m-d') -
format()支持自定义，但要注意'h:i A'和'g:i a'在 12 小时制下行为不同（前者补零，后者不补） - Laravel Blade 中
{{ $date->format('M j, Y') }}比{{ $date->isoFormat('MMM D, YYYY') }}更快，后者依赖额外的 locale 数据加载
Carbon::now() 在队列任务里为什么总是取到启动时间
因为 Laravel 队列 worker 启动后常驻内存，Carbon::now() 如果被写死在闭包或 job 构造函数里，就只执行一次——后续所有任务都复用那个“冻结”的时间点。
- 把
Carbon::now()移到handle()方法体内，确保每次执行都实时获取 - 不要在 job 属性里存 Carbon 实例：
$this->scheduledAt = Carbon::now();❌，改用时间戳$this->scheduledAt = now()->timestamp;✅ - 测试时用
Carbon::setTestNow()模拟时间，但记得在tearDown()里调用Carbon::setTestNow()清空（传 null）
MySQL datetime 字段存 Carbon 对象时丢精度怎么办
MySQL DATETIME 类型默认只支持秒级，但 Carbon 默认带微秒（2023-04-05 14:23:18.123456）。直接塞进去会被截断，且 Laravel 不报错。
- 显式调用
$carbon->second(0)->microsecond(0)截掉微秒，或用$carbon->truncate(1)（Laravel 9+） - 如果数据库字段是
DATETIME(6)，需在 migration 中声明：$table->datetime('started_at', 6); - Eloquent 模型里加
protected $dateFormat = 'Y-m-d H:i:s.u';才能正确读写微秒，否则u会被忽略
微秒精度和 MySQL 版本强相关，5.6.4 以下根本不支持 DATETIME(n)，别在低版本上硬刚。
