基于Java的互助答疑平台核心设计：从表结构到并发结算

简介：面向高校软件学院课程设计的基于Java的互助答疑平台项目，采用SSM框架与MySQL数据库，以B/S结构构建学生与教师在线提问、回答及后台管理等功能，针对传统远程教育邮件、关键词查询、在线讨论的不足，提供更便捷的师生互动答疑环境。资源共115个文件，压缩包仅311KB，包含28个Java源码与28个class文件、16个XML配置、10个JSP页面，以及数据库SQL脚本、properties配置、JS/CSS和图片素材等，目录结构完整，导入IDE即可对照学习。已有81人学习下载，适合正在完成Java Web课程设计或希望了解SSM整合流程的学生参考。通过源码可掌握用户登录与权限、问答发布、回复处理、后台管理等模块的实现思路，借助SQL脚本快速搭建数据库，是一份可运行、易拓展的完整课设方案。

1. 基于Java的互助答疑平台：不是写个问答功能就完事，难的是让“互助”转起来

一个典型的翻车现场：花了三周用 Spring Boot 撸了个问答系统，提问、回答、分页都齐了，上线后发现根本没人用。提问没人答，回答没人采纳，积分攒了一堆花不出去，最后整个平台成了僵尸社区。问题不在功能，而在“互助”这两个字——它需要一套把提问者、回答者、围观者串起来的激励闭环，而技术上的难点全部集中在这套闭环的可靠性上。

基于Java的互助答疑平台，通俗说就是用 Java 技术栈做一套支持悬赏、采纳、积分结算的问答系统。常见落脚点有校园内部答疑、企业内部技术问答、编程学习社区。适合两类人：一类是 Java 后端初学者想拿一个能写进简历的完整项目，另一类是公司想用最少成本搭内部知识库。下面按我实际做过的方案，从表结构到并发结算，把关键设计、代码和坑一次讲透。

2. 从需求到表结构：先把“互助闭环”拆成数据模型

2.1 功能边界：哪些功能必须做，哪些第一版别碰

互助答疑平台核心是“悬赏—回答—采纳—结算”四步。提问者发布问题时挂出悬赏积分，回答者提交答案，提问者采纳满意的答案后，悬赏积分结算给回答者。如果到期未采纳，积分自动退回。这个闭环之外的辅助功能包括用户信誉分、回答点赞、消息通知、内容审核。

第一版强烈建议砍掉的东西：私信聊天、关注关系、动态流、移动端 App。这些功能单拎出来每个都不小，而且和“互助答疑”这个核心闭环关联很弱。我做第一版时只保留了四个页面：提问页、问题列表页、问题详情页（含回答区）、个人中心（积分明细）。管理后台做一个最简单的审核列表就行，能下架违规问题即可。

积分账本要单独建表，不要只在一个字段上加减。所有积分变动都写流水，这是后面排查账目问题唯一的后悔药。没有流水账，用户说积分少了，你根本说不清是哪笔操作扣的。

2.2 技术选型：为什么是 Spring Boot + MyBatis-Plus + MySQL + Redis

这个项目的技术难点集中在事务一致性、并发结算、热点查询，并没有特别复杂的计算或海量数据，所以选型应该走“成熟、好招人、资料多”的路线。Spring Boot 3.x 或 2.x 都可以，如果你用的是 JDK 17 就上 3.x，JDK 8 就老实待 2.7。ORM 我用 MyBatis-Plus，因为它内置分页插件、逻辑删除、自动填充，能省掉大量样板代码。

MySQL 是主力存储，Redis 用来扛热点数据（热门问题列表、积分排行榜、接口限流计数）。定时任务处理“到期未采纳自动退回”，第一版用 Spring 自带的 @Scheduled 就够了，等真有多个服务实例跑任务时再换 XXL-Job 不迟。搜索引擎除非问题量超过几十万条，否则 MySQL 的 LIKE 查询配合前缀索引完全够用。

这里有一个和热词相关的选型点：近两年很多团队在“行级权限Java”上栽跟头。互助平台天然存在行级权限——提问者只能采纳自己问题的回答，用户只能编辑删除自己的内容。MyBatis-Plus 的拦截器能配数据权限插件，但我的经验是这种简单归属校验直接写在 Service 层更直白，出了问题也好查。

2.3 核心表设计：六张表搭起整个业务骨架

