ThinkPHP站内消息通知应采用“数据库驱动+前端轻量轮询/SSE”方案，核心是状态同步不丢、读写不冲突、未读数实时准确；需设计含to_user_id、from_user_id、type、status、created_at字段的消息表，并建联合索引(to_user_id, status, created_at)；未读数用“DB主表+Redis缓存”双写保障一致性；SSE推送需用stream响应、严格data格式、绑定用户身份、前端自动重连；标记已读须前端防抖+后端WHERE status=0幂等更新。
ThinkPHP 站内消息通知不需要重写整套通信协议，核心是「数据库驱动 + 前端轻量轮询/SSE」，关键在状态同步不丢、读写不冲突、未读数实时准确。
数据库表结构怎么设计才不翻车
消息表不能只存 content 和 user_id，否则无法支持已读/未读统计、批量标记、类型过滤等基础操作。常见错误是把发送者和接收者混在一个字段里，或漏掉 status 的多状态定义。
-
id（主键）、to_user_id（必填，接收方）、from_user_id（可为空，系统消息设为 0） -
type（tinyint，1=系统通知，2=用户私信，3=评论回复，避免用字符串枚举） -
status（tinyint，0=未读，1=已读，2=已删除（软删），别用布尔值，留扩展余地） -
created_at（datetime，索引它，查询未读时按时间倒序取前 N 条） - 加联合索引：
(to_user_id, status, created_at)，否则用户进消息页卡顿明显
未读数实时更新为什么总不准
前端靠定时 AJAX 查 /message/unread 接口返回数字，但后端如果每次查全表 COUNT，高并发下会拖慢 DB；如果用缓存（如 Redis），又容易和 DB 状态不同步。最稳的解法是「DB 主表记录 + 缓存兜底」。
- 用户打开消息列表页时，执行一次
UPDATE message SET status = 1 WHERE to_user_id = ? AND status = 0，再查当前未读数（此时已清零） - 新消息插入时，同时执行
INCR redis_key:unread:{user_id}，并在事务里保证 DB 写入成功才 incr - 前端轮询接口优先读 Redis，超时或空值时 fallback 到 DB 查询并回填缓存
- 别用
SELECT COUNT(*)实时算——1000 用户在线，每 5 秒刷一次，DB 就开始抖了
ThinkPHP6 怎么接 SSE 实现实时推送
SSE 比 WebSocket 轻，适合单向下行（服务端推通知），且 ThinkPHP6 原生支持流响应，不用额外装 Workerman。难点在连接保活和浏览器兼容性，不是写个 EventSource 就完事。
立即学习“PHP免费学习笔记（深入）”；
- 控制器里用
response()->stream()，设置 header：Content-Type: text/event-stream、Cache-Control: no-cache、Connection: keep-alive - 每个连接需绑定用户 ID，建议从 token 或 session 中提取，**不能靠 GET 参数传 user_id**（易被伪造）
- 推送格式必须严格：以
data: {json}开头，结尾双换行，例如：data: {"id":123,"title":"新评论"}\n\n
- 前端
EventSource实例需监听error事件并自动重连，SSE 默认断连后 3 秒重试，别依赖默认行为 - Chrome/Firefox 支持好，Safari 对本地开发（
http://localhost）有 CORS 限制，上线必须用 HTTPS
消息标记已读的接口为什么总被重复调用
用户点击“全部标为已读”按钮后，前端发请求，后端改状态，但用户手快连点两下，就可能触发两次 SQL UPDATE。这不是并发问题，是前端防抖没做，也不是后端要上分布式锁。
- 前端按钮点击后立即置灰 + 加载态，禁用再次点击（用
disabled属性，别只靠 JS 变量） - 后端接口加幂等判断：UPDATE 语句带条件
WHERE status = 0，返回影响行数，若为 0 说明已处理过，直接返回成功 - 别用
UPDATE ... SET status = 1全量更新，一定要带AND status = 0，否则二次请求会把已读消息又刷一遍 - 如果走队列异步标记（比如用 Redis 队列），务必确保消费者是单进程，否则多 worker 同时消费同一条任务会导致状态错乱
真正麻烦的从来不是“怎么显示一条消息”，而是“怎么让 1000 人同时看到未读数变 1 的那一瞬间不延迟、不跳变、不重复”。数据库索引、缓存更新时机、HTTP 流响应的换行格式——这些细节一错，整个通知体验就塌一半。
