站内信数据表核心字段为id、user_id、sender_id、title、content、unread（tinyint(1)，默认1）、created_at；必须为user_id建索引，unread须为每消息独立字段以保障并发一致性。
Yii 框架本身不内置站内信模块，但可以用 ActiveRecord + 队列 + 通知组件快速搭出轻量、可扩展的站内信系统，关键在“读写分离”和“状态标记”设计。
如何建站内信数据表（必须含 unread 字段）
站内信不是日志，不能只 insert 不 update。核心字段至少要有：id、user_id、sender_id、title、content、unread（tinyint(1)，默认 1）、created_at。不要用 is_read 这种命名——语义模糊，且后期加“已读回执”“多次重读”时容易冲突。
常见错误：把所有用户的消息塞进一张大表，未加 user_id 索引，查收件箱时全表扫描；或把未读数存在用户表里，导致并发更新丢失（两人同时点开同一条，unread=0 被覆盖两次，实际只变一次）。
-
unread必须是 per-message 字段，靠数据库行级锁保障一致性 - 查询未读数直接
COUNT(*) WHERE user_id = ? AND unread = 1，别缓存到 Redis 再同步，小项目反而增加复杂度 - 如果消息要支持“分组归档”（如系统通知/私信/评论），加一个
type字段比建多张表更灵活
Yii2 中怎么发一条站内信（避免阻塞响应）
别在控制器里直接 new Message()->save()。用户提交表单后，真正要通知的对象可能有几十人（比如一篇博文被点赞，关注者都该收到），同步写库+发邮件+推 WebSocket 会拖慢主流程。
正确做法是：用 yii-queue 把“生成并插入站内信”作为异步 Job。
- 定义 Job 类，
execute()方法里做Message::create([...])，别传 Active Record 实例（序列化失败） - 发送方调用
Yii::$app->queue->push(new SendInboxMessageJob($data))，$data只传原始数组（['to_user_ids' => [1,5,8], 'title' => '你有一条新回复']） - 不要在 Job 里查用户列表——查的动作应由发起方完成并传入，否则队列重试时重复查询，可能漏人或重复发
怎么查收件箱并标记已读（原子操作很关键）
用户点开收件箱页面，要同时做两件事：查未读消息列表 + 把这批消息设为已读。不能先查再 update，中间可能被其他请求插入新消息，造成“已读列表漏掉最新一条”。
Yii2 没有原生的“查+改”原子方法，得手写 SQL 或拆成事务：
- 推荐方式：用
UPDATE message SET unread = 0 WHERE id IN (SELECT id FROM (SELECT id FROM message WHERE user_id = ? AND unread = 1 ORDER BY created_at DESC LIMIT 20) AS tmp)，再查一遍这 20 条（确保顺序一致） - 简单项目可用事务：
Message::find()->where(['user_id' => $uid, 'unread' => 1])->limit(20)->all()，拿到 ID 数组后Message::updateAll(['unread' => 0], ['id' => $ids])，靠事务包裹 - 千万别用
->one()查一条改一条循环——N 条消息 N 次查询，性能崩盘
前端怎么实时感知新消息（不用轮询）
WebSocket 不是唯一解，也未必最合理。对站内信这种低频、非强实时场景，EventSource（SSE）更轻量、兼容性更好，且服务端用 Yii 的 Response::stream() 就能支撑。
要点：
- 前端用
new EventSource('/inbox/stream')，后端路由返回text/event-stream响应头 - 服务端保持连接打开，当有新消息时，输出
data: {"id":123,"title":"..."}并 flush - 不要让每个用户连一个长连接——用 Redis Pub/Sub 做广播，所有监听
inbox:uid_123的连接共享同一份事件流 - 如果硬要用 WebSocket（比如已集成 Ratchet），注意别把消息体塞进
onMessage处理逻辑里反查数据库，应在推送前就组装好最小 JSON
最容易被忽略的是“已读状态的边界”。比如用户 A 给 B 发消息，B 在手机 App 里点开看了，但 Web 端没刷新，这时 Web 端的未读数还是旧的——这不是 Bug，是设计选择。要不要跨端同步已读？取决于产品需求，而不是技术能不能做。
