企业官网建设流程全解析

1. 为什么银行柜台管理系统成了全栈练手题的“经典款”

每年到了课程设计和毕业设计的季节，我都能在技术社区里看到大量类似的需求帖子：基于springboot + vue的银行柜台管理系统，附带源码、数据库脚本和项目文档。乍看之下，这题目确实不够炫酷，没有AI、没有大数据、没有区块链。但你要是真把这个系统完完整整做下来、跑起来、讲清楚，它在全栈开发能力上的训练价值，一点不比那些花哨题目低。

银行柜台管理系统，本质上是一个“账务+权限+高事务强度”的典型业务系统。它不像电商商城那样堆功能模块，也不像论坛博客那样玩花样。它的核心是对钱的流转做严格记录，对操作者做严格身份控制，对每一笔业务留痕可追溯。这个领域对正确性的要求极高，你的数据模型稍微设计得差一点，事务边界稍微划得模糊一点，后台一跑对账流程就会暴露问题。所以，把它作为springboot + vue的练习载体，能非常扎实地锻炼数据库建模、并发控制、权限设计、状态管理等基本功。

另外，这个题目的交付物天然要求“源码+数据库+文档”三件套。这意味着你不只要让页面能点、接口能调，还要拿出完整的数据库初始化脚本，还要写出从需求分析到详细设计的说明文档。这其实很贴近真实项目交付的状态。很多学生项目代码能跑，但数据库脚本写得一塌糊涂，文档更是东拼西凑。如果你能把这个项目完整交付，你在面试或者答辩时就有话可讲：我设计的表结构能支撑什么业务、我的并发方案解决什么问题、我的文档怎么组织。

我把这个项目涉及的技术栈整理了一遍，你可以直观感受一下它的覆盖面：

下面我就以一个亲自带着学生做过这类系统的从业者身份，把整个项目的破题思路、数据库设计、后端实现、前端落地、安全审计以及答辩文档的组织方式，完整地拆一遍。你不用照着我的代码抄，但照着这个思路想，至少能少掉一半头发。

2. 从一笔存款业务出发，拆解系统的业务边界与模块划分

2.1 柜台业务流程决定数据流

很多人拿到这类题目，第一反应是去看别人怎么分模块，然后照猫画虎地建一个“用户管理”“客户管理”“账户管理”“交易管理”。这样分没问题，但如果你不理解业务流转的本质，做出来的系统往往只是“能增删改查的壳子”。真正决定这个系统数据流的，是柜台上真实的业务操作顺序。

我们拿最简单的“存款”来说。客户走进银行，柜员先核实客户身份，调出客户信息和账户列表，然后发起存款操作，选择账户、输入金额，系统校验账户状态是否正常、金额是否合法，然后执行记账：在账户余额上累加金额，同时生成一条交易流水，最后柜员操作结束，系统记录本次操作日志。这短短一分钟的业务背后，牵扯到客户表、账户表、流水表、操作日志表，还牵扯到金额更新的原子性。如果你不了解这个业务顺序，就会把流水表和账户表做成两个互不关联的独立功能，对账的时候两头对不上。

所以第一步，应该先把柜台的核心业务流转梳理出来。一套完整的柜台管理系统，业务闭环大致是这样的：

• 客户开户：录入客户基本信息，建立客户档案，同时开立账户并生成账户号
• 存取款：在账户上执行金额变动，校验账户状态和余额，生成交易流水
• 转账汇款：两个账户之间资金的原子性划转，涉及扣款账户和收款账户两条更新
• 账户查询：按客户、账号、时间段查询账户信息和交易明细
• 挂失与解挂：对银行卡或账户进行风险状态标记
• 销户：校验账户余额为零且无未完结业务后，关闭账户

这就是整个系统的“主流程”。所有页面、接口、数据表，都是为这条主流程服务的。把这6个环节吃透，模块划分就不会乱。

2.2 角色与权限的边界

