评论模块后端设计实战：表结构、缓存、幂等与防刷全解析

这个章节内容，我打算从评论模块这个点出发，把它当成一个完整的小项目来拆。很多人觉得评论模块就是“一个表 + 增删改查”，真的上线跑起来才发现处处是坑。嵌套层级怎么存、热点文章评论怎么扛、用户手滑重复提交怎么防、删了父评论子评论怎么办、emoji 表情存进去怎么变成问号，这些问题不提前设计好，后面都要返工。

这篇文章我会按照我实际开发时的思路走一遍：表结构怎么设计、接口边界怎么划、缓存和一致性怎么做、前后端联调有哪些坑，最后附上一些生产环境里排查问题的记录。无论你是刚接触后端的学生，还是已经在写业务 CRUD 的初级开发，这篇都值得花十分钟看完，能帮你省掉不少试错时间。

1. 评论模块的定位：为什么它值得单独写一章

评论模块在后端业务里属于典型的高频、读多写少、数据量增长快、安全要求高的场景。拿内容类产品来说，一篇文章可能只有几千次浏览，但热评区的互动量可能比正文还多。评论系统一旦设计不好，轻则接口超时拖垮整个详情页，重则被刷评论、刷广告、恶意攻击，直接污染内容生态。

评论模块最迷惑人的地方在于，从接口层面看它简单得不像话：一个列表接口、一个发表接口、一个删除接口，完了。但深入拆开，它要处理的子问题非常多：数据模型要支持嵌套、查询要做分页和排序、写入要处理幂等和频率控制、内容要做敏感信息过滤、还要考虑缓存策略和热门评论的数据一致性。任何一个环节偷懒，上线后都会出问题，而且这些问题往往是在凌晨流量高峰时候突然爆出来的。

另外，评论模块是前后端分离项目中联动最多的模块之一。前端要处理评论框的焦点、楼中楼的展开收起、表情输入；后端要处理评论树组装、跨域配置、按钮重复提交校验。这一章虽然标题写的是“后端”，但我会把前后端接口约定那一层也讲清楚，否则后端做得再稳，前端对接起来也难受。

这一章内容适合这几类人看：正在写电商、社区、CMS、知识付费这类带 UGC 评论的业务开发；做毕业设计选“前后端分离项目实战”方向的学生；以及准备后端面试、想刷评论系统设计题目的同学。评论模块是面试里非常高频的系统设计考点，和“秒杀系统”“短链系统”一个待遇，但因为它业务场景亲切、名词不唬人，反而更容易在一线实操层面聊出深度。

我写这一章的思路是：不堆概念，直接给结论、给 SQL、给时序，把我实际项目中踩过的坑和最后采用的方案完整过一遍。对于设计取舍的地方，我会说明当时为什么没有选另一个方案，因为技术选型没有绝对的对错，只有合不合适的场景。

2. 数据模型与表结构设计：先把地基打牢

2.1 通用评论模型还是耦合业务模型

很多新手项目里，评论表直接叫article_comment，字段只围绕文章设计，看起来简单直接。但我强烈建议用通用评论模型——表里放target_type和target_id两个字段，用来区分评论归属于哪类业务对象。

原因很简单：评论作为一种 UGC 能力，通常会先落地在文章上，但用不了半年就会有人说“咱们视频也想支持评论”“动态也想加评论”“商品评价也想复用”。如果你一开始就写了article_comment，到时候要么新加一张表复制一份代码，要么改表加字段兼容多个业务，两种路都别扭。用target_type + target_id的方案，新增一个业务场景只需要约定一个 type 值，后端接口一行都不用改。

这张通用评论表的结构，我按线上项目实际使用情况简化如下：

