评论数据结构需包含created_at、status、parent_id（NULLABLE并建索引）、user_id（非昵称），前端须校验空格、长度、XSS，禁用innerHTML渲染，采用游标分页替代offset/limit。
评论数据结构怎么设计才不容易翻车
后端存评论，核心字段不能只图省事写个 content 和 user_id。漏掉 created_at 会导致排序错乱；没加 status 字段（比如 "pending"/"approved"）后期想做审核就只能改表加迁移；如果允许嵌套回复，parent_id 必须设为 NULLABLE 并建索引，否则查某条评论的所有子回复会变慢。
常见错误：用字符串存用户昵称——用户改名后历史评论昵称不同步。正确做法是只存 user_id，展示时联查用户表或缓存昵称。
前端提交评论时必须校验什么
别只依赖后端拦截。用户粘贴 10000 字、发空格、塞 XSS 标签（比如 <script>）都是高频问题。前端至少要做三件事：
- 用
trim()判空，不是value === "" - 限制长度（建议 ≤ 500 字符），用
textContent或innerText渲染，避免直接innerHTML - 提交前检查是否已存在未发送的请求（防止连点触发多条重复评论）
如果用 React，别在 onChange 里实时调后端做敏感词检测——延迟高且浪费请求。本地正则先拦掉明显违规词（如 “http://” + 长随机串），再交由后端最终判断。
为什么分页加载评论不能只靠 offset/limit
当评论数过万、用户频繁增删时，OFFSET 1000 LIMIT 20 会越来越慢，因为数据库仍要扫描前 1000 条。更稳的方式是用游标分页（cursor-based pagination）：
每次请求带上上一页最后一条的 created_at 和 id，后端查 WHERE created_at 。这样不跳行、不漏数据，也规避了“别人刚插入一条顶到第一页导致你刷新后内容偏移”的问题。
注意：复合排序字段必须有联合索引，例如 INDEX idx_created_id (created_at, id)，否则性能照样崩。
CSRF 和登录态校验容易被忽略的点
评论接口看似简单，但常因疏忽变成攻击入口。两个关键动作不能少：
- POST 接口必须验证 CSRF token（尤其 Django/Flask 默认开启，但有人手动关掉）
- 即使前端显示了用户已登录，后端仍要从 session 或 JWT 中重新解析
user_id，不能信任前端传来的任何用户标识（比如user_id字段）
一个典型翻车场景：接口允许匿名评论，但忘了限制频率——机器人几秒内刷几百条。上线前务必加限流，比如基于 user_id 或 IP 的 60 请求/分钟 规则。
真正麻烦的不是写完功能，而是评论模块一旦上线，就会立刻暴露所有没想过的边界情况：时间戳时区错位、emoji 存储失败、富文本标签过滤不全……留好日志字段和快速回滚路径比追求“一次性写对”更重要。