银行柜台系统不像普通后台管理系统，所有人用一个管理员账号登进去随便点。真实柜面系统的角色边界非常严格，这也是它作为课程设计/毕业设计的加分项。我在系统里默认设计四类角色：

• 系统管理员：维护员工账号、分配角色、查看系统日志
• 柜员：办理日常存取款、转账、开户等业务，操作自己当班的流水
• 主管：审批异常业务、处理柜员差错、查看网点日报
• 客户经理：查询客户信息、维护客户关系，不能直接操作资金

这四类角色各管一块，互不越权。你会发现，如果只用用户表加一个admin字段，这套业务是根本撑不住的。角色和权限必须独立建模。哪怕你项目只做两个角色，也应该预留扩展空间。这就是后面讲到的RBAC模型落地的基础。

2.3 功能模块清单：那些“不起眼但必答”的菜单

除了一眼就能想到的基础模块，我强烈建议你把下面这几个容易被忽略的功能做进去，它们往往就是你答辩时的“技术亮点”：

• 日终结算：统计当日各柜员业务量、存取款总额、转账总额，输出日报表
• 操作日志查询：记录谁在什么时间执行了什么操作，含IP、操作类型、业务单号
• 账户状态管理：正常、挂失、冻结、销户四种状态的流转
• 身份证号、手机号等敏感信息脱敏展示

这些功能看起来都是“小功能”，但每一个背后都有实打实的技术点：日终结算涉及聚合查询和事务；操作日志涉及AOP或拦截器设计；账户状态管理涉及状态机思想；脱敏涉及数据呈现层的处理。把这些做了，你的系统就不只是一个“CRUD拼接体”。

3. 数据库设计才是这类系统的“真香区”

3.1 表结构主干的六张核心表

数据库是账务系统的命根子。这句话我在带项目的时候会重复很多遍。银行柜台系统的表不需要特别多，合理范围在12到18张表之间，但每张表的设计都要禁得起推敲。我给出一套经过验证的核心表结构，你可以在此基础上扩展：

很多初学者对“用户表”和“客户表”分不清楚，直接在用户表里塞上身份证号、手机号、地址，这就把两个领域混淆了。系统用户是“操作系统的人”，客户是“来银行办业务的人”，两者必须拆开。sys_user里存柜员账号和密码，biz_customer里存客户档案，中间关系通过业务操作关联。这个拆分的道理，放在任何一个企业管理里都一样：内部员工和外部客户是两类实体，不能共表。

3.2 账户表与流水表的微妙关系

账户表和流水表是整个设计的核心关系对。很多初学者把交易流水设计成“跟在账户后面的一条小尾巴”，账户余额更新了，就插一条流水，完事。这个思路做简单Demo可以，做银行柜台系统不够。真正核心的关系应该是：交易流水是账务变动的唯一凭据，账户余额是流水累计的结果。也就是说，流水表是业务事实，账户表是当前状态。这么设计带来的直接好处是对账容易——统计某账户的流水金额，汇总结果应该等于余额变动差额。如果余额和流水不一致，一定哪里出了问题。

要实现这种设计，关键字段必须完整。交易流水表不能只有金额和类型。我的建议是至少要包含：交易流水号、账户号、交易类型、交易金额、交易前余额、交易后余额、柜员ID、交易时间、业务摘要、状态字段。尤其是“交易前余额”和“交易后余额”这两个字段，很多人的表里根本没有。没有它们，出错了连“从哪变到哪”都查不了，审计更无从谈起。加上它们就是一条完整审计链路。

另外，账户号和流水号不要用自增ID。账务系统对外展示的编号必须是业务号，建议用时间戳+随机数生成，或者用雪花算法，保证唯一且不带业务含义。金额字段一律用DECIMAL类型，比如DECIMAL(18,2)，绝对不要用float和double。浮点数在金额计算上的精度问题，是账务系统最经典的坑之一。你会看到某个账户余额长了小数点后第7位的尾巴，怎么也消不掉。

3.3 事务、锁与并发扣款