CREATE TABLE `comment` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `target_type` varchar(32) NOT NULL DEFAULT 'article' COMMENT '评论目标类型', `target_id` bigint NOT NULL COMMENT '评论目标ID', `parent_id` bigint NOT NULL DEFAULT '0' COMMENT '父评论ID，0表示一级评论', `root_id` bigint NOT NULL DEFAULT '0' COMMENT '根评论ID，0表示一级评论', `user_id` bigint NOT NULL COMMENT '评论用户ID', `reply_user_id` bigint NOT NULL DEFAULT '0' COMMENT '被回复用户ID，平铺回复时使用', `content` text NOT NULL COMMENT '评论内容', `like_count` int NOT NULL DEFAULT '0' COMMENT '点赞数', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：1正常，0删除', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), KEY `idx_target` (`target_type`,`target_id`,`create_time`), KEY `idx_user` (`user_id`,`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='通用评论表';

表结构里几个容易被忽略的设计点：

• reply_user_id是给“楼中楼”用的。用户 A 评论了用户 B 的评论，这条记录挂在 B 的评论下面，但要记录 A 回复的对象是 B，前端渲染时才能显示“回复@某人”。这个字段也方便做站内信通知。
• content必须用text，不要用varchar(255)。评论内容长短差异很大，有的用户就发个“哈哈哈”，有的用户能写小作文。虽然业务层可以限制长度，但数据库层面不要卡死。
• 字符集必须用utf8mb4。评论是 emoji 表情的重灾区，如果用了老项目的utf8字符集，用户发一个 😂 存进去就变成????，这种问题排查起来非常磨人。

2.2 嵌套评论用邻接表就够，别过度设计

评论嵌套有两种常见存储方案：邻接表和闭包表。邻接表就是每条记录只存parent_id；闭包表要单独建一张表存所有祖先后代关系。业内绝大多数产品用的都是邻接表，因为它足够简单，能覆盖真实业务场景，而闭包表虽然查询子树方便，但写入时维护关系成本高、容易出错，性能收益在“评论最多两层楼中楼”的业务里也体现不出来。

考虑到用户阅读习惯，评论层级不宜过深。正常产品设计里，展示到两级就差不多了，再多用户根本看不过来。所以parent_id记录直接父级，root_id记录根级，查询时只需要把目标文章下所有评论一次性取出来，在内存里组装成树，完全不需要数据库递归查询。

root_id是这类表设计里非常关键的一个字段。它的价值体现在两个地方：第一，一级评论分页时可以直接WHERE root_id = 0，拿到的是“根评论列表”；第二，帖子里要做“按热度排序”时，排序对象是根评论，而不是子评论。一条子评论点赞再多，也应该跟着它所属的根评论一起出现。

2.3 索引设计与数据归档思路

很多项目评论表上线半年后单表轻松破千万，为什么？因为评论是永久性数据，很少删除，而且热门内容一天就能产生几万条。针对查询场景，idx_target(target_type, target_id, create_time)是核心索引，覆盖“某篇文章下所有评论按时间取”的路径。如果你业务里经常按用户维度查“我评论过的内容”，保留idx_user(user_id, create_time)这个索引也有价值。

评论表不建议做复杂索引组合，因为评论查询基本就两条路：按目标对象查、按用户查。索引多了影响写入性能，评论又是高频写入场景，得不偿失。

至于数据归档，常见做法是把 90 天前的冷评论迁移到归档表，或者直接把status=0的数据按月拆到历史表。这块根据团队运维成本来决定，但至少要意识到评论表数据膨胀速度很快，提前设计好清理方案，不要等到磁盘报警再慌。

3. 核心接口设计与边界处理

3.1 查询接口：游标分页 + 树形组装

评论列表接口是评论模块最核心的接口，也是性能优化空间最大的地方。很多人一上来就写“第 N 页”，用LIMIT offset, size分页，这在数据量小的时候没问题，但评论一旦过万，深翻页时offset越来越大，数据库扫描和丢弃的代价越来越高，响应时间指数级上涨。

我采用的做法是游标分页，对外暴露两个参数：cursor（上一次返回列表最后一条评论的 ID 或时间）和size（每页条数）。查询语句用WHERE target_id = ? AND root_id = 0 AND id < cursor ORDER BY id DESC LIMIT size。这是典型的“增量加载”模式，用户点击“加载更多”时携带上一次的游标，性能稳定，不会因为数据量增加而劣化。

