可行但不推荐直接更新 read_at 字段，因会跳过事件触发、缓存更新和模型状态同步；应优先使用 markAsRead() 方法或 unreadNotifications()->markAsRead()，手动 SQL 更新后须确保 UTC 时间格式、清空缓存并重新查询。
直接更新 notifications 表的 read_at 字段可行吗？
可行，但不推荐。laravel 的 notification 模型默认把 read_at 设为 null 表示未读，设为时间戳表示已读——这个逻辑本身没问题，但绕过模型直接写 sql 或手动赋值容易跳过 laravel 的状态同步机制，比如关联的未读计数（unreadnotifications()）可能不会刷新，广播事件也不会触发。
用 markAsRead() 方法是最稳妥的方式
这是 Laravel 官方提供的语义化方法，它不仅更新 read_at，还会触发 NotificationMarkedAsRead 事件，并确保 Eloquent 关系缓存一致。
- 对单个通知：调用
$notification->markAsRead() - 对用户所有通知：用
$user->notifications()->update(['read_at' => now()])虽快，但跳过事件和模型事件钩子 - 批量标记时更推荐
$user->unreadNotifications->markAsRead()，它会遍历并逐个触发逻辑，安全但略慢；若量大（如上万条），可先查 ID 再用whereIn()+update()，再手动触发清理缓存（见下一条）
手动执行 SQL 更新后必须注意的三件事
如果因性能或迁移等原因必须直连数据库更新 read_at，以下三点漏掉一个，后续就可能查不到“已读”或统计错：
- 确保时间格式是数据库能识别的 UTC 时间戳（Laravel 默认用
datetime类型，不是 Unix 时间戳），例如'2024-05-20 10:30:00'，不是1716201000 - 更新后清空该用户的未读通知缓存：执行
Cache::forget("notifications.{$user->id}.unread_count")（如果用了自定义缓存键） -
Notification模型默认不会自动 reloadread_at属性，已加载的通知对象仍显示read_at = null，需重新查询或调用$notification->fresh()
read_at 为 NULL 和 0000-00-00 00:00:00 的区别
MySQL 严格模式下，0000-00-00 00:00:00 是非法值，会导致写入失败或被转成 NULL；Laravel 的迁移默认用 $table->timestamp('read_at')->nullable()，所以只认 NULL 表示未读。一旦数据库里出现 0000-00-00 00:00:00，$notification->read_at 会是 Carbon 实例但时间异常，$notification->isRead() 可能返回 false 却无法再标记为已读——这种脏数据得先用 SQL 清理：UPDATE notifications SET read_at = NULL WHERE read_at = '0000-00-00 00:00:00';