银行柜台系统的核心并发场景是：多个柜员同时操作同一账户怎么办？比如账户余额1000元，柜员A正做一笔800元的取款在途，柜员B同时发起一笔500元转账。如果没有并发控制，两人都读到余额1000元，各自减去自己的金额，最后余额变成500或200，造成严重的资金错误。

解决这个问题有两条路。第一条是悲观锁：在查询账户记录时使用SELECT ... FOR UPDATE，直接把账户行锁住，等事务提交后再释放。这个方案逻辑最严谨，但并发量一大就会出现锁等待。第二条是乐观锁：在账户表设计一个version字段，更新时带上WHERE version = 当前版本号，如果更新影响行数为0，说明数据被其他人改过了，需要重试或报错。对于柜台系统这种低并发、高一致性的场景，我在实际项目中更推荐乐观锁，实现简单，也不会长期占用数据库连接。

Spring Boot中事务边界的控制也值得专门说。你在业务实现类上加了@Transactional，不等于事务就一定按你预想的范围工作。有一个非常隐蔽的坑：同类内部调用事务方法会失效。比如在Controller调用Service的doDeposit()方法，doDeposit()里调用了this.updateBalance()，后者加了@Transactional，这个注解实际不会生效，Spring AOP代理默认只拦截外部调用。解决办法有两种：把内部方法拆分到另一个Bean里，或者使用编程式事务。这个坑，我在带学生项目时至少遇到三四个同学踩过。

4. Spring Boot 后端落地：那些“写过才知道”的细节

4.1 项目结构与技术选型

后端部分，springboot + MyBatis-Plus + Redis + MySQL是这类项目最稳妥的组合，我并不建议一上来就上Spring Cloud那套微服务全家桶，一个柜台管理系统的业务量级根本用不上分布式那一堆东西。MyBatis-Plus提供的代码生成器能让你把实体类、Mapper、Service、Controller等基础代码一次性生成出来，省去大量样板代码，把精力集中在业务逻辑上。Redis则用来做验证码存储、登录Token黑名单等场景。

项目结构我建议按业务模块分包，而不是按技术层分包。也就是说，把customer、account、transaction、system这几个业务包放平级目录，每个包下放controller、service、mapper、domain。这样做的好处是，后续维护某一业务时不用在controller包和service包之间来回跳。尤其多人协作或者后面要写设计文档时，业务包结构比技术层结构好讲得多。

4.2 登录鉴权与拦截器设计：从Session到JWT

登录鉴权是这类系统的门面。传统Session方案在前后端不分离时代很常见，但springboot + vue做前后端分离后，最舒服的方案是JWT。用户登录成功后，后端签发一个token返回前端，前端把token存起来，每次请求在请求头里带上Authorization。后端通过拦截器解析token，校验身份，放行请求。

就是设计一个HandlerInterceptor，在preHandle方法里做token校验，把通过校验的用户信息塞到ThreadLocal或Request属性中，方便后续业务方法拿当前操作人。需要注意两个细节：

• 拦截器要放行登录接口和静态资源，只拦截需要认证的请求
• token过期要有统一返回结构，前端收到401之后跳转登录页

我在实际项目里还会给系统加上“同一账号单点登录”的简化策略：登录时把当前用户信息写入Redis，设置有效期，如果该账号在其他地方登录，就把旧token加入黑名单。当然，这属于锦上添花的功能，对毕设项目来说，有没有都不影响主线，但做了你就能在答辩时多讲一句“我如何防止越权和重复登录”。

4.3 交易接口的“三件套”写法：校验、幂等、原子性

交易类接口是整个系统最容易写坏的地方，也是最值得你花时间打磨的。我用最典型的“取款”业务来拆解一个标准写法，你后面做存款、转账都能复用这个套路。

第一步是参数校验。账户号不能为空、金额大于0、金额不能超过单笔限额，这些在Controller层可以用@Valid做基础校验，但业务层还要再校验一次业务规则，比如账户状态是否为正常、账户是否为销户状态。记住一个原则：Controller只做入参格式校验，业务合法性判断必须放在Service里。