互助答疑平台最少需要六张表，我按依赖顺序列出来。

question 表的 status 字段是整个系统的核心状态机。我一般用四个状态：OPEN（答疑中）、ACCEPTED（已采纳）、EXPIRED（已过期退回）、CLOSED（手动关闭）。accept_answer_id 在采纳时写入，用于记录最终采纳的是哪条回答。

这里面最容易被忽略的是 credit_frozen（冻结积分）。发布问题时不能直接扣减用户余额，而是把悬赏积分从可用余额转入冻结余额。采纳时再从冻结余额转入回答者可用余额。这样设计的原因很直接：问题还在答疑中，这笔积分理论上可能退回给提问者，直接扣掉的话退款操作就要反向加钱，账目容易乱。

CREATE TABLE `question` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL COMMENT '提问人ID', `title` varchar(128) NOT NULL COMMENT '标题', `content` text COMMENT '问题详情', `reward_points` int DEFAULT '0' COMMENT '悬赏积分', `status` tinyint NOT NULL DEFAULT '1' COMMENT '1答疑中 2已采纳 3已过期 4已关闭', `accept_answer_id` bigint DEFAULT NULL COMMENT '采纳的回答ID', `expire_time` datetime NOT NULL COMMENT '悬赏到期时间', `view_count` int DEFAULT '0' COMMENT '浏览量', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_status_expire` (`status`, `expire_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='问题表';

建表时两个索引要特别说明。idx_user_id 支撑“我的提问”列表，idx_status_expire 是给定时任务用的，它要每隔几分钟扫描一次“答疑中且已到期”的问题，没有这个联合索引，定时任务就是一次全表扫描，数据量到十万级就会拖垮库。回答表和积分流水表同理，user_id 和 question_id 都要建单列索引。

积分流水表 credit_account_log 要记录 change_amount 和 balance_after 两个值。balance_after 是这笔流水发生后的账户余额，这个字段是后期对账的关键。光记了变动金额，用户质疑余额不对时没法回溯，有了每次变动后的余额快照，拿着最后一笔流水的 balance_after 和用户表当前余额一比对，问题立刻能定位。

3. 核心流程实现：提问、采纳、自动退回的代码怎么落

3.1 发布问题：扣冻结积分和创建记录必须在一个事务里

发布问题的接口逻辑有三步：校验用户状态和积分余额、创建问题记录、把悬赏积分从可用余额转入冻结余额。这三步要么全成功，要么全失败，必须放在同一个事务里。我见过有人在 Service 里调 this.createQuestion() 再调 anotherService.freezeCredit()，结果第二步失败时问题已经写进去了，这种低级事故本质上是对 Spring 事务边界理解不透。

