SSM任务众包系统实战：数据库设计与并发安全

简介：基于Java与SSM框架实现的任务众包系统毕业设计项目，完整包含前端页面、后端业务、数据库脚本与使用文档，适合计算机相关专业学生用于毕业设计、课程设计或项目启动演示，也适合作为SSM整合开发的进阶学习范例。资源包共1161个文件，压缩后约18.62MB，其中包含Html/CSS/JS静态资源、JSP动态页面、Java源码、SQL脚本、Jar依赖及XML配置等，覆盖从环境配置到功能运行的全套材料，目录结构清晰。系统已通过mac与Windows10/11环境测试，导师指导下完成，答辩评分95分，可作为高分毕设参考。当前已有160人学习下载。除完整可运行代码外，还附有数据库文件和使用文档，可快速理解任务发布、接单、审核、个人中心等核心模块的设计思路，也可基于现有代码进行二次开发与功能扩展。

1. 任务众包系统：SSM 选题里最能讲清楚"钱"的毕业设计

任务众包系统的本质是一个撮合平台：发布者把需求拆成带预算、带截止时间的任务挂出来，接单者通过抢单或竞标获得执行资格，平台负责审核、验收和资金结算。相比学生管理系统这类纯增删改查选题，它多出来的复杂度全在"钱"和"状态"上，而这两块恰恰是 java 面试题里高频考察的事务、并发和设计模式落点。这个标题给出的资源一般是一套可直接导入 IDEA 的 SSM 工程，含 MySQL 建库脚本、使用说明和数据库文件。适合做毕业设计的人照着改，也适合想拿这个项目去面试的人反推表结构和业务代码为什么这么写。

2. SSM 任务众包系统的数据库设计：用户、任务、资金三类表怎么画 ER 图

画 ER 图时实体划分决定了后面所有代码的复杂度。任务众包系统最少需要四张表：用户表、任务表、任务竞标记录表、钱包流水表。把附件、公告这类边缘需求拆成附加表，不放进主流程。主流程的四张表关系是：一个用户发布多个任务，一个任务对应多条竞标记录，一条资金流水必须能反查到是哪个用户、哪个任务触发的。

2.1 角色与权限拆分：一张 sys_user 怎么撑起发布者、接单者、管理员

常见做法是不建三张用户表，而是在同一张用户表里用 role 字段区分身份，因为发布者与接单者只是行为差异，大部分字段如登录名、手机号、实名信息完全共用。管理员同样放在这张表里，只是前端菜单和后端拦截器按 role 做过滤。这样用户注册接口只需要写一套逻辑，登录后拿到的用户对象里多一个角色枚举，代价是每次业务操作都要校验角色，属于典型的"字段冗余换接口简化"。

CREATE TABLE `sys_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(32) NOT NULL, `password` varchar(64) NOT NULL COMMENT '盐值加SHA-256后的密文', `role` tinyint(4) NOT NULL DEFAULT '2' COMMENT '1-发布者 2-接单者 3-管理员', `balance_avail` decimal(12,2) NOT NULL DEFAULT '0.00' COMMENT '可用余额', `balance_frozen` decimal(12,2) NOT NULL DEFAULT '0.00' COMMENT '冻结余额', `real_name` varchar(16) DEFAULT NULL, `phone` varchar(11) DEFAULT NULL, `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

密码字段不用 MD5，因为 MD5 可以被彩虹表直接碰撞。存盐值的做法是系统生成随机串拼到明文后面再哈希，登录时取出盐值重新计算比对。role 用 tinyint 而不是 varchar，是为了让 Java 端用常量类或枚举映射时少一层类型转换，这也是数据库课程设计里老师比较认可的处理方式。余额拆成可用和冻结两个字段，是为了后面做任务预算冻结时不干扰用户正常提现。

2.2 任务状态机与 version 字段：int 状态值比 String 更省心的原因

任务表是整个系统的核心状态载体，任务从发布到完成会经历审核、招募、执行、验收、结算多个环节。状态字段用 int 比 String 更省心，因为状态转移逻辑要用 switch 或 if 判断，int 的等值比较没有字符串大小写问题，也方便在 MyBatis 的 SQL 里直接写status = 1。

