Laravel通知已读/未读状态本质依赖read_at字段是否为NULL，而非布尔值is_read；DatabaseNotification模型硬编码使用read_at，手动添加is_read会导致状态不一致、内置方法失效及维护困难。
直接说结论：Laravel 的通知已读/未读状态，本质就是靠 read_at 字段是否为 NULL 来判断的，不是布尔值，不能加 is_read 字段——否则会和原生逻辑冲突。
为什么必须用 read_at 而不是 is_read？
Laravel 的 DatabaseNotification 模型硬编码依赖 read_at 字段做状态判断：markAsRead() 写入时间戳，unread() 判断是否为 NULL。如果你手动加了个 is_read 布尔字段：
- 所有内置方法（如
$user->notifications()->unread()）会完全无视它 -
notifications:table迁移不会创建该字段，你得自己维护，容易漏同步 - 调用
$notification->markAsRead()后，is_read仍为 false，状态不一致
如何正确获取「先未读、再已读」的通知列表？
常见错误是想在一个请求里「先查全部 → 渲染 → 再统一更新」，结果用户第一次看到的仍是未读状态（因为视图渲染时 read_at 还是 NULL）。正确做法是分两步明确分离：
- 控制器里用
whereNull('read_at')显式只查未读：$unread = $user->notifications()->whereNull('read_at')->latest()->get() - 如果还要显示已读，再单独查一次：
$read = $user->notifications()->whereNotNull('read_at')->latest()->take(20)->get() - 不要在同个查询里用
orderByRaw('read_at IS NULL DESC')混排——会导致分页错乱，paginate()无法按真实状态切片
点击通知后怎么自动标记为已读？
关键点在于：不能依赖 URL 锚点（如 #123），服务端收不到；必须把通知 ID 作为 GET 参数传过来，然后在路由中处理：
- 链接生成要带 ID 和跳转目标：
route('notifications.mark', ['id' => $n->id, 'redirect' => request()->fullUrl()]) - 对应控制器方法里先
find($id)，确认属于当前用户，再调用$notification->markAsRead() - 务必校验
$notification->notifiable_id === auth()->id()，否则别人能伪造 ID 标记他人通知 - 标记完重定向回原页面，避免重复提交
性能与边界要注意什么？
用户通知多时，$user->notifications() 默认加载全部关联字段（包括大体积的 data JSON），但列表页往往只需要标题和时间：
- 用
select('id', 'type', 'data', 'created_at', 'read_at')显式限定字段 -
data字段默认是 JSON，但 Laravel 不会自动解包；如果模板里要取$n->data['title']，确保data是数组（casts = ['data' => 'array']已配好） - 全量标记已读（如小铃铛一键已读）别用
update()全表更新，改用$user->notifications()->whereNull('read_at')->update(['read_at' => now()])，避免锁表或误触他人数据
最易被忽略的是时间精度问题：read_at 是 datetime 类型，但 MySQL 5.6 默认只到秒级；如果高频并发标记，可能出现两条通知 read_at 完全相同，导致后续排序不可靠——升级到 5.7+ 并用 datetime(3) 可缓解。