第二步是幂等性控制。一个很常见的问题：前端网络抖动，用户点了两次取款按钮，后端收到两次相同请求，结果扣了两次钱。虽然前台可以用防抖来处理，但后端必须兜底。兜底方案是在交易表上增加“业务单号唯一约束”，同一个业务单号只能插入一条流水。客户端生成单号，后端插入前查重或者直接依赖数据库唯一索引，插入冲突时捕获异常，返回“重复提交”。

第三步是原子性操作。取款的Service方法必须是事务性的：校验通过，扣减账户余额，生成交易流水，更新操作日志，这四个动作要么全部成功，要么全部回滚。我习惯的做法是使用乐观锁更新余额，然后插入流水，最后写日志。更新余额时使用UPDATE account SET balance = balance - #{amount}, version = version+1 WHERE id = #{id} AND version = #{version}，这样既能避免并发问题，又让SQL保持原子性。

我见过不少交易代码是先查一次余额，在Java代码里判断够不够扣，然后更新。这种先查后改的写法在高并发下是不成立的，必须把校验放到SQL层面或者使用锁。虽然柜台系统的并发量远达不到电商秒杀那种级别，但从写代码的习惯上，我建议你从一开始就按严谨的方式写。答辩时老师最可能问的恰恰就是“两个柜员同时操作同一账户怎么办”。

4.4 金额计算与精度控制：血的教训

关于金额，我再单独拉一节出来强调，是因为这个坑实在太普遍了。我在同类的转账、充值项目里接过太多问题单，最后定位发现都是精度问题。先说结论：

• 数据库字段用DECIMAL(18,2)，Java实体用BigDecimal
• 前端传递金额时，用字符串类型，不要用浮点数
• 后端所有金额计算，一律通过BigDecimal的add、subtract、multiply方法，禁止用double做乘除

浮点运算在计算机内部以二进制近似值存储，0.1加0.2的结果并不精确等于0.3。对普通展示系统来说无所谓，但对账务系统来说就是大事故。我记得有个学生在做定期存款利息计算时，用double算利息，一开始看只是多出几分钱，后来复利滚出来，差异越来越大。最后换BigDecimal并用setScale(2, RoundingMode.HALF_UP)保留两位小数，问题才解决。

BigDecimal之间比较大小也不要直接用equals，因为1.0和1.00在BigDecimal里equals返回false。用compareTo方法，返回值小于0、等于0、大于0来比较。这段代码几乎会出现在你系统里的所有金额判断逻辑中。

5. Vue 前端不是“套个模板”就够了

5.1 环境搭建与页面规划

前端部分，vue + Element-UI（或Element Plus）+ Axios是这类管理系统的黄金组合。Vue的安装和环境配置本身是个门槛，很多人卡在node和npm版本不匹配上。建议直接装Node.js LTS版本，使用npm install -g @vue/cli安装脚手架，创建项目后，用npm install逐个安装依赖。如果网络慢，可以配置淘宝镜像。Vue Devtools插件对调试组件状态、路由参数、事件流转帮助极大，做二次开发的时候，没有它就像瞎子在夜里走路。

页面规划上，我用的是经典的后台管理布局：左侧菜单栏、顶部操作栏、中间内容区域。路由至少划分为这么几块：

• 登录页（不需要登录即可访问）
• 工作台首页（展示当日业务量、待办任务）
• 客户管理（客户列表、新增客户、客户详情）
• 账户管理（账户列表、开户、锁定/挂失/销户操作）
• 交易管理（存款、取款、转账、交易流水查询）
• 报表中心（日终结算报表、业务量统计）
• 系统管理（用户管理、角色权限配置、操作日志）

前端的路由设计要配合权限来控制。最直接的做法是，后端登录时返回当前用户的角色和可访问菜单列表，前端根据菜单列表动态生成路由，未授权的路径直接不注册。这样用户即使手工改地址栏，前端也不会渲染对应页面，属于前端侧的“软拦截”。真正的防越权还是要靠后端接口权限判断，前端菜单只是一层交互过滤。

