评论系统后端架构演进：从单体到高并发分布式全拆解-代码聚汇网

新闻App的评论功能，看起来只是文章底部一个简单的输入框和列表，但真正深入后端去做，你会发现它几乎涵盖了后端开发的所有经典命题：存储设计、缓存一致性、高并发写入、树形结构处理、内容安全，甚至还有AI。我这些年混迹过几家不同规模的新闻资讯团队，从日活几十万的垂直App到千万级体量的平台，评论区后端的基本盘和演进路径其实是非常清晰的。这个标题里的“昨天、今天、明天”，我想换个角度来聊——不只是回顾架构演进，更是一份从单体到分布式、从能用到好用的完整拆解。

先说个反直觉的结论：评论系统之所以难做，根本不在“写一条评论”，而在“读一个列表”和“扛住热点突发”。一个突发热点能让评论量在几分钟内从每分钟几十条飙到几千条，而这种场景恰好是评论区后端最容易雪崩的时候。所以，这篇文章主要围绕评论后端怎么从简单走向健壮、从粗放走向精细来展开，适合正在做资讯类产品后端、或者准备系统学习后端架构的朋友参考。

1. “昨天”的评论后端：单库单表时代的朴素解法

1.1 初代评论模块：一张表、一段接口、一次循环

早期新闻App的评论功能，在整个后端体系里属于“小透明”。当时的架构非常统一：一个Web应用（可能是Spring Boot，也可能是更早的Struts、Servlet），连着一个MySQL数据库，前端页面由服务端直接渲染。评论功能在这个阶段，本质上是“文章的附属品”。

典型的评论表结构大概长这样：

