企业官网建设流程全解析

简介：一套面向C#初学者的仿银行系统完整示例，涵盖账户管理、交易记录等常见业务模块，适合课程设计、毕业设计或希望了解WinForms分层结构的开发者。压缩包共44个文件，约257KB，主体为11个C#源文件、6个窗体资源文件及对应资源文件，另含SQL Server数据库文件、解决方案与项目文件、可执行程序及说明文档，目录模块划分清晰，便于对照代码与界面学习。资源已吸引6219人学习下载，实用性与完成度得到一定验证。读者可从中获得一套可直接运行的银行系统雏形，并借助数据访问类、实体类与多个业务窗体理解分层编码思路；同时，数据库文件展示了表结构设计，适合边运行边拆解，作为二次开发、功能扩展或答辩展示的参考。

1. 一套仿银行系统到底在仿什么：别把 CRUD 当成银行核心

做过面试项目的人应该都有同感：网上到处是仿淘宝、仿外卖，真正敢做仿银行系统的很少。原因很简单——银行系统的难点从来不在页面长什么样，而在账务上：一笔钱从一个账户到另一个账户，中间经历了什么、挂了怎么办、怎么证明没记错。一套仿银行系统，仿的不是 UI，是账务处理的那条链路：开户、记账、转账、冻结、解冻、对账、日切。把这套东西用代码实现出来，才算真的入门了企业级后端。

标题里“一套”和“一个”的区别，其实是两种做法：一个工程里的单体模块，还是拆开的多服务调用。我见过不少人拿着网上的培训项目源码，把数据库表一建、接口一跑就以为完事了，结果面试官问“转账中间断了怎么处理”就卡住。本文不依赖任何现成源码包，按我自己做过的方案，把领域模型、核心代码、数据一致性三层拆开讲。

适合谁读？正在做毕业设计或面试项目的后端开发，或者想把账务系统从纯 CRUD 提升到“有点银行意思”的人。不适合谁？想三天搭完交差的人——因为仿银行系统最花时间的不是代码，是设计。

2. 账务模型先行：借贷分录与账户体系怎么设计才不返工

2.1 为什么不能用“余额字段 + 更新语句”直接做账

很多第一次接触账务系统的人，第一反应是建一张account表，里面放个balance字段，转账时UPDATE account SET balance = balance - 100 WHERE id = ?。听上去没错，但这不是银行的做法，甚至不是正规电商账务的做法。

银行的核心账务系统里，余额是“算出来”的，不是“存出来”的。每一笔资金变动都会落一条流水（也叫分录），余额是流水累计的结果。为什么？因为直接改余额，你只有最终状态，没有过程。出了问题，例如多扣了钱、少记了一笔，你根本不知道哪笔错了。而流水是追加写的，只能 insert，不能 update，天然带审计能力。

所以仿银行系统的第一张核心表，不是account，是journal（流水表）。账户表可以保留余额字段做查询加速，但余额必须能被流水重放出来。这个设计叫“事件溯源”的简化版，不需要引入 Event Sourcing 框架，用事务和流水表就能实现。

2.2 账户体系：内部户、外部户、冻结金额三张表的关系

银行账户不像你注册个 App 那么简单。一个银行卡号背后，至少涉及三层：客户（Customer）、账户（Account）、账户余额明细（Balance）。仿银行系统按这套来：

• customer：客户信息表，存姓名、证件号、手机号。
• account：账户表，一个客户可以开多个账户，账户有类型（借记、贷记）。
• account_balance：余额表，记录总余额、可用余额、冻结余额。
• journal：流水表，每笔资金变动一条记录，包含借贷方向、金额、关联账户、业务流水号。

冻结余额这个字段很关键，转账、支付、预授权都会用到。比如你发起一笔转账但还没到账，钱要从可用余额挪到冻结余额，冻结状态解除时再真正扣减。不做冻结字段，就只能靠程序里的状态位硬扛，一旦并发过来就会翻车。

账户类型的枚举建议这样设计：

public enum AccountType { DEBIT(1, "借记账户"), CREDIT(2, "贷记账户"), INTERNAL(3, "内部户"), FLOAT(4, "影子户"); }

参数说明：内部户指银行自己的账户，比如手续费收入户、利息支出户；影子户是虚拟的过渡账户，用于借贷不平衡时的挂账。影子户这个概念是踩坑之后加上的——转账过程中如果收款账户不存在，钱不能丢，只能先挂到影子户，等人工处理。

