users表需设username和email为UNIQUE，password_hash用VARCHAR(255)存哈希值；comments表通过外键关联users和posts，含parent_id支持嵌套，content用utf8mb4，查询用INNER JOIN连用户并按时间倒序。

用户表设计要支持密码安全和唯一约束

用户注册登录必须保障基础安全，users 表不能只存明文密码。MySQL 本身不提供密码哈希函数（如 bcrypt），所以得靠应用层处理，但表结构要预留足够长度——VARCHAR(255) 是底线，因为 bcrypt 哈希值通常 60 字符左右，加盐后可能更长。

关键字段建议：

• id：主键，INT UNSIGNED AUTO_INCREMENT
• username：唯一且非空，加 UNIQUE 约束，避免重复注册
• email：也建议加 UNIQUE，方便找回密码
• password_hash：存哈希后的密码，**绝不能叫 password**，防止误读
• created_at：用 TIMESTAMP DEFAULT CURRENT_TIMESTAMP 自动记录

CREATE TABLE users (
  id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL UNIQUE,
  email VARCHAR(100) NOT NULL UNIQUE,
  password_hash VARCHAR(255) NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

评论表必须关联用户和文章，并支持嵌套线索

简易博客的评论不需要无限级嵌套，但至少要能区分“谁在哪个文章下评了什么”。comments 表需外键指向 users 和文章表（假设叫 posts）。如果未来想支持“回复某条评论”，就加一个 parent_id 字段，允许为 NULL（表示一级评论）。

注意点：

• 外键约束在 MySQL 中要求引擎为 InnoDB，MyISAM 不支持
• content 字段别用 TEXT 就完事，要设字符集，比如 TEXT CHARACTER SET utf8mb4，否则 emoji 或生僻字会乱码
• 不要用 DATETIME 存时间戳，用 TIMESTAMP 更省空间且自动时区转换友好

CREATE TABLE comments (
  id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  user_id INT UNSIGNED NOT NULL,
  post_id INT UNSIGNED NOT NULL,
  parent_id INT UNSIGNED NULL,
  content TEXT CHARACTER SET utf8mb4 NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,
  FOREIGN KEY (post_id) REFERENCES posts(id) ON DELETE CASCADE
);

查询评论时要连表获取用户名，避免 N+1

展示评论列表时，前端需要显示“张三：今天天气不错”，而不是只显示 user_id = 5。一次查出所有数据比循环查用户更高效。用 JOIN 是标准做法，但要注意 LEFT JOIN 还是 INNER JOIN：

• 用 INNER JOIN：只返回用户还存在、没被删的评论（推荐）
• 用 LEFT JOIN：即使用户被删，评论内容仍可见（需额外逻辑处理用户名显示）
• 别漏掉 ORDER BY created_at DESC，否则新评论在最底下

SELECT c.id, u.username, c.content, c.created_at
FROM comments c
INNER JOIN users u ON c.user_id = u.id
WHERE c.post_id = 123
ORDER BY c.created_at DESC;

删除用户时外键级联要谨慎启用

ON DELETE CASCADE 看似省事，但一删用户，ta 所有评论全没了，连历史痕迹都不留。对博客系统来说，这往往不合适。更稳妥的做法是：

• 把 user_id 外键改成 ON DELETE SET NULL，但前提是该字段允许 NULL
• 或干脆去掉级联，由应用层控制：删用户前先检查是否有评论，提示“请先转移或匿名化其评论”
• 如果真要用 CASCADE，务必在删除前加事务和确认日志，比如：START TRANSACTION; DELETE FROM users WHERE id = 123; SELECT ROW_COUNT();

另外，posts 表若也参与级联（比如删文章连带删评论），那两个 CASCADE 链起来风险更大——删错一篇热门文章，几百条评论瞬间蒸发。