5.2 Axios封装与跨域联调

前后端分离后，联调阶段是最容易出现“玄学”问题的时候。一个常见场景：前端请求后端接口，浏览器控制台报跨域错误。解决办法有两种。第一种是后端加CORS配置，允许前端来源的跨域请求。第二种是前端配置开发环境的代理，在vue.config.js里设置devServer.proxy，把/api前缀的请求转发到后端地址。我更推荐代理方案，因为上线后前后端往往是同域名部署，代理方式更接近生产环境。

Axios的封装也是一个值得认真对待的点。我在项目中统一封装了一套请求工具，核心功能包括：设置baseURL、请求拦截器自动携带token、响应拦截器统一处理业务状态码。后端返回统一结构为{code, msg, data}，遇到code=401时清空本地登录态并跳转登录页，遇到其他错误码弹出提示信息。这套封装做一次，后面写每一个页面都会轻松很多。

还有一个小细节：金额展示。前端拿到BigDecimal序列化后的金额依然是字符串，展示在表格里没问题。但如果你在表单里用Number类型绑定了金额输入框，输入小数时可能会被浏览器的浮点运算干扰。我在做金额输入框时，一般用字符串类型接收，校验时用正则过滤非数字字符，提交时再把字符串原样传给后端。这样避免了很多前端精度的花式坑。

5.3 表格、表单、弹窗：柜台操作系统的UI难点

银行柜台系统页面虽然不多，但有三个UI交互点值得认真做，它们也是你在成品展示阶段最能拿出来讲的部分。

第一是表格操作列。交易流水查询、客户列表这类页面，每行都要有“查看详情”“操作”等按钮，而且要根据业务状态动态显示。比如，只有状态为“正常”的账户才显示“冻结”按钮，已冻结账户显示“解冻”。这种动态按钮的写法，既可以在表格列模板里写v-if判断，也可以在数据Map里维护按钮权限。我通常会把状态判断逻辑抽成一个公共方法，方便复用。

第二是业务操作弹窗。存款、取款、转账这类操作不适合跳转到独立页面，更适合用弹窗承载。弹窗里放表单：选择账户、输入金额、填写备注、点击提交。提交成功后关闭弹窗，刷新表格数据。这里有一个体验细节，提交按钮在请求发出后要置灰，防止用户乱点。和前端置灰配合的，还有我们后端做的幂等校验，两道防线保证不会重复扣款。

第三是表单校验。开户表单必填项、身份证号格式校验、手机号校验、金额范围和格式校验，这些都应该在提交前完成。Element-UI的校验规则引擎支持自定义正则，写起来不费事，但很多同学懒得做，导致脏数据直接进入数据库，后面展示时到处报错。前端多拦一道，后端少处理很多垃圾数据。

6. 安全与审计：一个银行系统里不能省的那部分

6.1 RBAC权限模型的具体落地

权限设计我前文提了角色，这里展开具体的数据库与代码落地。RBAC模型用五张表实现：用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。后端接口鉴权的核心逻辑，就是在拦截器或注解中判断当前用户的角色是否拥有对应菜单权限码。

我的做法是自定义一个@RequirePermission注解，标注在Controller方法上，值为权限码字符串，比如@RequirePermission("customer:add")。权限校验的逻辑在一个AOP切面里实现：从ThreadLocal拿到当前登录用户，查出它的角色和权限码集合，判断注解要求的权限码是否在集合内。不在则抛业务异常，由全局异常处理器转成403响应。

使用注解的好处是，权限说明直接写在代码上，维护性强。缺点是权限码要提前定义好。对于课程设计来说，我建议至少实现“菜单级别的权限控制”，也就是不同角色登录后看到不同菜单。做到“按钮级别的权限控制”是加分项，比如普通柜员看不到“日终结算”按钮。两者实现的底层数据模型是一样的，无非校验粒度不同。

6.2 操作日志与审计链路

我在第二部分说过，交易要记录交易前余额、交易后余额。这里说的是更广义的操作审计：柜员登录、开户、修改客户信息、密码重置、删除数据，这些操作本身即使不涉及资金变动，也应该被记录到操作日志表中。

