thinkphp无内置消息中心，需自行设计含receiver_id和is_read字段的消息表，用redis缓存未读数并设过期，业务中显式插入记录而非用success()提示。
ThinkPHP 没有内置的「消息中心」模块，所谓消息中心是业务层抽象，不是框架能力。你得自己设计数据结构、定义读写逻辑、控制未读标记、处理批量标记已读——框架只提供模型、队列、缓存等基础工具，不替你做业务判断。
消息表设计必须带 is_read 和 receiver_id
消息中心的核心是「谁发给谁、有没有看」。跳过 is_read 字段会导致后续无法区分未读数；漏掉 receiver_id（而非仅用 user_id）会让群消息、系统通知、私信混为一谈，查询时不得不加冗余 JOIN 或重复扫描。
推荐最小可用字段：
-
id：主键 -
sender_id：发送方 ID（可为 0 表示系统） -
receiver_id：接收方 ID（必须，支持单聊/广播） -
type：枚举值，如'system'、'private'、'notice' -
content：文本内容（或存 JSON 结构化数据） -
is_read：tinyint(1)，默认 0 -
created_at：时间戳
别把 title 单独抽成字段——多数场景下标题就是 content 的前 20 字截取，冗余存储反而增加一致性维护成本。
success() 和 error() 不是消息中心，只是跳转提示
很多人误以为控制器里调用 $this->success('已发送') 就等于「进了消息中心」。其实它只是渲染一个前端跳转页面，不落库、不关联用户、不可查、不可标记已读。它和消息中心完全无关。
真要对接消息中心，得在业务逻辑里显式插入记录：
$message = new MessageModel();
$message->sender_id = $currentUser->id;
$message->receiver_id = $targetUser->id;
$message->type = 'private';
$message->content = $request->post('content');
$message->save();
注意两点：
- 别在事务外直接
save()，否则发消息失败但主业务成功，状态就错乱了 - 如果用 Swoole 或 WebSocket 推送实时未读数，记得在
save()后触发事件，而不是依赖模板跳转
未读数统计必须走缓存，不能每次 COUNT(*)
用户打开首页查一次未读数，列表页再查一次，侧边栏又查一次——三次请求全走 SELECT COUNT(*) FROM message WHERE receiver_id = ? AND is_read = 0，数据库压力会随用户量线性上涨。
正确做法是：用户收到新消息时，用 Redis 做原子自增：
Redis::incr("user:{$receiver_id}:unread_count");
标记已读时同步减：
Redis::decr("user:{$receiver_id}:unread_count");
关键细节：
- 不要用字符串拼接 key，避免注入风险；用
sprintf('user:%d:unread_count', $id)更安全 - Redis key 要设过期时间（比如 7 天），防止长期不登录的僵尸 key 累积
- 定时任务每天凌晨把 Redis 中的未读数回写到 MySQL 的 user 表
unread_count字段作兜底，避免缓存丢失后归零
消息中心最难的不是存和查，而是「已读状态同步」：WebSocket 断连时消息是否算已读？多端登录时 A 端标已读，B 端是否立刻刷新？这些边界问题没有银弹，得根据你的产品容忍度定策略——比如强制所有客户端轮询最新 last_read_time，或者接受最多 3 秒延迟。别指望框架自动解决。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
