数据库表设计必须包含status和created_at字段，否则无法准确标记已读/未读、无法正确排序分页；messages表至少需id、sender_id、receiver_id、subject、body、status（TINYINT）、created_at（DEFAULT CURRENT_TIMESTAMP），并加外键与索引，查询须用预处理语句防注入，更新status时同步维护未读数缓存，发信须强制绑定sender_id防伪造。
数据库表设计必须带 status 和时间戳
不加 status 字段，后续“已读/未读”就只能靠查 created_at 猜，用户刷新页面后状态就丢了；不加 created_at DEFAULT CURRENT_TIMESTAMP，排序和分页会出错，比如新消息排在旧消息后面。
常见错误是只建了 sender_id、receiver_id、subject、body 四个字段，上线后发现无法标记已读、不能按时间倒序展示、批量操作没依据。
-
messages表至少要有：id（主键）、sender_id、receiver_id、subject、body、status（TINYINT，0=未读，1=已读）、created_at（TIMESTAMP DEFAULT CURRENT_TIMESTAMP） - 外键约束建议加上：
FOREIGN KEY (sender_id) REFERENCES users(id)，但生产环境若用 MySQL 5.7+ 且引擎为 MyISAM，得先切 InnoDB，否则报错 - 如果未来要支持群发或系统公告，
receiver_id不能设为 NOT NULL，得允许为 NULL，并加一个type字段（1=私信，2=系统公告，3=群发）
PHP 查询收件箱时别直接拼接 $_SESSION['user_id']
用 "WHERE receiver_id = ".$_SESSION['user_id'] 这种写法等于把 SQL 注入大门敞开，哪怕用户登录态由你自己控制，中间件或 session 存储层一旦被绕过，攻击者就能拖库。更隐蔽的问题是：当 $_SESSION['user_id'] 为空或非数字时，查询直接返回全表或报错，前端显示空白却不报错，调试时很难定位。
- 必须用预处理语句：
$stmt = $pdo->prepare("SELECT * FROM messages WHERE receiver_id = ? AND status IN (0,1) ORDER BY created_at DESC"); $stmt->execute([$_SESSION['user_id']]); - 查之前先校验：
if (!isset($_SESSION['user_id']) || !is_numeric($_SESSION['user_id'])) { die('Access denied'); } - 不要在 SQL 里用
OR receiver_id IS NULL混合查私信+公告——类型分离不清，后期加权限控制时会反复改 SQL
标记已读不能只 UPDATE status=1，得同步更新未读数缓存
每次点开一条消息都去 SELECT COUNT(*) FROM messages WHERE receiver_id = ? AND status = 0，用户量一过万，首页顶部那个小红点就会变慢。更糟的是，多个标签页同时打开同一封信，可能因并发导致未读数扣成负数。
- 推荐做法：UPDATE 后立刻执行一次缓存更新，例如 Redis：
$redis->hIncrBy('inbox_unread:'.$userId, 'count', -1)，前提是你的登录态能稳定映射到$userId - 如果不用 Redis，至少把未读数存在用户表的
unread_count字段里，用事务包裹：UPDATE messages SET status = 1 WHERE id = ? AND receiver_id = ?; UPDATE users SET unread_count = unread_count - 1 WHERE id = ?; - 避免用 AJAX 多次点击“标为已读”按钮触发重复更新——前端要禁用按钮，后端接口需幂等，比如加条件
AND status = 0
发信逻辑里最容易漏掉的不是验证，而是 sender_id 的合法性检查
多数人会校验 receiver_id 是否存在，却默认 sender_id 就是当前登录用户，结果黑客伪造 POST 数据把 sender_id 改成管理员 ID，就能冒充发信。这不是理论风险——只要登录态用 session_id 做标识，又没做 IP 或 UA 绑定，就可能被会话劫持利用。
立即学习“PHP免费学习笔记（深入）”；
- 发信函数开头必须强制绑定发送者：
$senderId = (int)$_SESSION['user_id'];，然后 INSERT 时只用这个值，忽略任何来自表单的sender_id参数 - 如果系统允许后台管理员代发，那要单独走另一套鉴权路径，比如判断
$_SESSION['role'] === 'admin'才允许接收表单里的sender_id - 别在发信成功后直接跳转回列表页就完事——要加一句
header('Location: inbox.php?sent=1');并在 inbox.php 里清掉这个 GET 参数，否则刷新页面会重复提交
实际跑通的关键不在“怎么写 SQL”，而在于每一步操作是否明确知道它影响谁、何时失效、失败后如何恢复。比如 status 字段一旦设错类型（用了 VARCHAR 存 0/1），后续所有布尔判断都会静默失败；又比如没给 receiver_id 加索引，查收件箱时全表扫描，用户一多就卡死。这些细节不显眼，但压垮系统的往往就是它们。