sql复制CREATE TABLE `comment` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `article_id` int(11) NOT NULL COMMENT '文章ID',
  `user_id` int(11) NOT NULL COMMENT '用户ID',
  `content` varchar(2000) NOT NULL COMMENT '评论内容',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  PRIMARY KEY (`id`),
  KEY `idx_article_id` (`article_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评论表';

这段DDL放到今天看问题很多，但在一张表打天下的年代，它就是标准答案。接口也简单，后端提供一个 /api/comment/list?articleId=xxx&page=1&pageSize=20 接口，查询语句就是经典的 WHERE article_id = ? ORDER BY create_time DESC LIMIT ?,?。评论写入口更简单，一条 INSERT 完事，然后顺手 UPDATE article SET comment_count = comment_count + 1 WHERE id = ?，再在内存里把文章缓存更新一下。

在那个阶段，流量模型和今天完全不同。一个新闻App的日活可能只有十几万，一篇文章下的评论撑死几百条，MySQL单机完全扛得住。大家的精力基本都花在“让评论能正常展示”上，没人会去纠结缓存穿透、消息队列、分库分表这些概念。

如果你是从这个阶段开始接触后端的，你会形成一种直觉：评论数据量不大，查询不复杂，怎么搞都行。这个直觉在“昨天”是对的，但到了“今天”就必须得打破。

1.2 为什么平铺评论会被“楼中楼”取代

初代评论系统的另一大特征，是平铺列表，也就是所有评论按时间顺序一列排开。用户想回复某个人，只能带个“@”前缀，回复内容仍然是一条独立的平铺记录。从后端角度看，这种做法最简单，因为查询只需要 ORDER BY create_time，完全不用考虑层级关系。

但产品经理会很快发现，平铺评论的互动效率非常低。用户看到一条评论想回复，回复对象不明确，后续读者看上下文要自己脑补。于是“楼中楼”也就是二级评论结构，成了新闻类App的标配，后端随之迎来第一次复杂度升级。

楼中楼的数据结构是：每一条顶级评论下挂若干回复，回复还可以继续回复（继续三级、四级）。很多团队其实只做到两级：顶级评论 + 二级回复，三级及以上的嵌套一律拍平放在二级列表中。这个产品上的取舍，直接决定了后端的存储设计。

第一版楼中楼的表设计，常见做法是加两个字段：

sql复制ALTER TABLE `comment`
ADD COLUMN `parent_id` int(11) NOT NULL DEFAULT 0 COMMENT '父评论ID，0表示顶级评论',
ADD COLUMN `root_id` int(11) NOT NULL DEFAULT 0 COMMENT '根评论ID，0表示顶级评论';

查询某篇文章的评论列表，变成两步：

查询顶级评论列表（parent_id = 0），按时间或热度排序；
查出这些顶级评论下的所有子评论（root_id IN (顶级评论ID集合)），在内存中完成组装。

这种“先查top级，再批量查子集，内存组装”的模式，即使在数据量增长之后也依然是主流。它比逐条递归查询、N+1查询的方式不知道高到哪里去了——这是评论后端第一个值得记下来的优化思路：不要用循环查库，能用一次IN查询就用一次。

1.3 先发后审到先审后发：关键词过滤的雏形

早期的评论区，审核策略也是“昨天”级别的。大多数团队做的是“先发后审”，也就是用户评论实时展示，后台异步跑一个关键词词表去扫，命中犯规词再删除。这种方案在内容安全上隐患很大，但在当时的技术条件和监管环境下，大家普遍就靠一个敏感词库顶着。

后端实现也很直接：在写入评论前，做一次基于AC自动机或简单Trie树的关键词匹配，命中就拦截或者转人工审核。如果要做“先审后发”，则把评论先塞进一个待审核表，审核通过后再同步到线上评论表。这个阶段的技术含量其实不高，真正的难点在于词库怎么维护、怎么避免误杀、怎么处理谐音和变体——这些在今天依然是内容安全团队的核心痛点。

从“昨天”的视角看，整个评论后端的目标只解决了三个问题：存得住、查得出、审得掉。至于实时性、一致性、容灾性，基本上都在“随缘”状态。这种架构的转折点，一般出现在两个时刻：一个是业务量突然涨到单机MySQL无法承受的程度，另一个是热点事件导致评论洪峰直接打垮应用。

1.4 昨天架构的两大致命伤

第一个致命伤是“评论数与真实评论不一致”。UPDATE article SET comment_count = comment_count + 1 这套逻辑在低并发下没问题，但一旦出现并发，两个线程同时读到 comment_count = 100，各自加1后写回，结果变成了101而不是102。想修正这个，就得把语句改成 SET comment_count = comment_count + 1 这种原子操作，或者引入分布式锁。但即使解决了数值问题，文章缓存和评论计数之间的同步又会产生新的不一致。

第二个致命伤是“热点文章的查询放大”。一条爆款新闻可能带来几万条评论，用户刷评论列表是持续高频的读取操作。如果每次都 COUNT(*) 统计评论总数，或者 LIMIT 100000, 20 去翻深层分页，MySQL的执行计划会直接放弃索引走全表扫。很多开发者在低峰期不会注意到这些性能隐患，等到爆款一出，慢查询日志里全是类似 SELECT * FROM comment WHERE article_id = ? ORDER BY create_time DESC LIMIT 100000, 20 这种句子——这就是“昨天”架构扛不住“今天”流量的经典死法。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. “今天”的评论后端：前后端分离下的高并发架构

2.1 评论服务在业务链路中的位置与分层逻辑

到了“今天”，新闻App几乎是清一色的前后端分离架构。Vue或React负责页面渲染，后端只提供JSON数据接口。评论不再是文章详情页里顺带的一个查询，而是独立的评论微服务，拥有自己的数据库、缓存和部署单元。

一个相对成熟的评论后端，从上到下大概是这么几层：

接入层（Gateway）：负责鉴权、限流、跨域处理，把非法请求挡在最前面。热搜词里反复出现“后端跨域”，这确实是前后端分离后第一个会踩的坑。跨域得在网关层统一配好 Access-Control-Allow-Origin，不要在业务代码里到处加过滤器。
业务服务层：评论的增删改查、点赞、举报、屏蔽、热评榜等核心逻辑都在这层。这一层是无状态的，可以水平扩展，Pod数量直接跟着流量走。
缓存层：Redis负责扛住绝大多数读请求。热评榜用ZSET，评论分页数据用String或Hash，评论计数用String自增。
存储层：MySQL（或TiDB等分布式数据库）存全量数据，Elasticsearch在一些场景下承担评论搜索。数据量大了之后，还会按文章ID或评论ID做分库分表。

这一整套体系，说穿了并不神秘。和“昨天”最大的区别在于：昨天的架构是“先查库，再渲染页面”；今天的架构是“先查缓存，再查库，缓存没有就回源并回填”。读路径走缓存，写路径走异步，最终一致性作为兜底。

2.2 先写缓存还是先写库？评论写入的一致性路径

评论写入是评论后端最核心的链路之一，直接关系到用户的发布体验和数据一致性。假设用户发表一条评论，后端需要做这么几件事：

校验用户登录态和评论内容（长度、敏感词、频率）。
生成评论ID，落库。
更新文章下的评论计数。
把新评论追加进Redis的评论列表缓存。
异步触发内容审核、推送通知、积分奖励等副作用。

这里最刺激的问题是：先更新缓存还是先落库？我的建议是业务状态以数据库为准，缓存可以异步回填，不要强依赖“先写缓存”来保证一致性。

具体落到代码上，写链路可以这样设计：

java复制@Transactional
public Comment createComment(CreateCommentRequest request) {
    // 1. 参数校验和风控前置判断
    Comment comment = new Comment();
    comment.setArticleId(request.getArticleId());
    comment.setUserId(currentUserId());
    comment.setContent(SecurityFilter.filter(request.getContent()));
    comment.setParentId(request.getParentId() == null ? 0 : request.getParentId());
    comment.setRootId(request.getRootId() == null ? 0 : request.getRootId());
    comment.setCreateTime(new Date());
    comment.setStatus(CommentStatus.PUBLISHED);

    // 2. 落库
    commentMapper.insert(comment);

    // 3. 更新文章评论计数（原子操作）
    articleMapper.increaseCommentCount(comment.getArticleId());

    // 4. 发送MQ消息，异步做缓存更新、审核、通知
    mqProducer.send(CommentTopicEnum.CREATE.getTopic(), JSON.toJSONString(comment));

    return comment;
}

这里要注意的是，@Transactional 只保证“评论表和文章计数”这两个写库操作的事务，不保证Redis和MQ这类外部系统的一致。MQ消息发出后，如果消费者失败，可以通过MQ的重试机制来兜底。所谓的“先写库后写缓存”，最终靠MQ把缓存更新成功。如果缓存更新失败，下一次读取时会因缓存缺失回源数据库，再把正确数据回填进Redis——这是经典的Cache Aside模式。

我在实际项目中还遇到过一种更隐蔽的情况：用户发表评论后，刷新页面发现自己的评论排在列表末尾，但别人点赞后热评榜出现了重复条目。这类问题十有八九是缓存更新与榜单排序出现了竞态。解决办法很简单，缓存里不要直接存整个分页列表，而是只存评论ID列表，具体的评论内容走一次批量查库或批量查缓存。这样即使并发更新，最多是ID顺序轻微抖动，数据本身不会错乱。

2.3 树形评论的扁平化存储：一二级评论的读扩散与写扩散

楼中楼结构在“今天”的架构下有了更优雅的解法。目前行业里主流的设计基本是“一次查根评论，批量查子评论，内存组装成树”。这个方案之所以能成立，是因为我们巧妙地做了一个产品上的限制：只做两级评论。

root_id = 0 的评论是顶级评论，用来分页展示，一页20条。
root_id != 0 的评论是子评论，挂在某个 root_id 下面。
parent_id 表示这条子评论回复的是哪条评论，仅用于前端展示“回复 @某某”。

每次拉取评论列表，后端执行两条SQL：

sql复制-- 查顶级评论，按时间倒序
SELECT * FROM comment WHERE article_id = ? AND root_id = 0
ORDER BY id DESC LIMIT ?,?;

-- 查这批顶级评论下的所有子评论，最多取N条
SELECT * FROM comment WHERE root_id IN (?, ?, ?, ...)
ORDER BY id ASC LIMIT ?;

然后把子评论按 root_id 分组，逐条塞进对应的顶级评论下面，最后返回给前端。这个方案读路径微微有些复杂，但写路径非常简单：发根评论时 parent_id = 0，发子评论时带上 root_id 和 parent_id，一条INSERT就完了。

我看过不少团队试图为了省事，把所有层级的评论都做平铺，然后在应用层递归组树。这种做法面对上万条子回复时极易内存爆炸。所以如果产品没有强需求，千万记得把评论层级限制在两级——这是架构自由的前提。

另外，子评论的加载建议采用“按需加载”。顶级评论列表只带前面几条子评论作为预览，用户点击“查看全部回复”再异步加载该 root_id 下的所有子评论。这样既控制了响应体大小，也避免了深层次查询。

2.4 热点新闻下的峰值保护：限流、熔断与降级

评论后端和别的后端服务有一个显著区别：它的流量峰值完全由内容驱动。一条突发新闻可以在几秒内引爆评论区，这对系统设计提出了极高要求。我见过不止一次，热点出来之后评论服务CPU直接被打满，随后拖垮整个App的后端集群。

“今天”这个阶段，评论后端有三板斧：

第一板斧是限流。在网关层按用户维度做一个简单的滑动窗口限流，例如单个用户每分钟最多发5条评论。这个策略不只是为了防刷，也是保护后端写入链路的重要手段。很多“评论发不出去”的故障，其实不是系统挂了，而是限流器把普通用户也拦了。所以限流阈值不能设得太死，需要留出足够的余量。

第二板斧是熔断。评论服务依赖的Redis如果出现超时或者大面积报错，不能无限等地往下游压。用Resilience4j或Sentinel做熔断，连续失败率超过阈值，直接快速失败，返回“评论功能暂不可用，请稍后再试”。这里“快速失败”比“慢慢失败”重要得多——快速失败可以让调用方赶紧降级，而慢慢失败会拖垮整条调用链。

第三板斧是降级。热点来了，很多优雅的功能可以暂时让位。比如热评榜的刷新频率从秒级降到分钟级，评论详情里的“图片评论”暂时不加载，AI智能回复暂停。降级要提前写好规则，不能在故障发生时临时开发。

我一直强调一个观点，热点峰值保护的核心不是“提升性能”，而是“控制流量”。你不可能靠加机器来无限承接峰值，但你可以靠策略把峰值削成一个稳定的、系统能处理的形状。削峰填谷，靠的是MQ异步；限流挡闸，靠的是Sentinel；降级保温，靠的是开关系统。这三样，是现代评论后端比“昨天”的评论后端多出来的全部秘密。

2.5 反垃圾与内容审核：从关键词到行为特征

“今天”的评论后端，内容安全已经是一个专门的子系统。单纯的关键词匹配早就扛不住了。垃圾评论和违规评论的形式包括：包含广告链接、刷屏、辱骂攻击、涉政涉黄，以及用谐音、拆字、图片等方式绕过关键词拦截。

目前行业里比较通用的做法是“多层漏斗”：

第一层：AC自动机匹配精确关键词，拦截或转人工。
第二层：基于NLP模型的语义分析，识别辱骂、广告、垃圾推广意图。常用的策略有文本分类、敏感词向量召回。模型不需要自研，调第三方内容安全API也是常见方案。
第三层：行为特征风控，比如同一IP短时间大量评论、非正常时间段高频评论、注册后立刻大量发评等，都会触发限频或人工审核。

从架构角度看，内容审核链路应该做成异步的。用户评论先落入 comment 表但 status = PENDING，页面展示时过滤掉待审核评论。异步审核通过后，将 status 更新为 PUBLISHED，再触发缓存更新。或者走“先发后审”，用户看到但别人看不到，审核通过再公开展示。两种模式各有取舍，取决于产品的安全等级要求。

这里有个容易被忽略的工程细节：审核服务要设计成可重试的。如果你调第三方审核API，会偶尔遇到超时或返回异常，你就必须有一种机制保证每条评论都会经过审核，而不是审核服务一重启，待审核的评论就丢了。用MQ + 本地消息表（事务消息）可以很好地解决这个问题：评论落库和写本地消息表在同一个事务里，后台任务扫描消息表推送审核。

3. “明天”的评论后端：AI 与实时互动带来的新变量

3.1 AI审核：从“匹配关键词”到“理解语义”

展望未来，评论后端最大的变量是AI。关键词匹配的局限性大家都有体会——谐音、变体、上下文语义，靠规则根本无法穷举。大语言模型（LLM）出现后，“语义理解”从实验室走向了工程化落地。

AI在评论审核上的应用，不只是“判断这条评论是否违规”，而是更细粒度的分析，比如：

识别评论的情绪倾向（正向、负向、中性）；
识别是否包含具体危害行为引导；
识别评论与文章主题是否相关；
识别针对特定群体或个人的攻击性言论。

工程落地上，比较成熟的做法是：把大模型审核作为关键词过滤之后的一道补充环节。所有命中关键词的评论直接转大模型审核，未命中关键词但内容高度疑似垃圾的抽样送检。这样既控制了成本，又明显提升了审核覆盖率。

我还比较看好AI在评论理解侧的价值——对海量评论做内容归纳。新闻App每天产生几十万条评论，编辑不可能逐条阅读。用大模型跑一遍，自动提炼出评论区的主流观点、争议焦点和高频话题，再以“评论摘要”的形式展示在评论区顶部。这个功能在信息效率上的提升，远比单纯“审核垃圾”更有产品想象力。

3.2 评论语义搜索与话题聚类：数据冷启动后的价值挖掘

评论是用户对内容的即时反馈，它的实时性和情感浓度比任何调查问卷都高。但传统搜索只能按关键词匹配，想找“用户对某个政策的不满集中在哪些维度”，用关键词搜索只能搜到只言片语，难以形成整体结论。

向量检索可以解决这个问题。把评论内容用Embedding模型转换为向量，存入向量数据库（Milvus、Qdrant或云上的向量检索服务）。查询时，将“检索条件”转换为向量，通过相似度计算召回相关评论，再进一步聚类。这套体系搭建起来后，产品就能从“展示评论”升级为“理解评论”。

举一个实际场景：编辑发布一篇关于“某个新功能上线”的资讯，想知道用户反馈集中在哪些方面。传统方式是人工翻评论，或者靠关键词搜索“卡顿”“不好用”这种明显负面词。向量检索的方式是直接聚类所有评论的语义，自动生成“体验差”“网络问题”“功能建议”等话题簇，每一类下面附带对应的用户原声。这种能力对新闻媒体做用户洞察至关重要。

3.3 “评论”正在变成“实时讨论”：长连接与推送架构

“明天”的评论不太可能再是静态的“发一条、刷一下”。越来越多新闻App把评论区做成了实时互动场。当甲用户发表评论后，正在看同一篇文章的乙用户能够实时看到新评论冒出来，这就是评论动态推送。

技术上，从“轮询”升级到“长连接”是必然方向。WebSocket或SSE是现阶段最常见的两种方案。评论后端需要维护一个“文章-连接”的映射关系，当有新评论写入时，通过消息推送服务把新评论分发到所有订阅了这篇文章的连接上。

这一阶段的架构会引入一个新组件：推送网关（或叫长连接网关）。它和业务服务分离，独立部署，如果做在线状态维护，还可能需要引入Redis的Hash结构来管理连接与文章的关系。评论业务服务只负责把新评论事件发给MQ，推送网关消费MQ之后转而推给客户端。

一个值得提前设计的点：推送的数据量要“克制”。不能在每条新评论上都把整个评论对象推给客户端，更合理的做法是推送一个“有新评论”的事件，然后让客户端自己决定是否加载。否则直播间评论区那种大流量场景，推送服务会被消息量直接淹没。

3.4 中小团队如何低成本拥抱下一代评论体系

如果你在一个中小团队，资源有限，别一上来就想着搭建完整的AI审核、向量检索、实时推送体系。务实的路径是分三步走：

第一步，把审核从纯关键词升级为“关键词 + 第三方内容安全API”。大多数云厂商都提供了成熟的内容安全接口，接入成本很低，效果比自研关键词强一个量级。这一步花不了多少时间，但安全能力提升非常明显。

第二步，引入向量检索做评论聚类分析。不需要自建Milvus集群，直接用云上的向量检索服务，配合一个现成的Embedding API，就能在几周内做出“评论观点聚合”的功能原型。先跑通一条文章的分析链路，验证产品价值，再考虑规模化。

第三步，再考虑实时互动。做实时讨论之前，先想清楚产品场景是否真的需要。如果只是文章详情页的评论区，WebSocket带来的维护成本可能远大于收益。但如果你正在做体育直播、科技发布会图文直播这一类强互动场景，实时评论推送就是刚需。

中小团队最容易犯的错误是把架构做重。评论体系再怎么演进，核心永远是对业务价值的支撑。技术选型永远要问一句：这个能力上线后，用户真的感受得到吗？

4. 评论系统设计中的四个灵魂问题

4.1 评论写入到底要不要走事务？

很多同学做评论后端时，最纠结的问题就是：评论写入要不要加 @Transactional？答案不是绝对的，要看写入涉及哪些表。

如果一次评论写入只涉及 comment 单表，那事务其实是可有可无的。单条INSERT天然具有原子性，即使没有事务包裹也不会出现“写了半截”的情况。真正需要事务的，是“写入评论 + 更新文章评论计数 + 更新用户评论数”这类跨表操作。

但跨表事务在高并发下是个奢侈品。分布式事务（比如Seata的AT模式）会显著增加复杂度和性能开销，而本地事务只能保证同一个库内的多个操作。如果是微服务架构，评论服务和文章服务拆开了，那评论计数更新本质上是分布式调用，靠本地事务压根管不住。

我个人的取舍标准是：评论写入本身不必强求跨服务事务，把核心一致性收敛在评论服务内部。文章评论计数的更新可以走MQ异步，允许几秒钟的延迟。用户看到“评论数+1”稍慢一点，完全在可接受范围内。真正不能接受的是评论写失败了，页面却提示成功。

4.2 评论数到底是精确值还是近似值？

“评论数显示为25678，实际只有25676”这件事，用户根本感知不到，但很多后端工程师会为此焦虑到掉头发。新闻App的评论区，评论计数是个公开数据，不需要像银行账户那样强一致。它天然就是一个可以容忍“最终一致”的字段。

工程上处理评论计数，标准做法是“Redis计数 + 异步落库”：每产生一条评论，INCR Redis里的计数器；每隔一段时间（或者由定时任务、MQ消费者触发），把Redis里的计数值同步到MySQL。展示侧直接读Redis，不存在写库压力。

热点爆发时，Redis单键的并发 INCR 能扛得非常稳，每秒几十万次毫无压力。但你要注意，不要把评论计数和评论列表缓存放同一个Redis键，否则一次大列表的读取可能阻塞计数更新。计数用独立的Key，列表用另一个Key，各自过期时间都不同，避免互相影响。

4.3 主键为什么用 bigint 而不是 int？

这是热搜词里一个看似基础但很多人真会踩坑的点。初代评论表用 int(11) 做主键，当评论量超过21亿时会直接溢出——听着很远，但对头部新闻App来说，几年真能冲到。更现实的是，分库分表之后，全局唯一ID不能用单个库的自增ID，业界通用的方案是“雪花ID（Snowflake）”，它的数据类型是64位长整型，对应Java的 Long、MySQL的 BIGINT。

雪花ID的组成大致是：1位符号位 + 41位毫秒时间戳 + 10位机器ID + 12位序列号。它能在分布式环境下生成全局唯一且趋势递增的ID，不用依赖中心化的发号器。更重要的是，趋势递增的特性对MySQL的InnoDB索引非常友好，因为B+树写入时不会频繁触发页分裂。

我用雪花ID还有一个实际好处：评论ID自带时间属性，可以在一些场景下直接按ID排序代替 create_time 排序，少维护一个索引。从API返回给前端的评论ID虽然暴露了“某段时间评论量级”这种信息，但对新闻类产品影响不大，可以接受。

4.4 部署跨域与接口规范：前后端分离的第一个坑

看热搜词列表里反复出现“后端跨域”，我得重点说一句：跨域不是一个后端难题，而是一个“配置洁癖”问题。前后端域名不同，浏览器发起AJAX请求时会有CORS限制。解法是在网关层或Web层统一加一个CORS过滤器：

java复制@Configuration
public class CorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedOriginPattern("*");
        config.addAllowedHeader("*");
        config.addAllowedMethod("*");
        config.setAllowCredentials(true);
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return new CorsFilter(source);
    }
}

注意，allowCredentials(true) 时 allowedOrigins 不能配置成 *，必须用 allowedOriginPatterns("*")，这也是很多人配置了半天跨域还是不生效的隐蔽原因。

接口规范这件事，是前后端分离之后最容易扯皮的地方。评论相关的接口建议统一响应体结构：

json复制{
  "code": 0,
  "message": "success",
  "data": {
    "commentId": 123456789,
    "content": "这篇文章写得很实在",
    "likeCount": 12,
    "createTime": 1700000000000
  }
}

code 用整数表示业务状态，0表示成功，非0表示各类错误。message 是给前端直接展示的文案，data 是真正的业务数据。时间戳统一用毫秒级 Long，避免前端做字符串解析时涉及时区问题。

5. 从零搭一套评论后端：可直接抄作业的设计与踩坑清单

5.1 可复用的评论表 DDL 与索引设计

评论表的建设，我推荐一开始就把分库分表的可能性考虑进去，哪怕当前单表。主键用 BIGINT，所有评论都走雪花ID。核心表结构参考如下：

sql复制CREATE TABLE `t_comment` (
  `id` bigint(20) NOT NULL COMMENT '雪花ID',
  `article_id` bigint(20) NOT NULL COMMENT '文章ID',
  `user_id` bigint(20) NOT NULL COMMENT '用户ID',
  `content` varchar(2000) NOT NULL COMMENT '评论内容',
  `parent_id` bigint(20) NOT NULL DEFAULT 0 COMMENT '父评论ID',
  `root_id` bigint(20) NOT NULL DEFAULT 0 COMMENT '根评论ID',
  `like_count` int(11) NOT NULL DEFAULT 0 COMMENT '点赞数',
  `reply_count` int(11) NOT NULL DEFAULT 0 COMMENT '子评论数',
  `status` tinyint(4) NOT NULL DEFAULT 1 COMMENT '状态：0待审，1已发布，2已删除，3违规屏蔽',
  `audit_time` datetime DEFAULT NULL COMMENT '审核时间',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `update_time` datetime NOT NULL COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_article_root_id` (`article_id`, `root_id`, `id`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_create_time` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评论表';

索引设计上有几个关键点：

(article_id, root_id, id) 是核心查询索引，覆盖了“按文章查顶级评论”和“按根评论查子评论”两条主路径。把 id 放进索引末尾，能让排序直接走索引，避免 filesort。
不要单独建 article_id 的索引，它会被联合索引左前缀覆盖。
parent_id 和 root_id 如果都是常用查询条件，可以分别建索引，但很多场景下联合索引更省空间。
不要给 content 建索引，评论内容是长文本，索引无意义且浪费存储。

5.2 常用接口定义与响应体约定

接口设计上，评论系统的核心接口数量其实不多。下面是从实践中归纳的比较稳的一套：

接口	方法	说明
`/api/comment/list`	GET	按文章查顶级评论，分页
`/api/comment/replies`	GET	按root_id查子评论列表
`/api/comment/create`	POST	发布评论（根评论或子评论）
`/api/comment/delete`	POST	删除自己的评论
`/api/comment/like`	POST	点赞/取消点赞
`/api/comment/report`	POST	举报评论
`/api/comment/hot`	GET	获取热评榜

以“查顶级评论”为例，请求参数为 articleId、pageNum、pageSize。响应里的每个顶级评论对象，建议带上 likeCount、replyCount、前三条子评论的摘要（topReplies），方便前端直接渲染，不用再发一次请求。这就是所谓的“接口要面向UI设计”，减少一次交互，用户体验就能好一截。

发布评论接口有一个容易被忽略的点：必须做“幂等”。用户网络不好时可能连点几次提交，后端如果不做幂等，就会出现重复评论。常见的方案是前端生成一个 clientRequestId（UUID），后端在写入时查一下这个ID是否已存在，存在则直接返回原评论。这个机制成本很低，但能避免大量脏数据。

5.3 我踩过的一个经典事故复盘：热点新闻打穿评论服务

分享一个我亲身经历的事故，对正在做评论后端的朋友应该很有参考价值。那是某次突发热点新闻，文章详情页的QPS在几十秒内从2万涨到10万。评论服务的接口RT开始飙升，随后Redis连接数被打满，从库慢查询堆积，最后整个评论服务不可用，连带同一网关下的其他服务一起被拖垮。

事后复盘，根因有四个：

评论列表缓存过期时间设置得太短。文章热度突然暴增，原本冷数据变成了热数据，大量请求同时穿透到数据库。
缓存穿透。热点文章上线后，Redis里没有数据，大量未命中查询直接打到MySQL，导致从库CPU跑满。
没有兜底策略。网关层没有给评论服务配置合理限流，流量一路畅通无阻地打到数据库。
从库故障转移不及时。主从切换靠人工，故障后恢复花了半个小时。

那次事故之后，我们做了四件事：

给热点文章的评论列表缓存加了“热点探测”，一旦某篇文章的写入或读取频率超过阈值，就自动延长缓存过期时间到1小时，并且加一个分布式锁，只允许一个请求回源数据库。
引入本地缓存（Caffeine）作为Redis的二级缓存，热点数据的读取走了应用内存，极大降低Redis压力。
在网关层为评论接口配置链路级限流，超过阈值的请求直接返回“服务器繁忙”，给下游留出喘息空间。
把主从切换做成半自动化的，由监控系统的健康检查触发，不再依赖人工发现。

这些优化做下来，后面再遇到相似量级的热点，评论服务的CPU使用率基本能稳定在55%以下，不再出现雪崩。我想说的核心经验是：评论后端的瓶颈永远不在“单次查询有多快”，而在“异常流量下能不能活着”。你把每个环节的降级预案都准备好，比什么都重要。

6. 给还在起步的团队和开发者的建议

如果你正在负责一个新闻类App，评论后端刚好是起步阶段，我给几个非常接地气的建议。

第一，不要一上来就上微服务。评论功能在日活100万以内时，放在主业务服务里完全够用。你只需要保证评论相关的代码模块边界清晰，后续独立部署时只需要把代码搬出去加个启动类即可。过早拆服务只会增加调用的网络开销和运维成本。

第二，缓存不能省，但也不能什么都往Redis里塞。初期只需要缓存热评榜和热文评论ID列表，冷门文章的评论直接走MySQL。你不需要为所有文章都维护评论缓存，那会浪费大量内存。等有数据支撑你再发现热文画像，精准缓存。

第三，内容审核从第一天就要做。不要觉得“应用刚上线没什么人发评论”，垃圾广告机器人盯上的就是新上线的应用。审核可以从“先发后审 + 关键词过滤”开始，但状态位和审核字段必须提前设计好，否则后面加“先审后发”模式，改表结构会非常痛苦。

第四，日志和监控是最值得花的钱。评论服务至少要有这些监控指标：请求量、响应时间、错误率、缓存命中率、评论写入成功量、审核通过率。有了这些指标，你和“踩坑”之间就隔了一层预警网。很多问题在用户感知到之前，监控器早就报警了。

就聊到这里。评论后端这个方向，技术不算深，但胜在覆盖面广，适合用来系统锻炼后端架构能力。你现在做的每一个取舍，都可能成为下一套大型系统的设计底子。希望这篇经验分享能让你少走几步弯路。

评论系统后端架构演进：从单体到高并发分布式全拆解