CREATE TABLE `task` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `title` varchar(100) NOT NULL, `description` text, `budget` decimal(12,2) NOT NULL, `deadline` datetime NOT NULL, `status` tinyint(4) NOT NULL DEFAULT '0', `publisher_id` bigint(20) NOT NULL, `assignee_id` bigint(20) DEFAULT NULL COMMENT '当前执行者', `version` int(11) NOT NULL DEFAULT '0', `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_status_deadline` (`status`, `deadline`), KEY `idx_publisher` (`publisher_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

version 字段在这里不是简单的乐观锁计数，它还承担了"接单防冲突"的原子判断职责。客户端打开任务详情时拿到当前 version，点击接单时把这个 version 传回来，UPDATE 语句里同时带上status = 1和version = #{version}两个条件，谁先执行成功，另一个人的更新行数就是 0。状态流转见下表，同一时间只有特定状态能跳到下一个状态，非法流转在业务层拦截。

2.3 task_bid 与 wallet_tx 的唯一索引：不重复接单与不重复入账的兜底

业务代码可以加 if 判断防止重复操作，但并发请求下两个事务同时读到"没有记录"就会双双通过校验。数据库唯一索引是最后一道防线，业务判断可以出错，索引不会让两条相同记录落库。task_bid 表用(task_id, bidder_id)做唯一索引，同一个接单者对同一个任务只能有一条竞标记录。

CREATE TABLE `task_bid` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `task_id` bigint(20) NOT NULL, `bidder_id` bigint(20) NOT NULL, `bid_price` decimal(12,2) NOT NULL, `message` varchar(500) DEFAULT NULL COMMENT '竞标留言', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0-待选 1-中标 2-未中', `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_task_bidder` (`task_id`, `bidder_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

资金流水表是保证钱不错乱的核心。每笔资金变动都记一条流水，流水里的 type 区分业务类型，ref_id 记录关联的任务或账单 ID。唯一索引建在(user_id, type, ref_id)上，同一个用户对同一个任务不能产生两条相同类型的流水，这样结算接口即使被重复调用，第二次插入会因为唯一键冲突直接抛异常触发事务回滚。

CREATE TABLE `wallet_tx` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `amount` decimal(12,2) NOT NULL COMMENT '正数入账 负数出账', `type` tinyint(4) NOT NULL COMMENT '1-充值 2-提现 3-发布冻结 4-结算入账 5-取消解冻', `ref_id` bigint(20) NOT NULL COMMENT '关联任务ID', `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_type_ref` (`user_id`, `type`, `ref_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2.4 MyBatis 映射两个细节：驼峰映射与 jdbcType 指定

数据库字段用下划线命名，Java 属性用驼峰命名，MyBatis 的全局配置打开mapUnderscoreToCamelCase后就不用给每个字段写 resultMap 了。这个配置在 applicationContext.xml 里通过 SqlSessionFactoryBean 注入：

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="configuration"> <bean class="org.apache.ibatis.session.Configuration"> <property name="mapUnderscoreToCamelCase" value="true"/> </bean> </property> </bean>

第二个细节是插入数据时给 BigDecimal 和 Date 类型显式指定 jdbcType。MySQL 的 decimal 映射到 Java 的 BigDecimal 没问题，但如果某个值恰好是 null，MyBatis 在预处理语句时可能因为无法推断类型报错。解决方式是在 mapper XML 的 insert 语句里写#{budget,jdbcType=DECIMAL}、#{deadline,jdbcType=TIMESTAMP}，既不影响正常值，又让 null 值能安全绑定。

3. 从零搭建 SSM 工程：web.xml、Spring 容器与 MyBatis 的整合顺序

SSM 的搭建顺序其实就是一个问题：哪些 Bean 放进 Spring 根容器，哪些放进 SpringMVC 子容器，以及 MyBatis 的 SqlSessionFactory 在哪一层创建。顺序理清了，启动报错就能一眼定位。这个工程通常建议按三层拆分：pom 依赖、web 容器配置、Spring 配置。先从依赖说起。

3.1 依赖与版本组合：spring-webmvc、mybatis-spring、druid 各管哪一段

SSM 依赖选型里最容易出问题的是版本冲突。常见的组合是 Spring 5.x、MyBatis 3.5.x、Druid 1.2.x，MySQL 驱动版本需要跟数据库服务端匹配，JDK 用 8 或 11 都可以。这里不推荐把所有 Spring 模块单独引，直接引 spring-webmvc 会连带引入 spring-core、spring-context、spring-beans，再补一个 spring-jdbc 用于事务管理。

<dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> </dependency>

mybatis-spring 是整合的桥梁包，没有它 SqlSessionFactory 无法被 Spring 管理，Mapper 接口也无法自动注入 Service。jackson-databind 负责让 Controller 方法直接返回对象时被序列化成 JSON，前端用 Ajax 接收。Druid 连接池引入后，监控页面和 SQL 统计就能通过一个 Servlet 暴露出来，后面调优会用到。

3.2 web.xml 与 spring-mvc.xml：两个容器的职责边界

web.xml 里注册了 ContextLoaderListener 和 DispatcherServlet，前者创建 Spring 根容器，后者创建 SpringMVC 子容器。根容器放数据源、Service、事务等全局组件，子容器放 Controller、视图解析器、拦截器。子容器可以引用父容器的 Bean，父容器看不到子容器，所以 @Service 必须扫描在 applicationContext.xml 的 component-scan 里，@Controller 放在 spring-mvc.xml 的扫描范围里。如果图省事在 spring-mvc.xml 全包扫描，事务注解会失效，因为事务管理器在父容器中无法对子容器的 Bean 生成增强。

<servlet> <servlet-name>springmvc</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>springmvc</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> <filter> <filter-name>encoding</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> </filter> <filter-mapping> <filter-name>encoding</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

spring-mvc.xml 里的核心配置是注解驱动、扫描 Controller、视图解析器、静态资源和文件上传。文件上传解析器必须在这里配置，因为前端表单提交任务会有附件，POST 请求的 Content-Type 是 multipart/form-data 时，SpringMVC 需要 CommonsMultipartResolver 把请求解析成包含 MultipartFile 的参数对象。

<context:component-scan base-package="com.task.controller"/> <mvc:annotation-driven/> <mvc:resources mapping="/static/**" location="/static/"/> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/views/"/> <property name="suffix" value=".jsp"/> </bean> <bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver"> <property name="maxUploadSize" value="10485760"/> <property name="defaultEncoding" value="UTF-8"/> </bean>

maxUploadSize 设为 10MB 左右，只限制单次请求总大小，不限制单个文件。附件上传后建议落盘到服务器独立目录而不是数据库存 base64，页面展示时通过一个 DownloadController 读取文件流输出，这样可以控制权限和防盗链。

3.3 SqlSessionFactory 与 Mapper 扫描：MyBatis 整合报错的两个高频根因

applicationContext.xml 里配置数据源、SqlSessionFactory、Mapper 扫描和事务管理器。SqlSessionFactoryBean 有两个必配属性：dataSource 和 mapperLocations。mapperLocations 指向 XML 文件目录，"classpath:mapper/*.xml" 会把所有 Mapper 映射文件加载进来。MapperScannerConfigurer 负责扫描接口包，把每个接口动态注册成 Spring Bean，Service 里直接 @Autowired 就能拿到实现，不需要手写实现类。

<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close"> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> <property name="initialSize" value="5"/> <property name="maxActive" value="50"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.task.mapper"/> </bean> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:annotation-driven transaction-manager="transactionManager"/>

报错 "Invalid bound statement (not found)" 的根因九成是 mapper XML 的 namespace 没写成接口全限定名，或者 XML 的 id 与接口方法名不一致。另一个高频报错是 "Failed to configure a DataSource: 'url' attribute is not specified"，这通常发生在 SqlSessionFactoryBean 配置里漏了 dataSource 属性，或者 db.properties 没被加载。检查顺序是：先确认context:property-placeholder存在，再确认数据源 Bean 创建成功，最后看 Mapper XML 的 namespace。

3.4 事务配置与文件上传：任务发布场景的必备设施

事务放 Service 层，用 @Transactional(rollbackFor = Exception.class)。rollbackFor 必须写，因为 Spring 默认只回滚 RuntimeException，不回滚受检异常。任务发布场景里，如果预算冻结成功但任务插入失败，两个操作必须同时回滚，否则用户钱扣了任务没发出去，这个问题在验收演示时非常致命。

上传附件的 Service 里如果同时操作数据库和磁盘文件，事务回滚不会把磁盘文件删掉，常见的折中方案是先传文件到临时目录，数据库操作成功后再移到正式目录；失败时由定时任务清理临时文件。毕业设计做到这一步就已经超出大部分同学的水平了。

4. 任务抢单与众包竞标双模式：发布、接单、验收、结算的完整实现

任务众包系统的业务闭环要覆盖两种典型模式：第一种是抢单模式，任务发布后先到先得；第二种是竞标模式，多个接单者报价，发布者选择中意的人。两种模式共用发布、验收、结算流程，区别只在"确定执行者"这一步。下面的实现把两种模式都写出来，答辩时能主动说出两种流程的差异，信息量会明显不一样。

4.1 任务发布：冻结预算在前，插入任务在后

发布任务的 Service 方法核心逻辑是事务内先扣减可用余额、增加冻结余额，再插入任务记录。发布者余额必须充足，否则直接抛运行时异常让事务回滚。冻结金额的原因是一旦任务进入招募中，发布者不能随意撤销把预算挪走，这保证了接单者完成后一定能拿到钱。

@Service public class TaskService { @Autowired private TaskMapper taskMapper; @Autowired private WalletTxMapper walletTxMapper; @Transactional(rollbackFor = Exception.class) public boolean publish(Task task, Long publisherId) { int frozen = walletTxMapper.freezeBalance(publisherId, task.getBudget()); if (frozen != 1) { throw new IllegalStateException("余额不足，无法发布任务"); } task.setPublisherId(publisherId); task.setStatus(0); task.setVersion(0); return taskMapper.insert(task) == 1; } }

freezeBalance 的 SQL 是一条带条件更新：UPDATE sys_user SET balance_avail = balance_avail - #{amount}, balance_frozen = balance_frozen + #{amount} WHERE id = #{userId} AND balance_avail >= #{amount}。这里用条件判断余额是否充足，不需要先 SELECT 再 UPDATE，避免两个事务同时读到足够余额导致超扣。流水表同步插入一条 type=3 的记录，金额写负数。

4.2 抢单模式：乐观锁 update 返回行数判断胜负

任务被抢的本质是多个请求同时执行同一个 UPDATE，谁影响行数为 1 谁就获得了任务。Service 层先查任务拿到当前版本号，再调用乐观锁更新方法，更新成功的条件写死在 SQL 里，不依赖应用层的 if 判断。

@Transactional(rollbackFor = Exception.class) public boolean accept(Long taskId, Long bidderId) { Task task = taskMapper.selectById(taskId); if (task == null || task.getStatus() != 1) { return false; } int rows = taskMapper.acceptIfAvailable(taskId, bidderId, task.getVersion()); if (rows != 1) { return false; } walletTxMapper.replaceFrozenToFrozen(taskId, task.getPublisherId(), bidderId); return true; }

对应的 Mapper XML 更新语句：

<update id="acceptIfAvailable"> UPDATE task SET assignee_id = #{bidderId}, status = 2, version = version + 1 WHERE id = #{taskId} AND status = 1 AND version = #{version} </update>

这条 UPDATE 同时做了三件事：校验状态、写入执行者、递增版本号。数据库的行锁机制保证同一时间只有一个事务能更新同一行任务记录，第二个事务WHERE条件里status=1已经不成立，影响行数为 0，接单失败。这种方式比 SELECT FOR UPDATE 的悲观锁更轻量，它只在更新瞬间加锁，而任务发布到接单之间的读操作完全并发。

4.3 竞标模式：task_bid 收集报价，award 方法一次原子中标

竞标模式下任务不会被直接抢走，接单者往 task_bid 表插入一条报价记录，发布者看到多个候选后调用 award 方法选择中标者。award 的事务里先更新任务状态为进行中并写入 assignee_id，再更新这条 bid 记录的状态为中标，同时把其他竞标记录标记为未中。

@Transactional(rollbackFor = Exception.class) public boolean award(Long taskId, Long bidId, Long publisherId) { int rows = taskMapper.awardTask(taskId, publisherId, currentVersion); if (rows != 1) { throw new IllegalStateException("任务状态已变化，请刷新后重试"); } taskBidMapper.markWon(bidId); taskBidMapper.markOthersLost(taskId, bidId); return true; }

awardTask 的 UPDATE 同样带乐观锁条件：WHERE id = #{taskId} AND publisher_id = #{publisherId} AND status = 1 AND version = #{version}。这里额外加了 publisher_id 条件，防止非发布者调用接口把任务改成进行中。接口安全在众包系统里很容易被忽略，所有操作类接口都要校验当前登录用户与资源归属人一致，否则用 Postman 改个参数就能把别人的任务标记完成。

4.4 交付验收与超时扫描：状态流转与补偿机制

接单者完成工作后在任务详情页提交交付说明，任务状态从进行中变成待验收。发布者确认满意后调用 complete 方法，事务里同时完成状态更新和资金结算。资金结算拆成两笔流水：一笔给接单者入账，一笔把发布者的冻结余额清零。两笔都必须插入成功，任何一笔失败整个事务回滚。

@Transactional(rollbackFor = Exception.class) public boolean complete(Long taskId, Long publisherId) { int rows = taskMapper.completeTask(taskId, publisherId); if (rows != 1) { throw new IllegalStateException("仅待验收状态且发布者本人可完成操作"); } Task task = taskMapper.selectById(taskId); walletTxMapper.settleIncome(task.getAssigneeId(), task.getBudget(), taskId); walletTxMapper.settleRelease(publisherId, task.getBudget(), taskId); return true; }

wallet_tx 表上的(user_id, type, ref_id)唯一索引在这里起到幂等作用。如果 complete 接口被前端重复提交，第二次事务插入相同流水时主键不冲突但唯一索引冲突，抛出 DuplicateKeyException 后事务回滚，任务状态不会从已完成改成已完成，钱不会二次入账。超时补偿用 Spring 定时任务扫描，每五分钟把超过 deadline 且处于招募中或进行中的任务改成超时状态，冻结余额自动退回发布者可用余额。

@Component public class TaskTimeoutScanner { @Autowired private TaskMapper taskMapper; @Scheduled(cron = "0 */5 * * * ?") public void timeout() { List<Task> tasks = taskMapper.selectTimeoutTasks(); for (Task task : tasks) { taskMapper.markTimeout(task.getId()); walletTxMapper.unfreeze(task.getPublisherId(), task.getBudget(), task.getId()); } } }

cron 表达式0 */5 * * * ?表示每隔 5 分钟执行一次，秒位固定为 0。扫描时用deadline < NOW() AND status IN (1, 2)作为查询条件，一次查出所有超时任务，逐条处理。数据库时间如果存的是北京时间，而服务器时区是 UTC，NOW() 会有 8 小时偏差，建数据源连接时要把serverTimezone=Asia/Shanghai写进 JDBC URL，否则超时判断在凌晨会出错。

5. 参数调优与答辩准备：SSM 项目从"能跑"到"能讲清楚"

5.1 Druid 连接池的三个参数怎么给

数据源参数是答辩里最容易展开的技术话题。项目能跑默认参数就行，但要回答"为什么这样配置"就需要理解参数语义。initialSize 是启动时预创建的连接数，minIdle 是空闲时保留的底线，maxActive 是峰值上限。任务众包这类读多写少的项目，初始 5、上限 50 够用，maxWait 设为 60000 毫秒表示等不到连接时抛出异常而不是无限阻塞。validationQuery 配SELECT 1，testWhileIdle 在连接空闲时做探活，防止 MySQL 的 wait_timeout 把连接断开后应用还在使用。

5.2 慢 SQL 日志：打开与定位

预算结算是高频写操作，验收演示出问题反而能变成亮点。Linux 服务器上执行下面命令开启 MySQL 慢查询日志，超过 2 秒的 SQL 会记录到指定文件，然后通过mysqldumpslow聚合分析：

SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

分析时重点看两类 SQL：一类是 task 表按 status 和 deadline 的查询，索引建在(status, deadline)上可以覆盖超时扫描和任务列表两个场景；另一类是 wallet_tx 的插入，如果并发量大，唯一索引冲突需要看是正常幂等冲突还是业务 bug，日志里出现 DuplicateKeyException 且业务能正常返回失败提示，说明幂等生效了。

5.3 答辩自我介绍的技术话术与高频追问

简历和答辩介绍里不要写"实现了用户管理、任务管理"这类流水账，要按技术点组织。用三句话概括这个项目：基于 SSM 实现多人任务撮合，任务生命周期用状态机管理，接单与结算环节通过乐观锁和唯一索引保证并发安全与资金幂等。这三句话分别对应状态设计、并发控制、事务边界，每一句都能被面试官深入追问。

高频追问第一类是并发问题：同一任务两人同时接单会怎样？回答里突出 WHERE 条件带 status 和 version 的原子 UPDATE，以及数据库行锁在底层的作用。第二类是资金一致性问题：重复调用结算怎么办？回答里指出 wallet_tx 的唯一索引和事务回滚。第三类是状态机扩展性：如果要支持"申诉仲裁"状态怎么加？给出加入状态 7 并只允许从待验收转移的方案。把这三个追问提前在本地用 Postman 模拟并发场景跑通，验收和面试的状态会完全不同。

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