@Service public class QuestionServiceImpl implements QuestionService { @Transactional(rollbackFor = Exception.class) public QuestionVO createQuestion(QuestionCreateRequest request) { // 1. 校验用户是否存在、是否被封禁 User user = userMapper.selectById(request.getUserId()); if (user == null || user.getStatus() != 1) { throw new BizException("用户不存在或已被禁言"); } // 2. 校验可用积分是否足够（不包含冻结部分） if (user.getCreditBalance() < request.getRewardPoints()) { throw new BizException("可用积分不足"); } // 3. 创建问题记录，状态为答疑中 Question question = new Question(); question.setUserId(user.getId()); question.setTitle(request.getTitle()); question.setContent(request.getContent()); question.setRewardPoints(request.getRewardPoints()); question.setStatus(QuestionStatus.OPEN.getCode()); question.setExpireTime(LocalDateTime.now().plusDays(request.getExpireDays())); questionMapper.insert(question); // 4. 冻结悬赏积分：余额减、冻结加，并写流水 userMapper.freezeCredit(user.getId(), request.getRewardPoints()); creditLogService.log(user.getId(), -request.getRewardPoints(), user.getCreditBalance() - request.getRewardPoints(), "QUESTION_PUBLISH", question.getId()); return QuestionConverter.toVO(question); } }

这段代码有三个关键参数要调。第一个是 @Transactional 的 rollbackFor，默认只回滚 RuntimeException，而自定义 BizException 如果继承的是 Exception，事务不会回滚。第二个是 freezeCredit 的 SQL，它必须带余额足够的前置条件，UPDATE user SET credit_balance = credit_balance - #{points} WHERE id = #{id} AND credit_balance >= #{points}，这样并发场景下数据库层面就挡住了透支。第三个是 expireDays，我一般默认 7 天，最长 30 天，防止有人挂一个永久悬赏把积分永远冻结在自己账户里。

这里顺带说明为什么用 userMapper.freezeCredit() 这种写 SQL 的方式而不是先查再更新。查询再更新是典型的并发陷阱，两个请求同时读到余额 100，各自扣 80，最后余额变成 -60。UPDATE 语句带上条件后由数据库行锁保证原子性，这才是正确姿势。MyBatis-Plus 的乐观锁插件也能做，但 UPDATE 带条件更直接，少一层依赖。

3.2 采纳答案：状态机和并发控制决定会不会“花两份钱”

采纳接口是整个平台最容易出资金事故的地方。提问者点击“采纳”后要做的事：校验问题确实是自己发的、校验问题状态是答疑中、校验回答确实属于这个问题、把问题状态改成已采纳、把冻结积分转给回答者、给回答者发通知。这些操作必须保证并发下只成功一次，否则就会出现一个问题被采纳两次、积分被结算两次的事故。

@Transactional(rollbackFor = Exception.class) public void acceptAnswer(Long questionId, Long answerId, Long operatorId) { // 1. 行级权限校验：只能操作自己的问题 Question question = questionMapper.selectById(questionId); if (question == null || !question.getUserId().equals(operatorId)) { throw new BizException("无权操作该问题"); } // 2. 状态机校验：只有答疑中才能采纳 Answer answer = answerMapper.selectById(answerId); if (answer == null || !answer.getQuestionId().equals(questionId)) { throw new BizException("回答不属于该问题"); } // 3. 条件更新：CAS 思想，防止并发重复采纳 int updated = questionMapper.updateStatusWithCondition(questionId, QuestionStatus.OPEN.getCode(), QuestionStatus.ACCEPTED.getCode(), answerId); if (updated == 0) { throw new BizException("问题状态已变更，请刷新后重试"); } // 4. 结算：冻结转可用 userMapper.settleCredit(question.getUserId(), answer.getUserId(), question.getRewardPoints()); creditLogService.log(answer.getUserId(), question.getRewardPoints(), "ANSWER_ACCEPTED", questionId); // 5. 异步通知，不占用主事务 noticeService.sendAsync(answer.getUserId(), "你的回答已被采纳，获得" + question.getRewardPoints() + "积分"); }

更新问题状态这一步是整段代码的灵魂。UPDATE question SET status = 2, accept_answer_id = #{answerId} WHERE id = #{questionId} AND status = 1，这条语句利用数据库行锁实现 CAS（比较并交换）。两个并发请求同时进来，第一个执行成功后 status 已经变成 2，第二个的 WHERE status = 1 条件匹配不到，影响行数为 0，直接被拦下。这就是 Java 并发题里常说的“怎么保证数据一致性”在真实业务上的落地，比在应用层加 synchronized 可靠得多，因为 synchronized 只对单实例有效，而 SQL 条件更新天然支持多实例部署。

settleCredit 的 SQL 也要注意方向。UPDATE user SET credit_balance = credit_balance + #{points} WHERE id = #{answerUserId}，这是给回答者加余额。提问者侧的冻结余额减少不需要显式扣减，因为冻结余额本身没有单独字段存储总量，它等于所有 OPEN 状态问题的 reward_points 之和，这是一种“按需计算”的冗余设计，减少了更新字段的数量，但要求你保证所有状态流转都正确更新了问题状态，否则对不上账。

3.3 定时任务：到期未采纳的悬赏怎么自动退回

没有定时任务，悬赏到期后会永远冻结在提问者账户里，这是互助平台的信任危机。我用 Spring 的 @Scheduled 实现了每五分钟扫描一次到期问题，核心逻辑是查出所有“答疑中且 expire_time 小于当前时间”的问题，逐条执行关闭和退回。

@Component public class QuestionExpireTask { @Scheduled(cron = "0 */5 * * * *") @Transactional(rollbackFor = Exception.class) public void processExpiredQuestions() { // 1. 批量查出已到期且仍在答疑中的问题，limit 200 防止一次处理太多 List<Question> expiredList = questionMapper.selectExpiredOpenQuestions(200); for (Question question : expiredList) { // 2. 条件更新，和采纳接口同样防止并发 int updated = questionMapper.updateStatusWithCondition(question.getId(), QuestionStatus.OPEN.getCode(), QuestionStatus.EXPIRED.getCode(), null); if (updated == 0) { continue; } // 3. 退回冻结积分：提问者余额加回 userMapper.refundCredit(question.getUserId(), question.getRewardPoints()); creditLogService.log(question.getUserId(), question.getRewardPoints(), "QUESTION_EXPIRED_REFUND", question.getId()); noticeService.sendAsync(question.getUserId(), "你的问题已过期，悬赏" + question.getRewardPoints() + "积分已退回"); } } }

这里有个所有定时任务都会踩的坑：Job 本身要幂等。因为服务重启、任务超时都可能造成同一批数据被扫描两次。解决方案就藏在第 2 步的条件更新里——即使问题已经被上一个任务实例处理过并改为 EXPIRED，新的实例再查出来时 WHERE status = 1 不成立，自然跳过，不会重复退积分。我在代码里特意加了 limit 200，这是给大批量数据留的缓冲，如果一次处理几千条，事务时间过长会拖垮主库。

selectExpiredOpenQuestions 对应的 SQL 要用上 2.3 节说的联合索引。WHERE status = 1 AND expire_time < NOW() ORDER BY expire_time ASC LIMIT 200，这个查询在十万级数据下应该稳定在 50 毫秒以内。如果慢了，大概率是索引没建全，用 EXPLAIN 看一眼执行计划就能定位。

4. 缓存、权限与防刷：热门问题列表和行级校验的实战细节

4.1 热门问题列表的 Redis 缓存：KEY 设计和更新策略哪个更重要

问答平台首页要展示热门问题列表，按回答数或浏览量排序。这属于典型的读多写少热点数据，做缓存收益非常明显。我用 Redis 缓存首页三个列表：最新问题、热门回答、待解答（零回答）。KEY 设计成 help:question:list:new、help:question:list:hot、help:question:list:unanswered，不塞业务前缀是因为这个项目就一套环境，没必要为不存在的多租户场景提前设计。

缓存更新的策略上，我踩过缓存穿透的坑后换成“先写库，再删缓存”的方式。提问接口事务提交后，主动删除对应的列表缓存，下次读取时回源数据库重新构建。为什么不更新缓存而是删除？更新缓存要重新排序，在 Redis 里维护一个有序集合要额外写排序逻辑，删除则只需要一条 DEL 命令，实现成本低得多。

这里还有一个参数值得说：缓存过期时间。热门列表我设 600 秒，待解答列表只能设 60 秒。因为待解答列表对实时性要求高，用户刚回答完，这条问题就不该再出现在“待解答”里，60 秒的过期时间能让数据最多延迟一分钟，体感上可以接受。而真正修改问题状态的操作在 Service 层会主动删缓存，缓存只是兜底。

public PageResult<QuestionVO> listHotQuestions(int page, int size) { String cacheKey = "help:question:list:hot:" + page + ":" + size; // 1. 先查缓存 String cachedJson = redisTemplate.opsForValue().get(cacheKey); if (cachedJson != null) { return JSON.parseObject(cachedJson, new TypeReference<PageResult<QuestionVO>>() {}); } // 2. 缓存未命中，回源数据库 PageResult<QuestionVO> result = questionMapper.selectHotQuestions(page, size); // 3. 回填缓存，设置过期时间防止缓存雪崩 redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(result), 600, TimeUnit.SECONDS); return result; }

这段代码有两个需要调的点。一个是分页参数必须拼进 KEY，否则不同页码共用一份缓存数据，翻页时数据错乱。另一个是过期时间要加随机抖动，比如 600 秒变成 600 到 900 之间的随机值，防止同一时间大批缓存过期后全部回源数据库把 MySQL 打崩。这是标准的缓存雪崩预防手段。

4.2 行级权限校验：为什么不能只靠前端隐藏按钮

互助平台的权限模型不复杂，但很典型。用户只能采纳自己问题的回答，只能删除自己的回答，管理员可以下架任何内容。很多人只在前端根据当前登录用户 ID 判断是否显示“采纳”按钮，这个方案等于把安全交给浏览器，抓包改请求就能越权操作。

正确的做法是在 Service 层做归属校验，而且要用登录态里的用户 ID，不能用前端传来的参数。后端从 Token 或 Session 解析出当前用户 ID，再拿这个 ID 去和资源属主比对。我在 3.2 节的采纳接口里已经体现了这一点：question.getUserId().equals(operatorId) 这个 operatorId 就是服务端从登录态解析的，而不是请求参数里拿的。

@Aspect @Component public class QuestionOwnerCheckAspect { @Before("@annotation(requireOwner) && args(questionId, ..)") public void checkQuestionOwner(Long questionId, RequireOwner requireOwner) { // 从安全上下文获取当前登录用户（ThreadLocal 或 Spring SecurityContext） Long loginUserId = SecurityContextHolder.getUserId(); Question question = questionMapper.selectById(questionId); if (question == null || !question.getUserId().equals(loginUserId)) { throw new PermissionDeniedException("无权操作该问题"); } } }

用 AOP 切面做行级权限校验是清理重复代码的手段。发布问题、采纳回答、关闭问题、删除问题四个接口都需要“校验当前用户是不是问题属主”的逻辑，散落在各个 Service 里就是四份拷贝。抽成切面后，在新的接口方法上加 @RequireOwner 注解就能复用。如果你不想引入 AOP，也可以定义一个 BaseService 基类放 checkOwner 方法。

拦截器还是切面？我倾向于切面，因为拦截器只能拦截 Controller 层，而业务校验最终要落在 Service 层。Controller 层拿到的是请求参数，可能还是字符串 ID，还没有被序列化为 Long，提前在拦截器做校验要么重复转换类型，要么依赖 request.getParameter() 这种和框架耦合的方式，不利于单元测试。

4.3 防刷限流：提问频率和回答频率的双重防线

互助平台有个天然的内容质量问题——低质量提问和灌水回答。除了事后审核，前置限流更省人工。限流维度按用户 ID 控制：每用户 10 分钟内最多发布 3 个问题，60 秒内最多提交 5 条回答。用 Redis 的 INCR + EXPIRE 实现滑动窗口的简化版。

public void checkPostLimit(Long userId, String actionType) { String key = "help:limit:" + actionType + ":" + userId; Long count = redisTemplate.opsForValue().increment(key); if (count == 1) { // 第一次访问，设置过期时间 600 秒 redisTemplate.expire(key, 600, TimeUnit.SECONDS); } int maxCount = "QUESTION".equals(actionType) ? 3 : 5; if (count > maxCount) { throw new BizException("操作太频繁，请稍后再试"); } }

这个写法有个小坑：INCR 和 EXPIRE 不是原子的，极端情况下 INCR 成功后服务崩溃，EXPIRE 没执行，这个 KEY 就成了永不过期的计数器。规避方案是用 Lua 脚本把两步合在一起执行，Spring 的 DefaultRedisScript 支持封装 Lua。实际项目中我用的是后者，代码多几行但杜绝了脏数据。

接口层面再加一层 IP 维度限流兜底，应对羊毛党换号刷问题。但在校园或企业内部场景，同一出口 IP 下可能有一整个宿舍或一整层办公区的人，IP 限流的阈值要放宽，我一般放 5 倍于单用户限额。注意区分场景，别把真实用户误伤了。

5. 避坑指南：互助答疑平台最常见的 4 个翻车现场

5.1 @Transactional 不生效：this 调用导致自调用失效

现象：发布问题时报错后，问题记录没写入，但积分已经扣了，账目不平。排查发现 createQuestion 内部调用了 this.checkAndFreezeCredit()，这个方法上有 @Transactional 注解，但 this 调用是直接走对象内部方法，没有经过 Spring 代理，事务注解完全被忽略。

原因：Spring 的事务功能基于 AOP 动态代理，只有通过代理对象调用方法时，@Transactional 才会被拦截处理。同一个类内部 this.method() 调用不会经过代理。这就是 Java 面试里八股文常问的“Spring 事务失效场景”。

解决：事务方法不要直接内部调用，把加事务的方法拆到另一个 Service 或注入自身的代理对象。另一个替代方案是用 TransactionTemplate，编程式事务写起来更直白，也规避了代理问题。在 3.1 节我给的代码没有这个隐患，因为积分扣减调用的是 userMapper 和 creditLogService，这两个都是代理对象。

5.2 并发采纳导致积分重复结算

现象：线上出现一例“回答者收到双倍积分”，提问者反馈采纳一次但余额少了双份。查看日志发现两个采纳请求间隔不到 100 毫秒，第二个请求进来时事务还没提交，读到的还是旧状态。

原因：应用层先查状态再更新的 check-then-act 模式在高并发下有窗口期。两个请求同时 SELECT 到状态为 OPEN，然后都去 UPDATE，后一个把前一个覆盖。

解决：用 UPDATE 带状态条件做 CAS 更新，也就是 3.2 节的 questionMapper.updateStatusWithCondition。这是从数据库层面加锁，双实例部署也不会出问题。如果你坚持应用层锁，可以用 Redis 分布式锁，但要自己处理锁过期时间，复杂度比 SQL 条件更新高一个量级。这条经验后面再遇到“如何保证数据一致性”的面试题，直接拿这个案例回答最有说服力。

5.3 定时任务重复执行导致积分退回两次

现象：问题过期后用户收到两次“悬赏退回”通知，余额加了两次。查看调度日志发现上一次任务执行超时，运维手动重跑了一次，同一批数据被两个任务实例同时处理。

原因：定时任务没有做幂等保护，同一个问题可以被多次执行退款逻辑。

解决：在定时任务内部做条件更新，UPDATE ... WHERE status = 1 保证只有状态还是“答疑中”的问题才能被处理。如果一个任务已经把问题置为 EXPIRED，另一个任务再处理时 WHERE 条件不命中，自然跳过。这个方案比在数据库里加去重表更经济，但要求每个状态流转都必须是条件更新，凡是 UPDATE 语句没有 WHERE 锁定旧状态的，都是定时任务重复执行的隐患。

5.4 深分页查询越来越慢

现象：问题列表翻到 50 页之后响应时间从 100 毫秒飙升到 5 秒，数据库 CPU 被打满。EXPLAIN 显示去掉 limit 后扫描行数高达几十万。

原因：LIMIT 200000, 20 这种深分页写法，MySQL 要先扫描 20 万行再丢弃前 19 万行，代价极高。这是页面上加页码跳转功能留下的坑。

解决：改为游标分页。WHERE id < #{lastId} ORDER BY id DESC LIMIT 20，用上一页最后一条记录的 ID 作为查询条件，走主键索引扫描 20 行即可。我后来把列表页从页码分页改成了“加载更多”按钮，后端接口接收 lastId 而不是页码，性能问题彻底消失。

6. 验证与进阶：从跑通接口到扛住压力的几个关键动作

项目写完不等于能上线，我习惯按“功能自测 → 压测 → 安全巡检”三步走。功能自测按业务流程串：注册用户 → 发布问题 → 被回答 → 采纳 → 查积分流水，这一串走完主链路就通了。然后重点测异常分支：重复采纳、过期退回、余额不足，这三类异常最考验状态机设计。

压测用 JMeter 或 wrk 打两个核心接口：热门问题列表和发布问题接口。热门列表是读接口，目标 QPS 至少 1000 以上，如果低于这个数，先查 Redis 缓存是否生效，再看慢 SQL。发布问题是写接口，涉及事务和积分扣减，QPS 目标低一个数量级到 100 就行，但响应时间 P99 不能超过 300 毫秒。压测时盯着 MySQL 的连接数和慢查询日志，慢 SQL 出现就要用 EXPLAIN 分析索引。

安全巡检要过一遍行级权限的越权用例。登录用户 A 尝试采纳用户 B 的问题、尝试删除用户 B 的回答，这两个用例在 Service 层必须返回无权限。还有积分相关的参数篡改，比如把 rewardPoints 改成负数，发布问题反而加积分，这种漏洞在 Controller 层就要用 @Min(0) 参数校验拦掉。

最后说一个我自己的教训：上线第一周我盯着功能看，觉得一切正常，直到有人连发 50 条广告问题才发现审核前置有多重要。后来把缓存、限流、敏感词过滤这三件事排在功能 Bug 之前修，平台才真正稳定下来。互助答疑平台这个方向的技术含量不在 CRUD，而在状态机设计、事务边界划分和并发控制，每一层都有性价比很高的优化空间。希望帮到你。

本文还有配套的精品资源，点击获取