root_id = 0这个条件很重要。它的含义是：分页只分根评论，每个根评论下面挂它的所有子评论一次性返回。这样用户在浏览时，看到的是一层完整楼层，不会出现“第一页最后一个根评论的子评论被截断”的诡异情况。

分页拿到的根评论集合，会进入内存树组装流程。思路分成三步：

第一步，用一次查询把当前页所有根评论取出来，同时用root_id IN (当前的根评论ID集合)把这些根评论下的子评论也查出来，成一个 Map。第二步，遍历根评论，通过parent_id把子评论挂到对应父节点下。第三步，对顶级评论按时间倒序、对子评论按时间正序进行排序，得到一棵评论树。

这里有两个非常容易出现性能问题的地方。第一，子评论查询时where root_id in (...)的集合不能太大，控制在几百个以内没问题，但一次加载几千个根评论再查子评论，数据库压力就大了。第二，查询子评论时千万别逐条查询，否则会触发 N+1 问题，这是评论模块的首号性能杀手，我后面专门展开讲。

3.2 新增接口：幂等与防重复提交

发表评论的业务逻辑很多人觉得简单——接收参数，校验内容，插入数据库，完事。但这一条看似人畜无害的链路，在高并发场景下会暴露一个经典问题：用户手快点了两次发表按钮，数据库里插了两条重复评论。

从前后端分离项目的视角看，这个问题要两头治。

前端方案是按钮防抖：用户点击发表后，按钮立即置灰并进入 loading 状态，接口返回前禁止再次点击。这个方案实现简单，能解决 90% 的手误重复提交。但前端防抖不能完全信任——网络超时后用户刷新页面、App 端重试机制、脚本批量提交等情况，都会绕过按钮置灰直接打到后端。

后端方案要保证幂等。常用做法是引入幂等令牌，流程是这样：前端在评论框聚焦时向后端请求一个token，携带用户、目标对象指纹（比如 md5(target_type + target_id + userId)）存到 Redis，过期时间设为 5 分钟；用户提交评论时带这个 token；后端先校验 token 存在且匹配，校验通过后删除 token，再执行插入逻辑。这样一来，同一用户对同一篇文章在有效期内只能提交一次，第二次提交会因为 token 不存在而被拒绝。

如果业务不想额外引入 token 机制，还有两个反向思路：一是数据库唯一键约束，比如把user_id + target_type + target_id + content_hash建唯一索引；二是 Redis 分布式锁 + 短窗口去重，同一个用户在 10 秒内对同一个目标只有一次写库机会。这两种方案都有取舍，第一种要求内容完全一致才能触发去重，用户稍微改一个字就失效；第二种会误伤用户连续发表多条不同评论的合理场景。综合来看，幂等令牌 + 前端置灰是成本和体验最均衡的方案。

3.3 删除接口：软删除是必须的

评论删除有个很容易被忽视的点：直接物理删除会导致子评论悬空。假设用户 A 发了一条根评论，用户 B 在这条评论下面回复了三条，此时根评论被物理删掉，B 的三条回复在页面上就变成无所依归的孤儿数据。

所以评论删除几乎都采用软删除：status从 1 置为 0，记录还在，但查询时过滤掉。这个方法优雅地解决了“人走楼空”的问题——顶级评论删掉后，它下面的子评论虽然看不到父节点，但子评论本身依然能展示，用户可以理解这是一条被删除评论的楼中楼。

软删除还有一个额外好处：可以做“评论恢复”。运营误删或者平台申诉场景下，把status改回来就能立刻恢复展示，不需要找回物理数据。当然，不涉及审计要求时可以这样处理；如果评论系统涉及法律合规，建议把删除详情写进操作日志流转记录，这一点要结合具体业务合规要求来定。

删除接口要做的权限校验通常有三层：评论是否存在、评论归属是否当前用户或当前用户是否有管理权限、目标对象是否允许删除。评论归属校验很关键，否则用户传一个别人的评论 ID 就能删掉别人的发言，这是典型的水平越权漏洞。

4. 性能与一致性方案：别让评论拖垮主流程

4.1 热点评论的缓存设计