实现操作日志最简单可靠的方式是Spring AOP。定义一个@OpLog注解，标注在需要记录日志的方法上，注解参数里写明操作类型和操作描述模板。切面在方法执行成功后，从请求上下文拿到当前用户ID、请求IP、方法参数，组装日志内容插入数据库。这个方案的优势是侵入性极小，不污染业务代码，又可以覆盖所有需要记录的操作。

操作日志表的设计我在前面已经有字段说明。需要注意一点：日志内容最好使用模板+参数的形式，比如“用户{username}对账户{accountNo}执行了{opType}操作，金额{amount}”。如果直接把业务对象toString塞进去，JSON串太长而且没人看得懂。日志是给人追溯用的，不是给代码看的，可读性非常重要。

我在项目里还会写一个简单的“日终试算平衡”功能，思路是：按当日日期统计所有交易流水的借方发生额合计、贷方发生额合计，两边应该相等；再对比当日所有账户余额变动合计，与流水合计核对。这个功能只是几十行SQL的事，但它是账务系统审计思想的最好体现。答辩时只要拿出它，深度立马和普通仓储系统拉开差距。

6.3 敏感信息脱敏与密码安全

银行系统的数据敏感性毋庸置疑。用户管理这块，密码存储绝对禁止明文。我用BCryptPasswordEncoder做密码哈希，每次匹配都用matches方法比对。注意BCrypt每次生成的盐不同，所以数据库里存的是带盐的哈希串，不需要单独存盐字段。

客户管理这块，身份证号、手机号、联系地址都属于敏感信息。列表页展示时要脱敏：身份证显示前6位和后4位，中间用星号代替；手机号显示前3位和后4位。脱敏既可以在后端返回时直接处理，也可以在前端管道处理。我更推荐后端统一处理，因为一旦接口被绕过，前端脱敏等于没脱。

登录安全这块，银行业的柜台系统理论上应该有硬件U盾或动态令牌，课程设计肯定做不到这一步，但可以做个验证码。我用的方案是：后端生成验证码图片存入Redis，设定有效期两分钟，前端输入验证码和账号密码一起提交，后端校验通过后签发JWT。这个方案实现成本不高，但它在答辩中可以拿出来说明“我考虑了爆破攻击和验证码过期风险”。

7. 复盘与答辩：源码能跑通不是终点

7.1 我在实操中踩过的几个印象深刻的坑

这个项目的开发过程，基本上也代表了springboot + vue全栈新手会踩坑的典型路径。我把几个最常见、最隐蔽的坑整理出来，你们做到对应环节时能少走弯路。

第一个坑是MyBatis-Plus自动填充不生效。我在设计表结构时给几乎所有表都加了create_time和update_time字段，按MyBatis-Plus的官方文档配置了MetaObjectHandler的insertFill和updateFill，但运行时发现create_time是空的。检查半天，原因是实体类的字段没有配置@TableField(fill = FieldFill.INSERT)注解。这类注解缺失问题，报错不明显，只能自己debug。做完一个表后，把所有实体的填充注解统一检查一遍。

第二个坑是事务自调用失效。前面讲过了，如果在同一个Service类里，一个方法调用另一个加@Transactional的方法，事务是失效的。我遇到一个学生写转账方法，把扣款逻辑写在了内部私有方法里加事务注解，外部调用转账方法时，内部扣款出错并没有回滚。排查时看到控制台没有事务开启日志才反应过来。

第三个坑是数据库连接池耗尽。开发阶段人数少，感觉不明显，但导出数据库脚本或用Jmeter做简单压测时，一旦并发请求超过连接池上限，整个系统就卡住不动。如果项目中使用了@Transactional，一个事务会占用一个数据库连接，在方法里做了大量耗时的第三方调用，连接迟迟不释放，就会把HikariCP的默认10个连接全部占满。解决办法是，事务方法保持短小精悍，不要在里面调远程接口或做大量循环操作。

