做知识付费类项目的人都知道“问答系统”四个字不难难的是“付费”两个字。我见过太多网上下载的demo问题列表、回答详情做得很漂亮但钱的事完全没闭合提问者付了钱回答者答完系统只是把问题状态改成“已解决”余额没有变化也没有退款机制后台对账更是一笔糊涂账。本文要拆解的这套Spring Boot付费问答系统内部编号11806是能把“提问冻结资金、回答采纳入账、超时自动退款、提现走人工审核”完整闭环跑通的项目。文章不会只贴代码我会把业务模型怎么设计、表结构为什么这么建、支付回调怎么防重复、定时退款怎么防误杀一步步讲清楚。对于正在做Java毕设、准备接知识付费外包或者想自己做付费问答服务的读者这份拆解应该能节省不少试错时间。1. 付费问答系统的资金流先想清楚钱的闭环再写代码1.1 三个角色、两类账户、三张流水不管功能怎么包装付费问答本质上就是三方参与的担保交易提问者出钱买答案回答者出力赚报酬平台做规则制定方和资金监管方。很多项目做着做着跑偏就是因为只把“问答”当核心把资金链路当附属结果订单、余额、对账全是窟窿。这个系统里我严格区分了三个角色角色核心操作资金身份提问者发问题、支付/冻结、采纳回答付款方回答者答问题、被采纳后收款、发起提现收款方平台管理员内容审核、问题仲裁、提现审核监管方 抽成方和角色对应的是账户体系我分成了用户钱包账户和平台收入账户两者物理上隔离。用户钱包账户记录余额和冻结金额平台账户只记录抽成收入不参与用户间结算。这样每个月对账的时候平台到底挣了多少、用户余额总共多少一条SQL就能查清楚。账目上必须准备三类流水余额变更流水、冻结/解冻流水、提现流水。余额变更流水回答“用户账上钱怎么变多了/变少了”的问题冻结/解冻流水回答“这笔钱现在在哪、处于什么状态”提现流水回答“从平台账户出去的钱到哪里去了”。这三个维度合起来才能支撑起一份让财务放心的对账单。1.2 一次完整交易的状态机11806版本里我把一次问答交易的生命周期画成了一条清晰的链路代码里所有状态流转都只沿着这条链路走提问者发布问题填写悬赏金额系统生成待支付订单订单支付成功或余额冻结成功问题进入“待回答”状态回答者提交答案问题保持“待回答”答案列表逐渐增多提问者采纳某个答案问题进入“已采纳”状态资金解冻并结给回答者如果超过了设定的截止时间仍然没有回答系统自动退款问题进入“已退款”状态如果问题违反平台规则被管理员强制关闭进入“已关闭”状态已冻结资金原路退回。各个环节必须有唯一入口。比如从“待回答”到“已采纳”只能通过提问者主动采纳触发定时任务不能动这个状态从“待回答”到“已退款”只能通过定时退款任务触发用户接口不能直接调用。状态机的这个原则后面帮我挡掉了好几个bug。1.3 为什么必须“冻结资金”而不是“直接打款”这是我被问得最多的问题用户付了钱直接把钱放到回答者账上等采纳后再扣回来不行吗从技术上说可以从业务风险上说非常不建议。有一个很典型的场景提问者发了50元的悬赏问题没有回答者愿意答过了截止时间要退款。如果系统一开始就把钱打给了回答者那退款动作就变成了“从回答者账户里扣钱”回答者可能已经消费掉或者根本不配合平台就得去求用户把钱退回来。而采用冻结机制钱只是被锁定在提问者的可用余额之外回答者还没拿到所有权退款时只需要一解冻一返回即可全程不需要回答者参与。把冻结理解为“资金预授权”就明白了类似住宿时的押金它保证了买卖双方的利益都有缓冲。所以我在设计钱包时专门区分了“可用余额”和“冻结余额”两个字段提问者发问时从可用余额扣减并加上冻结余额回答者被采纳时才把冻结余额真正变成可用余额。2. 表结构设计把业务模型砸进MySQL2.1 核心表清单与字段目标跑通这套业务最少需要六张表。我列一张核心表清单字段只保留关键项实际开发中还可能需要加扩展字段表名关键字段作用userid、nickname、password_hash、role、status用户体系区分提问者/回答者/管理员walletid、user_id、balance、frozen_balance、version钱包账户余额与冻结余额分离questionid、user_id、title、content、price、status、expired_at问题主表含悬赏金额和状态answerid、question_id、user_id、content、is_accepted、created_at答案表一个问题一对多payment_orderid、order_no、question_id、payer_id、amount、status、channel支付订单表对接第三方支付网关wallet_transactionid、user_id、change_amount、balance_after、type、ref_id钱包流水表每一笔余额变动留痕withdrawalid、user_id、amount、status、audit_user_id、audit_time提现申请表走人工审核这里有个很容易忽略的点question表里特意保留了expired_at字段它存储的是“问题截止回答时间”。很多人喜欢在定时任务里用created_at 一定时长实时计算一旦产品调整超时时长历史数据全部需要重算。直接把过期时间作为字段落库任务只需要判断expired_at now()逻辑简单也方便后续人工修改某个问题的截止时间。2.2 金额、状态、版本号三个必须较真的字段细节先说明一个铁律金额一律用DECIMAL(10,2)在Java中对应BigDecimal绝对不用double或float。浮点数的二进制精度问题在涉及钱的时候是非常致命的0.1加0.2可能会变成0.30000000000000004对账时差一分钱都解释不清楚。项目里我见过有人用double存金额报表算出来的总数和明细对不上排查了一个下午才发现是浮点精度问题。状态字段我统一使用tinyint并且要把枚举值写到代码常量类中。question.status的约定是0待支付、1待回答、2已采纳、3已退款、4已关闭。很多新人喜欢直接把状态写成字符串如“WAIT_PAY”查询没什么问题但代码里极易写错大小写和拼写而且占用空间更大。使用tinyint再配合注释数据库里一眼就能看懂。版本号字段version是为乐观锁准备的。钱包余额的更新在并发场景下很容易互相覆盖每行记录带一个自增版本号更新时where version #{oldVersion}如果影响行数为0说明数据已被其他线程修改本次操作必须重试或报错。这个字段在资金表里是必选项。2.3 建表SQL示例直接抄作业的版本问题表和订单表是整个系统的关键我把核心建表SQL放出来大家可以在这个基础上改CREATE TABLE question ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 提问者ID, title varchar(100) NOT NULL, content text, price decimal(10,2) NOT NULL COMMENT 悬赏金额, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1待回答 2已采纳 3已退款 4已关闭, answer_count int NOT NULL DEFAULT 0, expired_at datetime NOT NULL COMMENT 回答截止时间, created_at datetime NOT NULL, updated_at datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_status_expired (status, expired_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE wallet_transaction ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL, change_amount decimal(10,2) NOT NULL COMMENT 负数表示扣减, balance_after decimal(10,2) NOT NULL COMMENT 变动后余额, type tinyint NOT NULL COMMENT 1冻结 2解冻 3回答收入 4提现 5退款, ref_id varchar(64) NOT NULL COMMENT 关联业务单号, created_at datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_ref_type (ref_id, type), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;看到没wallet_transaction上我加了一个唯一约束(ref_id, type)。这个约束的价值会在支付回调重复通知时体现出来——同一笔业务单号只能产生同类型的一条流水数据库层面就把重复挡掉了。这是资金安全的一道保险丝。3. Spring Boot工程结构与接口设计11806版本的分层思路3.1 包结构横着按技术分竖着按业务聚网上很多项目的包结构是纯技术分层一个controller包装所有接口一个service包装所有逻辑。项目小的时候还好一旦牵扯到支付、定时任务、消息通知这些能力service包会膨胀到几千行非常难维护。11806版本采用的是技术分层与业务域聚合的混合结构com.example.qa ├── controller │ ├── QuestionController.java │ ├── AnswerController.java │ ├── PaymentController.java │ └── WalletController.java ├── service │ ├── question │ │ ├── QuestionPublishService.java │ │ ├── QuestionAcceptService.java │ │ └── QuestionExpireService.java │ ├── payment │ │ ├── PaymentCallbackService.java │ │ └── PaymentFacadeService.java │ ├── wallet │ │ ├── WalletFreezeService.java │ │ ├── WalletSettleService.java │ │ └── WalletWithdrawService.java │ └── task │ └── RefundExpiredTask.java ├── mapper ├── entity ├── dto ├── config │ ├── WebConfig.java │ ├── PayConfig.java │ └── TaskConfig.java └── common ├── Result.java ├── BizException.java └── LockKeyBuilder.java这种结构的核心思想是让每个Service只做一件事。比如WalletFreezeService只负责冻结WalletSettleService只负责结算PaymentCallbackService只负责处理支付回调。改冻结逻辑时不会碰结算逻辑排查问题时也能快速定位到类。3.2 核心接口清单与实际参数REST接口我全部使用POST因为涉及资金的操作都应该归类为“动作”而不是“资源查询”。以下是最主要的接口接口说明关键参数POST /api/question/publish发布问题title、content、price、expired_atPOST /api/question/{id}/pay对问题支付/冻结questionIdPOST /api/question/{id}/answer提交回答questionId、contentPOST /api/question/{id}/accept采纳答案questionId、answerIdPOST /api/pay/callback/{channel}第三方支付网关回调由支付网关定义含签名参数POST /api/wallet/withdraw申请提现amountGET /api/question/list分页查询问题page、size、status、keyword发布问题时可以直接传入支付金额后端校验金额必须大于0且不超过用户余额限制。如果用户选择线上支付则生成订单号并返回支付网关跳转参数如果用户余额足够则可以直接走余额冻结通道支付回调接口就不需要参与了。3.3 接口设计上的三个安全细节第一登录态必须统一拦截。我使用拦截器校验Token取出当前登录用户ID后放入请求上下文。所有资金类接口都必须把当前用户ID与业务数据归属人对比防止越权操作。比如说支付接口必须校验问题确实是当前用户发布的回答采纳接口必须校验问题归属人提现接口必须校验提现的是当前用户自己的钱包。第二支付回调接口不能裸奔。第三方支付网关的回调包必须验签最简单的方式是配置好密钥后在回调入口重新计算摘要并比对。同时建议把回调接口限定为只接受支付网关服务器的IP或者至少限制来源域名防止有人伪造回调刷余额。签名校验失败直接返回失败应答不让请求进入业务处理逻辑。第三查询接口做脱敏。用户列表、问题列表都不允许返回手机号、支付订单号、支付网关渠道参数等敏感字段。前端需要的只是问题标题、价格、状态、回答数、回答者昵称这些信息不需要知道内部订单号。4. 核心逻辑的代码落地从发问冻结到结算入账4.1 发问时的余额冻结事务加行锁一步都不能少余额冻结的代码是整个资金链路的起点这里必须做到事务和并发安全兼备。我看过很多伤痕累累的案例所以直接在Mapper层使用SELECT ... FOR UPDATE锁定用户钱包行确保并发场景下只有一个线程能对同一钱包做扣减。Transactional public void publish(QuestionPublishRequest req, Long userId) { // 锁定用户钱包行防止并发修改 Wallet wallet walletMapper.selectByUserIdForUpdate(userId); BigDecimal amount req.getPrice(); if (wallet.getBalance().compareTo(amount) 0) { throw new BizException(余额不足); } // 扣减可用余额增加冻结余额 walletMapper.freezeBalance(wallet.getId(), amount); // 生成冻结流水 walletTransactionService.record(userId, amount.negate(), wallet.getBalance().subtract(amount), WalletTransactionType.FREEZE, orderNo); // 创建问题记录状态置为待回答 Question question new Question(); question.setUserId(userId); question.setTitle(req.getTitle()); question.setContent(req.getContent()); question.setPrice(amount); question.setStatus(QuestionStatus.WAIT_ANSWER); question.setExpiredAt(req.getExpiredAt()); questionMapper.insert(question); }之所以要FOR UPDATE是因为如果两个请求同时读取到余额都是50元又同时执行扣减就可能各自按照50元做运算最后余额变成40元而不是0元等于凭空创造了钱。行锁让同一时刻只有一个线程能读取和修改这行数据虽然性能上有少量开销但资金场景必须这样。4.2 支付回调的幂等处理先查状态再写流水支付回调是另一个极容易踩坑的地方。第三方支付网关为了确保业务方收到通知通常会按一定时间间隔重试多次例如隔5秒、30秒、5分钟各回调一次。如果代码不做幂等同一笔订单会被处理多次用户余额就会多出好几倍。我用的原则非常简单回调处理前先查订单状态只有当订单还是待支付时才执行入账逻辑否则直接返回成功应答给支付网关。PostMapping(/api/pay/callback/{channel}) public String callback(PathVariable String channel, RequestBody MapString, String params) { // 第一步验签 if (!payConfig.get(channel).verifySign(params)) { return fail; } String orderNo params.get(orderNo); PaymentOrder order paymentOrderMapper.selectByOrderNo(orderNo); if (order null) { return fail; } // 第二步幂等判断已支付订单直接返回成功 if (!WAIT_PAY.equals(order.getStatus())) { return success; } // 第三步处理入账内含事务 paymentCallbackService.handlePaid(orderNo, params); return success; }注意这里的handlePaid方法内部必须是事务性的它会做三件事更新订单状态为已支付、把可用余额增加对应金额、生成入账流水。唯一约束(ref_id, type)在这里是第一道防线即使并发到达两个相同回调数据库也只会成功插入一条流水另一个会因唯一索引冲突而回滚。4.3 采纳回答后的分账逻辑提问者采纳答案是资金真正从“冻结”变为“收入”的转折点。这个操作必须是一个大事务任何一步失败都不能让数据处于中间状态。Transactional public void accept(Long questionId, Long answerId, Long userId) { // 校验问题归属人、状态以及答案属于该问题 Question question questionMapper.selectById(questionId); if (!userId.equals(question.getUserId())) { throw new BizException(无权操作); } if (!QuestionStatus.WAIT_ANSWER.equals(question.getStatus())) { throw new BizException(问题状态不允许采纳); } Answer answer answerMapper.selectById(answerId); if (!questionId.equals(answer.getQuestionId())) { throw new BizException(答案不属于该问题); } // 冻结资金解冻并进入平台结算 BigDecimal amount question.getPrice(); BigDecimal platformFee amount.multiply(platformRate).setScale(2, RoundingMode.HALF_UP); BigDecimal answererIncome amount.subtract(platformFee); // 更新问题状态与答案采纳标记 questionMapper.updateStatus(questionId, QuestionStatus.ACCEPTED); answerMapper.updateAccepted(answerId, true); // 回答者余额入账 walletMapper.increaseBalance(answer.getUserId(), answererIncome); walletTransactionService.record(answer.getUserId(), answererIncome, walletMapper.selectByUserId(answer.getUserId()).getBalance(), WalletTransactionType.ANSWER_INCOME, questionId.toString()); // 平台流水记录 platformTransactionService.record(platformFee, questionId.toString()); }平台抽成比例platformRate我放到了配置中心默认值0.2也就是20%。抽成计算会涉及小数截断这里必须显式指定RoundingMode.HALF_UP否则默认的BigDecimal除法在某些情况下会直接抛异常。4.4 超时未回答的自动退款定时任务怎么设计才不误伤超时无人回答的自动退款是系统里最容易“好心办坏事”的功能。如果定时任务扫描条件写得太大很可能会把已经采纳的问题也退款掉。我的定时任务只处理“待回答”且“回答数为0”且“已经超过截止时间”的问题。有回答的问题即便提问者没有及时采纳也不应该触发全额退款因为这会让认真回答的用户血本无归。Component public class RefundExpiredTask { Scheduled(cron 0 */5 * * * ?) public void refundExpiredQuestions() { ListQuestion expiredList questionMapper.selectExpiredWaitAnswer(); for (Question q : expiredList) { try { refundService.refund(q.getId()); } catch (Exception e) { // 单条失败不能影响其他单据记录日志稍后可人工处理 log.error(自动退款失败, questionId{}, q.getId(), e); } } } }对应的Mapper查询语句是这样的SELECT id, user_id, price FROM question WHERE status 1 AND answer_count 0 AND expired_at NOW() LIMIT 100 FOR UPDATE SKIP LOCKED;这里用了FOR UPDATE SKIP LOCKED在任务并发执行时可以避免多条线程处理同一个问题。单机部署时用普通FOR UPDATE也没问题但为了保险我直接把SKIP LOCKED写进去了。退款操作本身复用一个事务方法扣减冻结余额、恢复可用余额、更新问题状态为已退款、写入退款流水。每个环节都必须留痕。5. 实测排坑支付回调、并发扣减和定时任务的三次教训5.1 回调重复通知导致同一笔订单入账两次联调阶段我故意用测试工具向后端发送了两次一模一样的支付成功回调结果用户钱包余额增加了两笔金额。当时代码的问题在于先插入入账流水再更新订单状态。第一次回调时流水插入了状态也更新了第二次回调进来时判断状态已经是已支付本应直接返回但因为我判断的是“先去查流水是否存在不存在才处理”流水又插入了一遍状态更新又被跳过所以入账重复了。这也让我意识到一个原则资金类代码里状态查询和业务处理必须顺序不可颠倒。先查订单状态状态不合法直接返回只有状态合法才进入处理流程。同时数据库唯一约束仍然要保留因为极端并发下两个请求可能在同一个微秒内同时读到旧状态唯一索引是最后的兜底。5.2 并发扣减余额时出现负数压测工具模拟10个线程同时对一个钱包执行“发布问题”和“发起提现”操作时钱包余额出现了负数。问题出在更新语句没有加balance amount条件两个线程同时读到余额10元一个扣了8元另一个扣了3元最终余额变成-1元。修复其实一行SQL就能解决UPDATE wallet SET balance balance - #{amount}, version version 1 WHERE id #{id} AND balance #{amount}如果更新影响行数为0说明余额不足或版本冲突上层抛出异常让事务回滚。这种做法比单纯靠代码里if (balance.compareTo(amount) 0)判断要可靠得多因为判断和更新在数据库层面原子化了。5.3 定时退款任务把已经采纳的问题也退款了这是上线之后被用户投诉才发现的问题。一个用户的问题已经采纳了答案但定时任务扫描时仍然把资金原路退回导致回答者白写了答案。排查过程是这样的定时任务查询条件最开始写的是“已过期且状态小于已退款”我当时想当然地认为过期之后就不会有人再操作了。结果忽略了一个场景提问者可以在问题过期之前正常采纳但因为数据库的expired_at已经设置成过去时间定时任务扫到该问题时状态虽然已不是待回答但我没有对状态做过滤于是把已采纳问题也捞出来了。修复方案就是上面在Mapper里看到的条件status 1 AND answer_count 0 AND expired_at NOW()。只锁定“待回答且一个回答都没有”的问题任何有回答内容的问题都不走自动退款而是留给提问者选择采纳或者等待人工仲裁。这次排坑也让我整理出一个检查清单定时任务条件要以“最小可处理集合”为准不要用排除法写条件排除法一定会漏。5.4 本地没有真实支付网关联调怎么破很多人在本地开发时因为没有支付网关的真实回调能力整个支付流程联调特别痛苦。我在11806版本里加了一个模拟支付开关放在配置文件中pay: mock: enabled: true当开启模拟模式时调用支付接口会直接返回“支付成功”同时由系统模拟回调接口向本地回调地址发送一条通知。这样本地不需要内网穿透也不需要真实支付网关就能完整走通“发布问题 → 支付 → 提交答案 → 采纳 → 余额入账”的全链路。模拟开关同时配了一个页面按钮“模拟支付回调”实际上就是向回调接口发送一条构造好的请求。生产环境必须把开关置为false并且建议在上线脚本里强制校验这个配置项防止有人把模拟支付带上去。5.5 时区问题导致定时任务提前8小时执行最后的坑来自时区。我在本地开发一直正常部署到云服务器后定时退款任务比预期时间提前8小时触发原因是服务器时区是UTCMySQL连接串又没指定时区。排查后把数据库连接串统一加上serverTimezoneAsia/Shanghai并在实体类时间字段上全部使用LocalDateTime避免Java中Date类型在序列化和反序列化时再次产生时区偏差。6. 上线前要看的检查清单以及11806还能往哪延伸6.1 上线前必须处理的合规项和配置项付费问答系统一旦涉及真实资金就不只是“把代码跑起来”这么简单了。我的上线前检查清单至少包含这些第一内容审核机制。问答内容是UGC必须对问题标题、回答内容做敏感词过滤和人工抽审。我接了一个简单关键词过滤工具覆盖率不高但对于明显违规内容能起到拦截作用。同时要保证后台可以下架问题、封禁用户。第二支付与结算规则公示。平台抽成比例、提现手续费、退款规则必须在用户服务条款里写清楚。用户第一次发布问题时弹窗确认避免后续产生纠纷。第三操作审计日志。管理员关闭问题、人工退款、审核提现等敏感操作必须有记录。万一出现资损问题审计日志是排查的第一手证据。第四配置项集中管理。支付密钥、平台抽成比例、问题默认过期时间、退款任务开关等全部放到配置文件中并区分dev、test、prod三套配置。严禁把密钥硬编码在代码里。6.2 从11806版本继续迭代几个性价比很高的功能基础闭环跑通之后我开始规划后续迭代。优先级最高的几个功能是这样排的悬赏加价是最实用的功能提问者可以在问题未被回答时追加金额只需在原问题和原订单上追加一笔订单即可资金冻结逻辑复用推广难度低。然后可以加匿名提问在用户表和问题表上加一个匿名标识回答问题的人不展示提问者信息隐私感更强的产品往往更容易吸引用户。专家认证是提高回答质量的关键后台审核用户上传的资质材料后给用户打上专家标签专家回答的问题在列表排序中权重更高。这个功能配合问题推荐流能显著提高采纳率。实时通知也不能少。11806版本只是定时轮询问题状态回答之后提问者要刷新页面才能看到。后续用WebSocket或SSE推送“有人回答你的问题”配合站内信和邮件通知用户留存体验会有质的提升。6.3 安全与性能方面的保留手段如果这套系统要扛住真实流量还需要加上限流和缓存。分布式部署下我建议用Redis做统一限流对发布问题和提现接口做较严格的频率限制因为这两个接口是资损高发点。热点问题的详情可以缓存到Redis设置短TTL避免高频访问直接打到数据库。数据库层面的读写分离也可以提上日程但事务操作必须保证在主库执行尤其涉及余额和状态更新的方法不能走从库。我的经验是先保证正确性再考虑性能资金类接口绝不能为了一点并发性能牺牲一致性。最后数据库备份策略一定要有。每天全量备份关键业务表每两小时做一次增量备份至少保留七天。线上出过数据回退操作的人都知道备份不是可选操作是救命操作。最后聊点实战感受做完这套系统我的最大体会是一个能收钱的问答系统60%工作量都花在了“异常状态闭环”上。用户不付钱、付了钱不提问、回答了没人采纳、采纳了不提现、提现了不到账这些链路每一个都要有对应的处理逻辑。我在后台故意保留了三个手工处理按钮关闭问题、原路退款、转人工处理。当时觉得是“土办法”实际上线后值班同事靠它们解决了大量自动化处理不了的局面。如果你准备动手做付费问答建议先把状态机画清楚再写第一行代码。