评论是典型的“读多写少”场景，一篇热门文章被推上首页后，评论区可能在数小时内增长上万条数据，详情页流量也集中在同一时段。MySQL 单库扛这种瞬时读压力是能扛，但代价是连接池被打满，其他业务跟着遭殃。所以评论数据必须加缓存。

我用的缓存方案是：以目标对象维度聚合缓存，key 为comment:list:{targetType}:{targetId}，value 存评论树序列化后的 JSON 或压缩后的字符串，TTL 设为 30 分钟。首次请求时回源数据库组装评论树，写入 Redis；之后同一篇文章的评论请求直接命中缓存，不落库。

这个方案对查询性能提升显著，但有两个问题需要提前设计好。

第一，评论树 JSON 体积。一篇超热文章的完整评论树可能几十 KB，序列化和反序列化大对象还是有 CPU 开销，而且 Redis 单个 key 过大对集群迁移、持久化都有压力。解决办法是在聚合缓存里只放最新 N 条评论，比如最新 100 条根评论及其子评论，更深的历史评论走游标分页直接查库。业务上这合理：用户通常只看前几页热门评论，老评论已经沉下去了。

第二，缓存写入时机。评论查询回源后要加“缓存击穿保护”，否则大量并发回源会瞬间压垮数据库。我用的是SET NX+ 短 TTL 的分布式锁，拿到锁的那个请求负责回源写缓存，其他请求短暂等待后读缓存；为了降低等待，锁释放后立刻重试一次缓存读取，通常能命中。

4.2 评论数与缓存的最终一致性

评论数这个数据点，单独提出来说是因为它太容易被设计错了。很多系统直接在查询时SELECT COUNT(*) FROM comment WHERE target_id = ?，数据量大了以后这条语句本身就很慢，而且每次都要和列表接口串行执行，白白增加查询耗时。

合理做法是在目标对象表冗余一个评论数字段，比如文章表加comment_count字段。发表评论时执行UPDATE article SET comment_count = comment_count + 1 WHERE id = ?；删除评论时减一。这里注意软删除只对用户可见性做控制，计数增减依然要执行，否则数字不准。

但这个方案在极高并发时会有问题：comment_count + 1是热点行更新，同一篇文章的评论区高爆发时，这条 UPDATE 会锁竞争，成为性能瓶颈。业界常用的解法是评论计数服务化——用 Redis 的INCR记录计数，定期异步刷到库，或者干脆计数只走 Redis，文章详情页读取时优先读缓存计数，缓存丢失再回源库。

缓存和数据库的一致性我采用“先更新数据库，再删缓存”的策略。为什么删而不是更新缓存？因为评论数变化导致评论列表排序变化概率很高，用更新缓存的方式要重新组装评论树，成本高；直接删除缓存让下一次请求回源重建，简单可靠且逻辑不会出错。删除缓存后到下一次重建之间，会有一小段窗口期的数据不一致，但评论数据的最终一致性是可以接受的——用户发表评论后刷新页面看到自己评论的延迟在毫秒级，感知不到。

4.3 躲开 N+1 查询这个性能杀手

N+1 查询是评论模块性能问题中最隐蔽也最常见的一个。场景是这样的：查询根评论列表得到 20 条评论，然后循环遍历每条评论去查user表拿到用户名和头像。20 条评论就触发 20 次用户表查询。文章评论超过 100 条时，一个详情页接口就背了 100 多次数据库查询，数据库连接池被这种低效查询拖死，接口平均耗时轻松上千毫秒。

解决思路非常简单：批量化。把查询到的所有评论里的user_id收集成一个集合，用WHERE user_id IN (...)一次查出全部用户信息，构建成 Map，再在内存里与评论数据关联。同理，子评论查询、点赞状态查询、用户脱敏信息查询，全部遵循“收集 ID → 批量查 → 内存组装”这条铁律。

上线后我用 APM 工具检查，优化前后详情页接口的数据库查询次数从 80+ 次降到了 3 次，接口 P99 耗时从 1.8 秒降到了 300 毫秒以内。评论列表这类集合接口，优化目标永远不是“少写代码”，而是“减少数据库交互次数”。