2.3 借贷记账法：银行系统的“复式记账”最小实现

借贷记账法是银行账务的根基。很多人一听借贷就头大，其实就一条规则：每笔交易至少记两条分录，有借必有贷，借贷必相等。

举个转账例子：A 账户转 100 元给 B 账户。

• 借：A 账户存款 100（负债减少）
• 贷：B 账户存款 100（负债增加）

这里“借”和“贷”在银行科目里的方向含义，做仿银行系统时可以不用深究会计学，直接按业务约定来：借表示资金流出，贷表示资金流入。关键是两条分录的 sum 必须为零。一组分录的借贷是否平衡，就是这笔交易合法的判据。

伪代码如下：

JournalEntry entry = new JournalEntry(); entry.setAccountId(fromAccountId); entry.setDirection(Direction.DEBIT); entry.setAmount(amount); entry.setBusinessNo(businessNo); JournalEntry entry2 = new JournalEntry(); entry2.setAccountId(toAccountId); entry2.setDirection(Direction.CREDIT); entry2.setAmount(amount); entry2.setBusinessNo(businessNo);

这就是最核心的账务抽象。理解这点之后，再看银行核心系统的代码，你会发现所有交易类接口都长得差不多：创建记账请求、检查账户状态和可用余额、生成借贷分录、锁行或乐观锁、批量写流水、更新余额。开户、转账、冻结、解冻、计息，全部复用这套骨架。

2.4 建表 SQL：仿银行系统第一次落地要建哪几张表

直接给可执行的 DDL 核心部分。这里只列最关键的字段，索引和约束后文再讲：

