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 链起来风险更大——删错一篇热门文章，几百条评论瞬间蒸发。