5. 前后端联调重点：跨域、渲染与防刷

5.1 跨域问题怎么一次配干净

前后端分离项目开发时，前端在localhost:5173，后端接口在localhost:8080，两者不同源，第一道坎就是跨域。有些开发者图省事，在后端直接setHeader("*")开放所有跨域，这在开发环境能用，但生产环境等于裸奔，任何站点都能往你接口发请求，极度危险。

推荐的做法是在服务端做一个 CORS 配置类，只允许配置的域名列表访问，同时开启请求方法和请求头白名单。这里有个经验：CORS 预检请求（OPTIONS）如果要走 Spring Security 的过滤器链，必须在安全配置里明确放行 OPTIONS 方法，否则前端刷新几次就发现所有跨域请求开始报 403，排查半天结果是预检被拦了。很多前后端联调卡在跨域，都是这个小细节引起的。

除了 CORS，还要警惕“浏览器觉得跨域，服务端觉得是同源”的微妙差异。比如 Nginx 层没有转发Host头、代理时丢失了Origin头等，这些会导致 Nginx 层 CORS 行为不符合预期。联调前先确认整体链路：前端 → Nginx → 后端，每一层的 CORS 配置都要对齐。

5.2 评论树由谁来组装：后端还是前端

评论列表的树形组装放在后端还是前端，这个决定影响接口设计和前端渲染代码量，属于前后端接口约定的核心决策点。我最终选择的是后端组装完整评论树返回 JSON，前端只需要按层级递归渲染，不用处理循环引用和节点归属问题。

有人会觉得“后端返回平铺列表、前端自己组装”更省后端算力。但实际经验是，前端拿到平铺数据后写递归组件、维护节点父子关系、处理折叠展开逻辑，代码量和复杂度都很高，而且每个前端开发对嵌套数据的处理方式还不一样，极易出现不一致。后端组装树的好处是接口返回结构稳定，前端逻辑简单，同时后端可以通过限制最大层级来保护性能，避免前端递归过深出现栈溢出。

返回结构参考如下：

{ "code": 200, "data": { "frecentComments": false, "items": [ { "id": 1001, "content": "讲得很细，收藏了", "user": { "nickname": "代码王", "avatar": "/xxx.png" }, "children": [ { "id": 1002, "parentId": 1001, "replyUser": { "nickname": "代码王" }, "content": "补充一点，事务要加", "user": { "nickname": "架构师老张" } } ] } ], "cursor": 1001, "hasMore": true } }

5.3 按钮重复提交校验的前后端配合

前端对评论按钮做“防抖 + 置灰”是体验层保障，后端做“幂等校验”是数据层兜底，二者缺一不可。具体到评论模块，前端的实现一般是这样：点击发表后按钮disabled，同时启动一个 500 毫秒的防抖计时器；如果接口报错，恢复按钮并提示用户重试；如果接口超时，不要立即恢复可点状态，而是先调一次查询确认评论是否真的发了，这样能避免用户重复提交。

后端在幂等校验之外，还应该配合频率控制。一个用户 1 分钟内对同一目标对象的评论次数要有限制，比如最多 10 条。这个后端做起来很轻量，RedisINCR带上过期时间即可实现。别觉得这是给用户添堵，评论区刷屏、水军灌水都是从“不设防”开始的。

另外强调一个安全细节：评论内容必须做XSS 过滤。用户提交的评论里带<script>标签或者onerror事件，如果后端不做过滤直接存库再返回到前端页面，就会被浏览器当成页面的一部分执行，形成存储型 XSS 攻击。后端入库前过滤，前端渲染时也建议用文本插值而不是v-html，双端同步设防才能放心。

5.4 敏感词过滤与内容安全

内容安全是评论模块“看不见的必做项”。裸奔的评论系统上线第二天就可能被刷满垃圾广告。敏感词过滤我采用两段式处理。