CREATE TABLE `account` ( `id` bigint NOT NULL AUTO_INCREMENT, `account_no` varchar(32) NOT NULL COMMENT '账号，业务唯一', `customer_id` bigint NOT NULL, `account_type` tinyint NOT NULL COMMENT '1借记 2贷记 3内部户 4影子户', `status` tinyint NOT NULL DEFAULT 1 COMMENT '1正常 2冻结 3销户', `currency` varchar(8) NOT NULL DEFAULT 'CNY', `version` int NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', PRIMARY KEY (`id`), UNIQUE KEY `uk_account_no` (`account_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账户表'; CREATE TABLE `account_balance` ( `id` bigint NOT NULL AUTO_INCREMENT, `account_id` bigint NOT NULL, `total_balance` decimal(18,2) NOT NULL DEFAULT 0 COMMENT '总余额', `available_balance` decimal(18,2) NOT NULL DEFAULT 0 COMMENT '可用余额', `frozen_balance` decimal(18,2) NOT NULL DEFAULT 0 COMMENT '冻结余额', PRIMARY KEY (`id`), UNIQUE KEY `uk_account_id` (`account_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='余额表'; CREATE TABLE `journal` ( `id` bigint NOT NULL AUTO_INCREMENT, `journal_no` varchar(64) NOT NULL COMMENT '流水号', `business_no` varchar(64) NOT NULL COMMENT '业务号，幂等键', `account_id` bigint NOT NULL, `direction` tinyint NOT NULL COMMENT '1借 2贷', `amount` decimal(18,2) NOT NULL, `balance_after` decimal(18,2) NOT NULL COMMENT '交易后余额', `status` tinyint NOT NULL DEFAULT 1 COMMENT '1有效 2冲正 3作废', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_journal_no` (`journal_no`), KEY `idx_business_no` (`business_no`), KEY `idx_account_id` (`account_id`, `create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='记账流水表';

注意几个细节。金额字段必须用decimal(18,2)，不能用 float 或 double，这是新手最容易犯的错误。balance_after字段用来做余额连续性校验，后面对账全靠它。business_no必须是业务幂等键，同一笔转账的借、贷分录共享同一个 business_no，避免重复操作。

3. 把核心服务跑起来：开户、转账、幂等键与最小可运行代码

3.1 技术选型：单体优先，别一上来就拆微服务

做仿银行系统，我强烈建议单体架构起步。Spring Boot 3 + MyBatis-Plus + MySQL 就足够了。为什么？因为这个项目的核心价值在账务逻辑，不在服务治理。等你把账务逻辑跑通了，发现某些模块确实有独立部署的诉求，再拆不迟。一上来就 Spring Cloud 全家桶，只会让问题定位变得更难。

如果你的简历上写着“微服务架构”，面试官肯定会问服务间数据一致性怎么保证。单体里的事务还能用@Transactional兜底，拆开后就得引入 Seata 或者手工实现分布式事务。这不是仿银行系统该背的复杂度。

3.2 开户接口：用事务把账户和余额绑在一起

开户的逻辑不复杂，但必须保证“账户创建”和“余额初始化”同时成功或同时失败。代码如下：

@Transactional(rollbackFor = Exception.class) public AccountOpenResponse openAccount(AccountOpenRequest request) { // 1. 校验客户是否存在且状态正常 Customer customer = customerMapper.selectById(request.getCustomerId()); if (customer == null || customer.getStatus() != 1) { throw new BizException("客户不存在或状态不正常"); } // 2. 生成唯一账号 String accountNo = generateAccountNo(request.getAccountType()); // 3. 创建账户 Account account = new Account(); account.setAccountNo(accountNo); account.setCustomerId(request.getCustomerId()); account.setAccountType(request.getAccountType()); account.setStatus(1); accountMapper.insert(account); // 4. 初始化余额 AccountBalance balance = new AccountBalance(); balance.setAccountId(account.getId()); balance.setTotalBalance(BigDecimal.ZERO); balance.setAvailableBalance(BigDecimal.ZERO); balance.setFrozenBalance(BigDecimal.ZERO); balanceMapper.insert(balance); // 5. 返回账号 AccountOpenResponse response = new AccountOpenResponse(); response.setAccountNo(accountNo); return response; }

逻辑说明：@Transactional(rollbackFor = Exception.class)保证第 3 步和第 4 步在同一事务里，只要插入余额表失败，账户创建也会回滚。账号生成用随机数加业务前缀，避免和别人的方案雷同。

参数说明：rollbackFor = Exception.class是必须的。Spring 默认只回滚 RuntimeException，而自定义异常BizException如果继承 Exception 而不设置 rollbackFor，事务不会回滚，你会遇到账户建了但余额没建的诡异问题。这是仿银行系统最常见的坑之一。

3.3 转账接口：锁行、记账、余额更新三件事必须原子

转账是仿银行系统的核心考点，也是网上各种教程最容易做错的地方。我用一个方案：先锁账户行，再检查余额，然后写流水，最后更新余额。全部在一个事务里。

@Transactional(rollbackFor = Exception.class) public TransferResponse transfer(TransferRequest request) { String businessNo = request.getBusinessNo(); // 1. 幂等校验：同一个业务号不能重复处理 int count = journalMapper.countByBusinessNo(businessNo); if (count > 0) { throw new BizException("重复的转账请求"); } // 2. 锁住转出账户行，防止并发扣款 AccountBalance fromBalance = balanceMapper.selectByAccountIdForUpdate(request.getFromAccountId()); if (fromBalance == null) { throw new BizException("转出账户不存在"); } if (fromBalance.getAvailableBalance().compareTo(request.getAmount()) < 0) { throw new BizException("可用余额不足"); } // 3. 锁住转入账户行 AccountBalance toBalance = balanceMapper.selectByAccountIdForUpdate(request.getToAccountId()); if (toBalance == null) { throw new BizException("转入账户不存在"); } // 4. 生成流水号 String journalNo = generateJournalNo(); // 5. 记借：转出账户 + 创建余额快照 JournalEntry debit = new JournalEntry(); debit.setJournalNo(journalNo); debit.setBusinessNo(businessNo); debit.setAccountId(request.getFromAccountId()); debit.setDirection(1); debit.setAmount(request.getAmount()); debit.setBalanceAfter(fromBalance.getAvailableBalance().subtract(request.getAmount())); journalMapper.insert(debit); // 6. 记贷：转入账户 JournalEntry credit = new JournalEntry(); credit.setJournalNo(journalNo); credit.setBusinessNo(businessNo); credit.setAccountId(request.getToAccountId()); credit.setDirection(2); credit.setAmount(request.getAmount()); credit.setBalanceAfter(toBalance.getAvailableBalance().add(request.getAmount())); journalMapper.insert(credit); // 7. 更新余额，先扣减转出方 int updated = balanceMapper.decreaseAvailableBalance(request.getFromAccountId(), request.getAmount()); if (updated != 1) { throw new BizException("余额更新失败，请重试"); } balanceMapper.increaseAvailableBalance(request.getToAccountId(), request.getAmount()); // 8. 返回结果 TransferResponse response = new TransferResponse(); response.setJournalNo(journalNo); response.setBusinessNo(businessNo); response.setStatus("SUCCESS"); return response; }

逻辑说明：第 1 步的幂等校验非常关键，它挡住了重复提交。第 2 步和第 3 步用SELECT ... FOR UPDATE锁行，将并发扣款的竞争变成串行。第 5、6 步写流水，第 7 步更新余额。为什么先写流水再更新余额？因为流水是账务的事实记录，余额只是派生数据。如果余额更新失败，流水还在，可以靠对账找回来。

参数说明：selectByAccountIdForUpdate对应 SQL 里的SELECT * FROM account_balance WHERE account_id = ? FOR UPDATE，它是 MySQL InnoDB 的行锁。要注意锁的顺序：所有转账操作必须按照账户 ID 升序加锁，否则两个互相转账的请求会发生死锁。这是我在实际压测里翻车之后学到的血泪经验。

3.4 幂等键设计：为什么 business_no 比“查重”更可靠

转账接口的幂等，网上常见的错误做法是在转账前先查一下“有没有同样的一笔交易记录”。这个思路没问题，但实现上有 bug：两个并发请求同时查到“没有记录”，然后同时插入，结果就是同一笔转账被执行了两次。

解决方式是让数据库自己拒绝重复数据。journal表上的唯一索引uk_business_no就是干这个的。第一个事务插入成功后，第二个事务的 insert 会被 MySQL 拒绝并抛DuplicateKeyException，程序捕获这个异常直接返回“重复请求”。

改进后的写法：

try { journalMapper.insert(debit); } catch (DuplicateKeyException e) { throw new BizException("重复的转账请求"); }

注意：这里不是用“先查后插”做防御，而是用唯一索引做底线。查重的countByBusinessNo只是提前拦截，减少无效操作，真正防并发靠的是索引。

3.5 初始化数据：让系统跑起来的最少 SQL

建完表之后，先插入一组测试数据，方便后面联调：

-- 客户 INSERT INTO customer (name, id_card, phone) VALUES ('张三', '110101199001011234', '13800000001'); INSERT INTO customer (name, id_card, phone) VALUES ('李四', '110101199002022345', '13800000002'); -- 账户 INSERT INTO account (account_no, customer_id, account_type, status, version) VALUES ('622200000001', 1, 1, 1, 0); INSERT INTO account (account_no, customer_id, account_type, status, version) VALUES ('622200000002', 2, 1, 1, 0); -- 余额 INSERT INTO account_balance (account_id, total_balance, available_balance, frozen_balance) VALUES (1, 10000.00, 10000.00, 0.00); INSERT INTO account_balance (account_id, total_balance, available_balance, frozen_balance) VALUES (2, 5000.00, 5000.00, 0.00);

然后跑一个最简单的转账请求：

{ "businessNo": "BIZ202501010001", "fromAccountId": 1, "toAccountId": 2, "amount": 100.00 }

正常结果：账户 1 可用余额变为 9900.00，账户 2 变为 5100.00，journal 表新增两条记录。

4. 数据一致性靠什么兜底：本地消息表、对账与日切的三层防线

4.1 只靠数据库事务够不够

单体应用跑转账，@Transactional已经能保证强一致。但仿银行系统的价值在于模拟真实环境下的边界情况：比如转账后要发通知、要记账、要同步给风控，这些事如果塞进同一个事务，事务时间会很长，锁的粒度也会变大。

常见的做法是引入本地消息表。事务里只做核心账务操作，然后往message表插一条待发送的消息。事务提交后，异步任务扫描消息表，把消息发出去。如果发失败了，消息还在表里，可以重试。这套方案比 RabbitMQ 的事务消息更容易理解，也更适合单体应用。

4.2 本地消息表：核心事务和后续操作的解耦

表结构如下：

CREATE TABLE `message` ( `id` bigint NOT NULL AUTO_INCREMENT, `business_no` varchar(64) NOT NULL, `event_type` varchar(32) NOT NULL COMMENT '事件类型，如 TRANSFER_DONE', `payload` text NOT NULL COMMENT '消息内容，JSON格式', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待发送 1已发送 2发送失败', `retry_count` int NOT NULL DEFAULT 0, `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_status` (`status`, `create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='本地消息表';

转账事务里新增一步：

// 8. 写入本地消息表，和账务操作同一事务 MessageRecord msg = new MessageRecord(); msg.setBusinessNo(businessNo); msg.setEventType("TRANSFER_DONE"); msg.setPayload("{\"fromAccountId\":1,\"toAccountId\":2,\"amount\":100}"); msg.setStatus(0); messageMapper.insert(msg);

这样消息的写入和账务操作要么一起成功，要么一起失败，不会出现“钱转了但消息没发”的情况。异步发送逻辑很简单：定时扫描 status=0 的记录，尝试发送，成功改状态，失败加重试次数。

什么时候用到这个？比如转账后要通知用户、要同步到征信系统、要触发风控规则。如果这些都算在转账接口的同步链路里，任何一个下游挂了转账就失败，这是不能接受的。

4.3 对账：仿银行系统和普通 CRUD 项目的分水岭

对账是仿银行系统里最能让面试官眼前一亮的设计。原理不复杂：每天固定时间，把系统里的流水和账户余额做一次交叉验证，看账实是否相符。

最简单的对账逻辑包含三步。第一步，校验每个账户的流水连续性：

SELECT account_id, COUNT(*) AS cnt, SUM(CASE WHEN direction = 1 THEN amount ELSE -amount END) AS diff FROM journal WHERE status = 1 GROUP BY account_id HAVING diff != 0;

这一步的目的是查出有借贷不平衡的账户。正常情况每组账户的diff应该是 0。如果不是 0，说明有分录丢了或者方向记错了。

第二步，校验余额表与流水重放结果是否一致：

SELECT b.account_id, b.total_balance, t.calc_balance FROM account_balance b JOIN ( SELECT account_id, SUM(CASE WHEN direction = 1 THEN -amount ELSE amount END) AS calc_balance FROM journal WHERE status = 1 GROUP BY account_id ) t ON b.account_id = t.account_id WHERE b.total_balance != t.calc_balance;

第三步，处理对账发现的差异，生成差错报告。常见差异来源是：手动改库、程序 bug、流水缺失。对账不是自动修复，它的价值是把问题暴露出来。

4.4 日切：仿银行系统里最容易被忽略的时间边界

日切是银行每天的一个关键时间点，一般是凌晨 00:00:00。日切后，上一日的账务封存，不再允许记到上一日。仿银行系统如果涉及“当日交易汇总”“利息按日计息”之类的功能，就需要考虑这个问题。

常见做法是在journal表上再加一个trans_date字段，日切时根据当前时间决定这笔交易算哪一天的。校验规则如下：

if (now.isBefore(cutoffTime)) { transDate = yesterday; } else { transDate = today; }

这个字段不能由前端传，必须后端根据服务器时间生成，否则别人传一个昨天的日期就能篡改账务日期。这是仿银行系统安全设计里容易被忽视的一环。

5. 仿银行系统避坑实录：并发扣款、浮点误差与流水丢失的 5 个现场

5.1 并发扣款变成了负数：余额不足检查形同虚设

现象：用 JMeter 对同一个账户发起 200 个并发转账请求，金额 100 元，账户余额只有 5000 元。跑完后发现账户余额变成了负数。

原因：代码里先查余额、再扣款，虽然用@Transactional包起来了，但两个线程同时读到可用余额 5000，都判断“够扣”，然后各自扣了 100，导致余额少了。

解决：必须用SELECT ... FOR UPDATE把账户余额行锁住，让并发请求串行化。上面的转账代码里已经写了，但要确认 MyBatis 的 XML 里真的加了FOR UPDATE，而不是普通的SELECT。有人以为@Transactional本身就带锁，其实它只保证事务隔离，不锁行。

5.2 金额算错：float 和 double 的精度坑

现象：转账 0.01 元，账户余额从 100.00 元变成 99.99 元，看起来正常。但连续转多笔之后，余额变成 99.99000000000002，再次转账时compareTo判断异常。

原因：Java 的double和 MySQL 的float都存在二进制浮点误差。0.1 在二进制里是无限循环小数，加减多次精度就丢了。

解决：Java 侧一律用BigDecimal，且构造时用new BigDecimal("100.00")或BigDecimal.valueOf(100.00)，不要用new BigDecimal(100.00)，后者已经把浮点误差装进去了。数据库侧金额字段全部使用decimal(18,2)。视图层不要暴露金额字段给前端直接用 number 运算，要求前端按分传递。

5.3 事务没回滚：rollbackFor 配置错了

现象：转账时转入账户不存在，抛了BizException，但日志里看到转出账户的余额已经被扣了，流水也写进去了。

原因：@Transactional默认只回滚RuntimeException和Error。如果你的BizException继承的是Exception，并且没在注解里指定rollbackFor，事务不会回滚。

解决：

@Transactional(rollbackFor = Exception.class)

这是所有写交易系统的人必修的第一课。有人把BizException改成继承RuntimeException也可以，但rollbackFor写明白更稳妥，因为事务里可能有受检异常需要回滚。

5.4 流水号重复：并发下 UUID 的随机性不够用

现象：压测时发现journal_no唯一索引冲突，偶尔有事务直接失败。

原因：用的 UUID 是 Java 默认的UUID.randomUUID()，冲突概率虽然极低，但并发量上来以后也不是不可能。而且项目要求流水号按时间排序，UUID 没有时间语义。

解决：改用“时间戳 + 序列号 + 随机后缀”的格式：

public String generateJournalNo() { String datePart = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMddHHmmssSSS")); String randomPart = String.format("%04d", ThreadLocalRandom.current().nextInt(10000)); return datePart + randomPart; }

这样生成流水号既有时间信息，又有随机性，配合数据库唯一索引兜底，足够应付仿银行系统的量级。

5.5 对账发现流水缺失：日志里却看不到报错

现象：日切对账时发现某个账户余额和流水重算结果差了 50 元，翻日志发现转账接口报了“余额更新失败”，但流水表里有借没有贷。

原因：转账代码里，如果decreaseAvailableBalance更新的行数为 0（比如账户被删了），会抛异常回滚。但假如先写了借记流水、再写贷记流水时数据库连接断了，异常被上层吞掉，则出现只有一条流水的情况。

解决：在数据库层面给journal表的business_no建立唯一索引，并要求同一business_no下的借贷分录必须同时存在——这其实是检查约束，MySQL 不支持跨行约束，所以要在应用层校验：写完借记后立即写贷记，如果贷记写入失败或异常，整个事务回滚。另外，对账脚本要有“单脚分录”检测：

SELECT business_no, SUM(CASE WHEN direction = 1 THEN amount ELSE -amount END) AS diff FROM journal WHERE status = 1 GROUP BY business_no HAVING diff != 0;

这个脚本查的是“同一笔业务下借贷是否平衡”，如果 diff 不为零，说明这笔业务只有一条腿，要立刻介入排查。

6. 给系统做一次体检：从压测脚本到账务平衡校验的收尾技巧

仿银行系统写完，最忌讳的是“能跑就行”。这类系统的评判标准不是接口通不通，而是数据经不经得起检验。我给自己的项目设了三个体检关卡，每一关都能找出实际问题。

第一关是并发扣款压测。用 JMeter 起 100 个线程同时向同一账户转账，跑完后检查最终余额是否正确。工具的配置不复杂：添加线程组、添加 HTTP 请求、设置循环次数即可。观察点有三处：事务失败率、余额是否正确、journal表有没有借贷不均的记录。如果第一关就挂了，说明锁或者幂等设计有问题，后面的都白搭。

第二关是幂等重放测试。拿到一笔成功的转账返回的business_no，原样再提交一次。预期是接口返回“重复请求”，而不是再扣一次钱。这个测试很多人会跳过，但恰恰是面试官最常问的细节。

第三关是账务平衡校验。写一个简单的 SQL 脚本放到定时任务里，每天跑一次前面提到的“分组借贷差为 0”和“余额等于流水累计”两个查询。不要求自动化修复，只要每次有异常能告警，就比 99% 的仿银行项目强了。

最后说一个我的习惯：每次交接这类系统，我一定会在 README 里写清三件事——初始化数据怎么造、跑哪几条 SQL 能验证账务是平的、已知的坑在哪里。不是为了给别人看，是三个月后你自己回来看代码时，会发现当初不写注释的自己有多坑。这套仿银行系统做下来，我发现最难的不是设计表，不是写转账，而是“模拟真实系统的边界条件”时的那种较真。希望这些踩过的坑能帮到你，少熬几个夜。

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