第四个坑是Vue打包后的路由刷新404。这个问题一般在上线部署或验收演示时暴露。打包后部署在Nginx，刷新某个子路由页面，Nginx返回404，因为前端路由是history模式，刷新时Nginx不知道应该把所有路径都指向index.html。解决方式是配置Nginx的try_files $uri $uri/ /index.html。这个问题在项目本地开发时不会出现，但一定会出现在部署验收时，提前配好省得现场尴尬。

7.2 文档怎么写才不是流水账

标题里“源码+数据库+文档”三件套中的文档，很多同学都是最后一天才匆匆忙忙从同类项目里抄一份。这样的文档别说老师看不过去，你自己答辩时都讲不顺。

一篇合格的课程设计/毕业设计文档，要从始至终服务一个目标：让一个没看过你代码的人，通过文档就能理解你做了什么、为什么要这么做。因此，最核心的是需求分析和系统设计部分，而不是贴大段大段代码。需求分析部分，至少包括：项目背景与目标、角色分析、功能性需求、非功能性需求。系统设计部分，包括总体架构图（可以用文字或简单符号描述，不需要花哨但要说清楚层次）、功能模块划分、数据库设计（每张表都配说明字段含义和关联关系）、关键业务流程的文字时序说明。

我在带学生写文档时，会特别强调数据库设计章节。一张表一个表格，字段名、类型、是否为空、默认值、含义说明，列得清清楚楚。这是整个文档中最能体现工程素养的部分，也是老师最爱翻的部分。业务流程图和功能结构图用简洁的块状图即可，不用太炫，但要逻辑自洽。

测试章节也别写成“功能均正常”。至少要列出核心业务场景的测试用例，比如正常存款、余额不足取款、重复提交、跨柜员并发取款、账户冻结状态下开户失败等。能写出这些用例，比你写一百行“测试通过”有用得多。

7.3 答辩与扩展：如何自然而然地把亮点讲出来

到了答辩环节，你不需要吹嘘技术栈有多新，系统有多好看，而要选择两三个真正有深度的点，用“业务场景+我的方案+为什么这么选”的结构讲清楚。我建议选择的点如下：

第一个亮点肯定是并发与事务。讲到转账或取款功能时，主动引出“如何防止两个柜员同时操作同一账户导致超扣”，说出你的乐观锁方案。我建议准备一个数字类比：余额1000时，两个请求同时读，乐观锁会让后提交的那个请求更新影响行数为0，系统提示重试，从而保证不会扣成负数。

第二个亮点是权限设计与操作审计。讲清楚五张RBAC表如何协作，AOP如何切面记录日志，日终试算平衡如何校验每天的数据。这个点能向答辩老师传达一个信息：你不只是会调接口，你考虑了系统的安全和可追溯性。

第三个亮点是前后端分离与接口设计。你可以刻意提到统一响应结构、axios全局拦截器、JWT认证流程、跨域代理方案。这些词在面试环节同样是加分项，因为不少工作两三年的人也未必能把前因后果说透。

当然，你的系统还有非常大的扩展空间，这也是一些好学的人会在答辩时提的“后续优化方向”，但要注意别只说空话，最好能具体到某个技术方案，比如：

• 引入RabbitMQ做跨系统记账消息通知，实现异步解耦
• 接入报表引擎，将日终结算升级为图形化经营分析看板
• 客户端增加业务受理影像采集，和银行后台流程引擎联动

我个人在实际操作中的体会是，这类银行柜台系统真正难的不是技术本身，而是把“一笔业务必须走通的全链路”想清楚。你只要能把一笔存款从页面点击到数据库余额变化，再到操作日志留痕的完整路径对着别人讲明白，这个项目的训练目的就达到了。后面不管你做电商、做OA、做任何管理类系统，会发现很多思路都是一脉相承的。所谓源码、数据库、文档三件套，本质上就是逼你把“能跑的东西”和“能讲的东西”完整地交付出来——这本身就是从业者最该养成的工作习惯。