第一段是网关或后置异步任务做敏感词匹配，基于 DFA 算法构建敏感词树，命中后把评论状态置为待审核或直接替换成*。第二段是接入云服务的内容安全接口，做图片鉴黄、文本反垃圾、广告识别。这两段处理都放在异步任务里，不能同步阻塞发表评论链路，否则会大幅降低发表体验。

敏感词库要动态更新，不要写死在代码里。常见做法是把敏感词列表放到配置中心或者数据库，定期加载到本地内存，配合定时刷新。这样运营同学可以直接在后台维护敏感词，不需要发版。评论领域对政治、色情、广告等类别尤其敏感，这块要严格按平台规范和法律法规执行。

6. 常见问题排查清单与避坑指南

评论模块上线后，我整理了生产环境排查记录中频率最高的几个问题，每一类都附了排查思路和解法，可以直接当速查表用。

6.1 时区问题：为什么别人看到的评论时间多了 8 小时

评论模块里用户时间展示乱掉的问题十有八九是数据库时区设置与后端服务时区不一致导致的。MySQL 的DATETIME和TIMESTAMP行为差异很大，如果后端部署在服务器的 UTC 时区，而数据库是CST（中国标准时间），插入和读取时没有做显式时区转换，就会出现用户的评论时间不管早晚，显示起来都多了或者少了 8 小时。

我的习惯是：数据库连接串上强制指定serverTimezone=Asia/Shanghai，后端实体统一处理成带时区的时间对象，接口返回时统一转成 ISO 8601 时间字符串，前端直接渲染不另做转换。时间问题一旦出现，污染范围极大，所有列表的时间全错，而且用户反馈通常是“所有时间都不对”，定位很快，但修复要全链路检查一遍。

6.2 我的生产环境慢查询修复实录

有一次压测时发现，评论列表的接口 TPS 上不去，数据库 CPU 飙到 80%。看了慢查询日志，吓一跳——有两条 SQL 平均耗时超过 900 毫秒，一条是分页LIMIT 100000, 20的深翻页，另一条是递归查询子评论的WITH RECURSIVE（当时还没换成平铺方案）。这两条组合在一起效果爆炸，直接把数据库拖垮。

那次检修之后我把规则定死了：任何评论列表都不允许深分页，统一走游标；任何场景都不允许数据库递归查询，要树形结构就在内存里组装，层级通过应用层限制。修改上线后，同一压测场景下数据库 CPU 降到了 15%，P99 从 800 毫秒降到 90 毫秒。

6.3 上线前必须检查的清单

评论模块上线前，我建议团队过一遍这个检查清单：

• 是否所有评论表、索引、连接串都使用utf8mb4，并且拿 emoji 做了真实测试；
• 是否所有查询语句走 MySQL 慢查询日志验证过，是否还有深翻页和 N+1；
• 是否已配置 CORS 域名白名单，并验证过 OPTIONS 预检不报错；
• 是否已接通幂等、频率限制和 XSS 过滤，三方内容安全服务是否到位；
• 是否已设置缓存 key 的 TTL 和缓存重建防击穿逻辑；
• 是否已与前端约定树形评论数据的结构，并给出完整的 mock 数据；
• 是否在大数据量下测试过分页加载、加载更多、折叠展开的交互性能。

评论模块负责的内容安全、数据一致性、性能带宽，本质上是内容产品是否能健康运转的基础。很多团队把评论模块交给刚入职的新人练手，其实这是最不应该轻视的模块之一——它简直是后端综合能力的试金石：数据建模、接口设计、缓存一致性、安全防护、前后端协作，全都能在这一章里练到。

我做后端这些年，经手过电商、社区、企业应用，几乎每个系统都有评论或者类似评论的 UGC 模块。最深的体会就是，评论模块的“复杂度”不在功能多少，而在边界情况极多。你设计的不是“存一条文字”，而是一整套内容互动规则：谁能发、发什么、发完怎么展示、删了怎么处理、人多了怎么扛、坏人来怎么挡。把这些边界想清楚，评论模块反而能做成整个后端项目里最稳定的一个模块，而且这一章的设计经验，可以平滑迁移到问答、评价、留言板等任何 UGC 场景里。