简介这份资源是面向高校在校生与课程设计学习者的数据库课设项目包主题为大学生贷款管理系统提供可运行的Java源码与配套说明书帮助读者完成从数据库建模到前后端交互的完整实践。压缩包共46个文件约1.1MB以18个java源文件与20个class编译文件为主体另含1个sql建库脚本、1份doc说明书及图片等辅助素材覆盖学生信息、贷款申请、还款记录与用户权限等表结构设计并体现MVC分层与登录注册、贷款审批、还款管理、数据统计等功能模块。已有1510人学习下载适合需要参考项目结构、理解数据库设计与Java实现流程的读者对照研读也可作为课设选题与答辩准备的实践样例。1. 从一份“能跑起来”的数据库课设说起每年到了数据库课程设计的中后期总有人拿着一个能登录、能增删改查、但一被追问“表怎么设计的、事务怎么控的、并发怎么办”就卡壳的系统来找我。在校大学生贷款管理系统这个题目尤其典型业务链条不长但涉及学生、贷款申请、审批、放款、还款计划、逾期状态等多个实体关系一旦理不清后面写多少代码都是补丁摞补丁。这份源码加说明书的组合解决的正是“结构先立住、再谈功能”的问题适合正在做数据库课设、课程设计或者需要一份可交付管理系统方案的学生和初级开发者参考。它不追求花哨的前端重点落在表结构、约束、状态流转和一套能讲清楚的说明书上这也是答辩时最容易被追问的部分。2. 需求与数据建模先把实体和状态机定死2.1 业务角色与核心用例拆解贷款管理系统的角色不多但每个角色的边界必须提前划清否则后面权限判断会散落在各个接口里。通常的做法是拆成三类角色学生端负责提交贷款申请、查看审批进度、查询还款计划审核端负责初审和终审决定额度与期限管理端负责放款登记、逾期标记和基础数据维护。用例上不要一上来就画大而全的图先把“申请—审批—放款—还款—结清/逾期”这条主链路走通再补异常分支。我一般会先列一张角色与操作的对应表把每个操作落到具体的数据表上这样建表时不会漏字段。比如“审批”这个动作表面上是改一个状态实际上要同时写入审批记录、更新申请单状态、可能还要生成还款计划这三件事必须在一个事务里完成。很多课设翻车就翻在这里状态改了但还款计划没生成后面还款模块直接对不上账。2.2 核心表结构与约束设计表设计是这份方案的重头戏。学生表、贷款申请 table、审批记录表、还款计划表、还款流水表这五张表基本能撑起主流程。关键不在于表多而在于约束写没写对。下面这段建表语句是主流程里最核心的申请与还款计划部分字段名和类型可以直接照着改-- 贷款申请主表一条申请对应一个学生的一次借款 CREATE TABLE loan_application ( app_id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, apply_amount DECIMAL(10,2) NOT NULL CHECK (apply_amount 0), approved_amount DECIMAL(10,2) DEFAULT NULL, term_months INT NOT NULL CHECK (term_months BETWEEN 1 AND 36), status TINYINT NOT NULL DEFAULT 0, -- 0待审 1初审过 2终审过 3已放款 4已结清 5已拒绝 apply_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, CONSTRAINT fk_app_student FOREIGN KEY (student_id) REFERENCES student(student_id) ); -- 还款计划表放款时按期限拆成若干期 CREATE TABLE repay_plan ( plan_id BIGINT PRIMARY KEY AUTO_INCREMENT, app_id BIGINT NOT NULL, period_no INT NOT NULL, -- 第几期 due_date DATE NOT NULL, principal DECIMAL(10,2) NOT NULL, interest DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0未还 1已还 2逾期 UNIQUE KEY uk_app_period (app_id, period_no), CONSTRAINT fk_plan_app FOREIGN KEY (app_id) REFERENCES loan_application(app_id) );这里有几个设计点值得说清楚。status用 TINYINT 而不是字符串是为了索引效率和状态机判断方便但一定要在说明书里附一张状态码对照表否则答辩时没人看得懂。approved_amount允许为空是因为审批前它本来就不存在不要给它设默认值 0否则“未审批”和“批了 0 元”就分不清了。还款计划表的uk_app_period唯一键是血泪经验没有它重复放款或重复生成计划时会出现同一期两条记录后面还款流水一关联就全乱。金额字段统一用 DECIMAL别用 FLOAT利息计算差几分钱在答辩现场被指出来很尴尬。2.3 状态流转与事务边界状态机要画在说明书里代码里也要有对应的校验。申请单从 0 到 5 的流转不是随便改的每次变更前都要判断当前状态是否允许。通常的做法是写一个状态流转表把“当前状态 → 允许的下一状态 → 触发角色”列清楚代码里用一个简单的映射判断而不是散落一堆 if。放款这个动作最重更新申请状态为 3、生成还款计划、写一条放款流水三件事必须包在一个事务里。下面这段是放款服务的核心逻辑示意def disburse(app_id, operator): with db.transaction(): app query_app_for_update(app_id) # 行锁防止并发重复放款 if app.status ! 2: raise BizError(当前状态不允许放款) update_app_status(app_id, 3) plans build_repay_plans(app.approved_amount, app.term_months) batch_insert_plans(app_id, plans) # 按期拆分写入 insert_disburse_log(app_id, operator)query_app_for_update这行行锁是很多人会漏的。课设演示时单线程看不出问题但答辩老师如果问一句“两个管理员同时点放款会怎样”没有行锁就会生成两套还款计划。事务边界划在服务层而不是 DAO 层是为了让“状态 计划 流水”要么全成功要么全回滚这也是说明书里需要重点写清楚的一段。3. 总体架构与模块划分三层结构怎么落到目录3.1 分层结构与职责边界这套系统我建议按 controller、service、dao 三层来组织别把业务逻辑写进 controller也别让 dao 里出现状态判断。controller 只做参数接收和返回封装service 承担状态校验、事务和业务编排dao 只负责单表 CRUD 和简单查询。目录上按模块分而不是按技术分比如student、loan、repay、admin四个包每个包下再分三层这样找代码时按业务就能定位。说明书里最好附一张模块职责表把每个模块对外暴露的接口和依赖的模块写清楚。比如还款模块依赖贷款模块查询申请状态但不直接操作申请表而是通过 service 调用。这种约束在课设规模下看起来有点重但答辩时被问到“模块之间怎么解耦”就有话可说。实际落地时公共的返回体、异常处理、分页参数抽到 common 包里避免每个模块重复造轮子。3.2 关键接口与参数约定接口设计上统一返回结构比什么都重要。下面这个返回体是整套系统所有接口共用的前端和说明书都按这个约定来{ code: 0, message: success, data: {} }code为 0 表示成功非 0 表示业务异常message给前端直接展示data放业务数据。分页接口统一用pageNum、pageSize两个参数返回里带total。这种约定看起来是小事但课设里最常见的翻车就是每个接口返回格式不一样前端写一套适配逻辑最后说明书也没法统一描述。参数校验放在 controller 层用注解做基础校验业务校验放 service比如“申请金额不能超过剩余额度”这种依赖数据的判断不能放在 controller。3.3 权限与登录的轻量实现课设不需要上完整的权限框架但登录态和角色判断必须有。通常的做法是登录成功后签发一个 token服务端用拦截器解析 token 拿到用户 id 和角色塞进上下文service 里按角色做操作校验。别把角色判断写死在每个接口里抽一个注解或者拦截规则按 URL 前缀区分学生端和管理端。密码存储必须加盐哈希说明书里要写明用的算法和盐值来源这是答辩常问的安全点。token 过期时间设短一点比如两小时演示时够用也显得考虑过安全性。4. 核心功能实现申请、审批、还款三条链路4.1 申请提交与额度校验申请提交看起来简单但校验点不少学生是否已结清上一笔、当前是否有在途申请、申请金额是否在允许区间、期限是否合规。这些校验要放在一个 service 方法里按顺序做任何一条不满足就抛业务异常。下面这段是申请提交的核心校验逻辑def submit_application(student_id, amount, term): if amount 0 or amount MAX_AMOUNT: raise BizError(申请金额不合法) if term not in ALLOWED_TERMS: raise BizError(期限不在允许范围) if has_unfinished_application(student_id): # 在途申请检查 raise BizError(存在未结清申请暂不能重复申请) app_id insert_application(student_id, amount, term) return app_idhas_unfinished_application这个检查是很多人会漏的结果演示时同一个学生能提交好几笔审批列表里一堆重复数据。实现上查一下状态在 0 到 3 之间的申请即可注意加索引否则数据量一大就慢。金额上限和允许期限建议做成配置项或者常量表说明书里写清楚取值依据别硬编码在代码里还说不出来源。4.2 两级审批与审批记录审批分初审和终审目的是模拟真实流程也让状态机更有层次。初审通过后状态变 1终审通过变 2 并写入批准金额拒绝则直接变 5。每次审批都要写一条审批记录记录操作人、时间、意见和前后状态这张表是答辩时证明“流程可追溯”的关键。审批接口要判断当前状态是否匹配当前审批级别比如初审只能处理状态 0 的单子终审只能处理状态 1 的否则会出现跳级审批。审批意见字段别设成必填但建议给默认值演示时省得每次填。批准金额在终审时写入要校验不超过申请金额这个校验放在 service 里和状态判断一起做。审批记录表不需要外键强关联到用户表存操作人 id 和姓名快照即可避免用户改名后历史记录对不上这也是说明书里可以提一句的设计取舍。4.3 还款计划生成与还款登记还款计划在放款时生成按等额本息或者等额本金拆期课设里用等额本金更简单每期本金相同利息按剩余本金算。生成时要注意最后一期把尾差补上否则总金额对不上。还款登记时按 plan_id 更新状态为已还同时写还款流水并判断该申请下所有期是否都已还清是则把申请状态改为 4。下面这段是还款登记的核心逻辑def repay(plan_id, pay_amount): with db.transaction(): plan query_plan_for_update(plan_id) if plan.status 1: raise BizError(该期已还清) if pay_amount plan.principal plan.interest: raise BizError(还款金额不足) update_plan_status(plan_id, 1) insert_repay_log(plan_id, pay_amount) if all_periods_paid(plan.app_id): update_app_status(plan.app_id, 4)query_plan_for_update同样是防并发重复还款。all_periods_paid查该申请下未还期数是否为 0注意要把逾期状态也算作未结清。还款金额这里简化成必须足额实际系统可能支持部分还款课设里不做也行但说明书里要说明这个简化别让老师以为是漏了。5. 避坑与常见问题答辩前最容易翻车的五处5.1 金额用浮点导致对账差几分现象是还款计划各期金额加起来和批准金额差几分钱或者利息算出来是 33.33333。原因是用了 FLOAT 或 DOUBLE 存金额。解决是把所有金额字段改成 DECIMAL(10,2)计算时用数据库的 DECIMAL 运算或者代码里的 Decimal 类型最后统一保留两位。生成计划时尾差补到最后一期并在说明书里写明这个处理。5.2 状态判断散落各处导致流转混乱现象是同一个申请单能跳过初审直接终审或者已结清的单子还能还款。原因是状态校验写在各个接口里没有统一的状态机。解决是抽一个状态流转判断方法所有状态变更前都调用它把允许的流转关系集中维护说明书里附状态流转表。5.3 并发演示时重复放款或重复还款现象是答辩时老师让点两次按钮结果生成两套还款计划或者同一期还了两次。原因是查询后直接更新没有行锁也没有唯一约束。解决是放款和还款都用SELECT ... FOR UPDATE加行锁还款计划表加(app_id, period_no)唯一键兜底双保险。5.4 外键缺失导致脏数据现象是删了一个学生他的申请单还在还款计划还挂着。原因是建表时没加外键或者加了但没设级联规则。解决是核心关联字段都加外键删除策略按业务定课设里建议用 RESTRICT不允许直接删有业务数据的学生改为逻辑删除说明书里说明这个选择。5.5 说明书和代码对不上现象是说明书里写的字段名、状态码和代码里不一致答辩时被当场指出。原因是先写代码后补文档中间改过字段没同步。解决是建表和状态码定稿后再写说明书的数据字典部分改代码时同步改文档最后对照检查一遍。这个坑看起来低级但每年都有人栽。6. 验收与答辩怎么把这份方案讲成自己的验收这件事我一般建议按“数据—流程—异常”三层来准备。第一层是数据层打开数据库客户端把五张核心表的建表语句和数据字典摆出来重点讲约束和索引为什么这么设比如唯一键防重复、DECIMAL 防精度丢失、外键防脏数据。第二层是流程层按“申请—初审—终审—放款—还款—结清”走一遍完整链路每一步展示状态变化和对应的表数据变化让老师看到状态机是闭合的。第三层是异常层主动演示几个边界重复申请被拦、并发放款只成功一次、金额不足还款被拒、已结清单子不能再还。主动暴露边界比被问出来强得多。答辩陈述控制在八到十分钟结构上按“需求背景一句话、表设计两分钟、核心流程三分钟、异常与取舍两分钟”来分配。表设计部分不要逐字段念挑三到四个关键设计点讲比如状态码为什么用数字、还款计划为什么放款时才生成、事务边界划在哪。被问到不会的问题别硬编可以说“这部分当前做了简化处理后续可以按某种方式扩展”然后把话题引回你熟悉的模块。说明书里的数据字典和状态流转表要提前打印或者放在手边被问字段含义时直接翻比现场回忆靠谱。下面这张验收自查表可以照着过一遍每项都确认后再去答辩检查项合格标准常见问题表结构五张核心表齐全主外键完整缺还款流水表金额精度全部 DECIMAL尾差已处理用 FLOAT 导致对账不平状态流转有流转表代码集中校验跳级审批事务放款、还款在事务内状态改了计划没生成并发关键操作有行锁或唯一键重复放款文档数据字典与代码一致字段名对不上从那以后我每次带课设都强制要求先把状态流转表和数据字典定稿再动代码最后对照自查表走一遍翻车的概率能降一大半。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/24 4:28:17 · 阅读 1.2k 数据库课设实战：学生贷款管理系统表设计与事务并发避坑指南
简介这份资源是面向高校在校生与课程设计学习者的数据库课设项目包主题为大学生贷款管理系统提供可运行的Java源码与配套说明书帮助读者完成从数据库建模到前后端交互的完整实践。压缩包共46个文件约1.1MB以18个java源文件与20个class编译文件为主体另含1个sql建库脚本、1份doc说明书及图片等辅助素材覆盖学生信息、贷款申请、还款记录与用户权限等表结构设计并体现MVC分层与登录注册、贷款审批、还款管理、数据统计等功能模块。已有1510人学习下载适合需要参考项目结构、理解数据库设计与Java实现流程的读者对照研读也可作为课设选题与答辩准备的实践样例。1. 从一份“能跑起来”的数据库课设说起每年到了数据库课程设计的中后期总有人拿着一个能登录、能增删改查、但一被追问“表怎么设计的、事务怎么控的、并发怎么办”就卡壳的系统来找我。在校大学生贷款管理系统这个题目尤其典型业务链条不长但涉及学生、贷款申请、审批、放款、还款计划、逾期状态等多个实体关系一旦理不清后面写多少代码都是补丁摞补丁。这份源码加说明书的组合解决的正是“结构先立住、再谈功能”的问题适合正在做数据库课设、课程设计或者需要一份可交付管理系统方案的学生和初级开发者参考。它不追求花哨的前端重点落在表结构、约束、状态流转和一套能讲清楚的说明书上这也是答辩时最容易被追问的部分。2. 需求与数据建模先把实体和状态机定死2.1 业务角色与核心用例拆解贷款管理系统的角色不多但每个角色的边界必须提前划清否则后面权限判断会散落在各个接口里。通常的做法是拆成三类角色学生端负责提交贷款申请、查看审批进度、查询还款计划审核端负责初审和终审决定额度与期限管理端负责放款登记、逾期标记和基础数据维护。用例上不要一上来就画大而全的图先把“申请—审批—放款—还款—结清/逾期”这条主链路走通再补异常分支。我一般会先列一张角色与操作的对应表把每个操作落到具体的数据表上这样建表时不会漏字段。比如“审批”这个动作表面上是改一个状态实际上要同时写入审批记录、更新申请单状态、可能还要生成还款计划这三件事必须在一个事务里完成。很多课设翻车就翻在这里状态改了但还款计划没生成后面还款模块直接对不上账。2.2 核心表结构与约束设计表设计是这份方案的重头戏。学生表、贷款申请 table、审批记录表、还款计划表、还款流水表这五张表基本能撑起主流程。关键不在于表多而在于约束写没写对。下面这段建表语句是主流程里最核心的申请与还款计划部分字段名和类型可以直接照着改-- 贷款申请主表一条申请对应一个学生的一次借款 CREATE TABLE loan_application ( app_id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, apply_amount DECIMAL(10,2) NOT NULL CHECK (apply_amount 0), approved_amount DECIMAL(10,2) DEFAULT NULL, term_months INT NOT NULL CHECK (term_months BETWEEN 1 AND 36), status TINYINT NOT NULL DEFAULT 0, -- 0待审 1初审过 2终审过 3已放款 4已结清 5已拒绝 apply_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, CONSTRAINT fk_app_student FOREIGN KEY (student_id) REFERENCES student(student_id) ); -- 还款计划表放款时按期限拆成若干期 CREATE TABLE repay_plan ( plan_id BIGINT PRIMARY KEY AUTO_INCREMENT, app_id BIGINT NOT NULL, period_no INT NOT NULL, -- 第几期 due_date DATE NOT NULL, principal DECIMAL(10,2) NOT NULL, interest DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0未还 1已还 2逾期 UNIQUE KEY uk_app_period (app_id, period_no), CONSTRAINT fk_plan_app FOREIGN KEY (app_id) REFERENCES loan_application(app_id) );这里有几个设计点值得说清楚。status用 TINYINT 而不是字符串是为了索引效率和状态机判断方便但一定要在说明书里附一张状态码对照表否则答辩时没人看得懂。approved_amount允许为空是因为审批前它本来就不存在不要给它设默认值 0否则“未审批”和“批了 0 元”就分不清了。还款计划表的uk_app_period唯一键是血泪经验没有它重复放款或重复生成计划时会出现同一期两条记录后面还款流水一关联就全乱。金额字段统一用 DECIMAL别用 FLOAT利息计算差几分钱在答辩现场被指出来很尴尬。2.3 状态流转与事务边界状态机要画在说明书里代码里也要有对应的校验。申请单从 0 到 5 的流转不是随便改的每次变更前都要判断当前状态是否允许。通常的做法是写一个状态流转表把“当前状态 → 允许的下一状态 → 触发角色”列清楚代码里用一个简单的映射判断而不是散落一堆 if。放款这个动作最重更新申请状态为 3、生成还款计划、写一条放款流水三件事必须包在一个事务里。下面这段是放款服务的核心逻辑示意def disburse(app_id, operator): with db.transaction(): app query_app_for_update(app_id) # 行锁防止并发重复放款 if app.status ! 2: raise BizError(当前状态不允许放款) update_app_status(app_id, 3) plans build_repay_plans(app.approved_amount, app.term_months) batch_insert_plans(app_id, plans) # 按期拆分写入 insert_disburse_log(app_id, operator)query_app_for_update这行行锁是很多人会漏的。课设演示时单线程看不出问题但答辩老师如果问一句“两个管理员同时点放款会怎样”没有行锁就会生成两套还款计划。事务边界划在服务层而不是 DAO 层是为了让“状态 计划 流水”要么全成功要么全回滚这也是说明书里需要重点写清楚的一段。3. 总体架构与模块划分三层结构怎么落到目录3.1 分层结构与职责边界这套系统我建议按 controller、service、dao 三层来组织别把业务逻辑写进 controller也别让 dao 里出现状态判断。controller 只做参数接收和返回封装service 承担状态校验、事务和业务编排dao 只负责单表 CRUD 和简单查询。目录上按模块分而不是按技术分比如student、loan、repay、admin四个包每个包下再分三层这样找代码时按业务就能定位。说明书里最好附一张模块职责表把每个模块对外暴露的接口和依赖的模块写清楚。比如还款模块依赖贷款模块查询申请状态但不直接操作申请表而是通过 service 调用。这种约束在课设规模下看起来有点重但答辩时被问到“模块之间怎么解耦”就有话可说。实际落地时公共的返回体、异常处理、分页参数抽到 common 包里避免每个模块重复造轮子。3.2 关键接口与参数约定接口设计上统一返回结构比什么都重要。下面这个返回体是整套系统所有接口共用的前端和说明书都按这个约定来{ code: 0, message: success, data: {} }code为 0 表示成功非 0 表示业务异常message给前端直接展示data放业务数据。分页接口统一用pageNum、pageSize两个参数返回里带total。这种约定看起来是小事但课设里最常见的翻车就是每个接口返回格式不一样前端写一套适配逻辑最后说明书也没法统一描述。参数校验放在 controller 层用注解做基础校验业务校验放 service比如“申请金额不能超过剩余额度”这种依赖数据的判断不能放在 controller。3.3 权限与登录的轻量实现课设不需要上完整的权限框架但登录态和角色判断必须有。通常的做法是登录成功后签发一个 token服务端用拦截器解析 token 拿到用户 id 和角色塞进上下文service 里按角色做操作校验。别把角色判断写死在每个接口里抽一个注解或者拦截规则按 URL 前缀区分学生端和管理端。密码存储必须加盐哈希说明书里要写明用的算法和盐值来源这是答辩常问的安全点。token 过期时间设短一点比如两小时演示时够用也显得考虑过安全性。4. 核心功能实现申请、审批、还款三条链路4.1 申请提交与额度校验申请提交看起来简单但校验点不少学生是否已结清上一笔、当前是否有在途申请、申请金额是否在允许区间、期限是否合规。这些校验要放在一个 service 方法里按顺序做任何一条不满足就抛业务异常。下面这段是申请提交的核心校验逻辑def submit_application(student_id, amount, term): if amount 0 or amount MAX_AMOUNT: raise BizError(申请金额不合法) if term not in ALLOWED_TERMS: raise BizError(期限不在允许范围) if has_unfinished_application(student_id): # 在途申请检查 raise BizError(存在未结清申请暂不能重复申请) app_id insert_application(student_id, amount, term) return app_idhas_unfinished_application这个检查是很多人会漏的结果演示时同一个学生能提交好几笔审批列表里一堆重复数据。实现上查一下状态在 0 到 3 之间的申请即可注意加索引否则数据量一大就慢。金额上限和允许期限建议做成配置项或者常量表说明书里写清楚取值依据别硬编码在代码里还说不出来源。4.2 两级审批与审批记录审批分初审和终审目的是模拟真实流程也让状态机更有层次。初审通过后状态变 1终审通过变 2 并写入批准金额拒绝则直接变 5。每次审批都要写一条审批记录记录操作人、时间、意见和前后状态这张表是答辩时证明“流程可追溯”的关键。审批接口要判断当前状态是否匹配当前审批级别比如初审只能处理状态 0 的单子终审只能处理状态 1 的否则会出现跳级审批。审批意见字段别设成必填但建议给默认值演示时省得每次填。批准金额在终审时写入要校验不超过申请金额这个校验放在 service 里和状态判断一起做。审批记录表不需要外键强关联到用户表存操作人 id 和姓名快照即可避免用户改名后历史记录对不上这也是说明书里可以提一句的设计取舍。4.3 还款计划生成与还款登记还款计划在放款时生成按等额本息或者等额本金拆期课设里用等额本金更简单每期本金相同利息按剩余本金算。生成时要注意最后一期把尾差补上否则总金额对不上。还款登记时按 plan_id 更新状态为已还同时写还款流水并判断该申请下所有期是否都已还清是则把申请状态改为 4。下面这段是还款登记的核心逻辑def repay(plan_id, pay_amount): with db.transaction(): plan query_plan_for_update(plan_id) if plan.status 1: raise BizError(该期已还清) if pay_amount plan.principal plan.interest: raise BizError(还款金额不足) update_plan_status(plan_id, 1) insert_repay_log(plan_id, pay_amount) if all_periods_paid(plan.app_id): update_app_status(plan.app_id, 4)query_plan_for_update同样是防并发重复还款。all_periods_paid查该申请下未还期数是否为 0注意要把逾期状态也算作未结清。还款金额这里简化成必须足额实际系统可能支持部分还款课设里不做也行但说明书里要说明这个简化别让老师以为是漏了。5. 避坑与常见问题答辩前最容易翻车的五处5.1 金额用浮点导致对账差几分现象是还款计划各期金额加起来和批准金额差几分钱或者利息算出来是 33.33333。原因是用了 FLOAT 或 DOUBLE 存金额。解决是把所有金额字段改成 DECIMAL(10,2)计算时用数据库的 DECIMAL 运算或者代码里的 Decimal 类型最后统一保留两位。生成计划时尾差补到最后一期并在说明书里写明这个处理。5.2 状态判断散落各处导致流转混乱现象是同一个申请单能跳过初审直接终审或者已结清的单子还能还款。原因是状态校验写在各个接口里没有统一的状态机。解决是抽一个状态流转判断方法所有状态变更前都调用它把允许的流转关系集中维护说明书里附状态流转表。5.3 并发演示时重复放款或重复还款现象是答辩时老师让点两次按钮结果生成两套还款计划或者同一期还了两次。原因是查询后直接更新没有行锁也没有唯一约束。解决是放款和还款都用SELECT ... FOR UPDATE加行锁还款计划表加(app_id, period_no)唯一键兜底双保险。5.4 外键缺失导致脏数据现象是删了一个学生他的申请单还在还款计划还挂着。原因是建表时没加外键或者加了但没设级联规则。解决是核心关联字段都加外键删除策略按业务定课设里建议用 RESTRICT不允许直接删有业务数据的学生改为逻辑删除说明书里说明这个选择。5.5 说明书和代码对不上现象是说明书里写的字段名、状态码和代码里不一致答辩时被当场指出。原因是先写代码后补文档中间改过字段没同步。解决是建表和状态码定稿后再写说明书的数据字典部分改代码时同步改文档最后对照检查一遍。这个坑看起来低级但每年都有人栽。6. 验收与答辩怎么把这份方案讲成自己的验收这件事我一般建议按“数据—流程—异常”三层来准备。第一层是数据层打开数据库客户端把五张核心表的建表语句和数据字典摆出来重点讲约束和索引为什么这么设比如唯一键防重复、DECIMAL 防精度丢失、外键防脏数据。第二层是流程层按“申请—初审—终审—放款—还款—结清”走一遍完整链路每一步展示状态变化和对应的表数据变化让老师看到状态机是闭合的。第三层是异常层主动演示几个边界重复申请被拦、并发放款只成功一次、金额不足还款被拒、已结清单子不能再还。主动暴露边界比被问出来强得多。答辩陈述控制在八到十分钟结构上按“需求背景一句话、表设计两分钟、核心流程三分钟、异常与取舍两分钟”来分配。表设计部分不要逐字段念挑三到四个关键设计点讲比如状态码为什么用数字、还款计划为什么放款时才生成、事务边界划在哪。被问到不会的问题别硬编可以说“这部分当前做了简化处理后续可以按某种方式扩展”然后把话题引回你熟悉的模块。说明书里的数据字典和状态流转表要提前打印或者放在手边被问字段含义时直接翻比现场回忆靠谱。下面这张验收自查表可以照着过一遍每项都确认后再去答辩检查项合格标准常见问题表结构五张核心表齐全主外键完整缺还款流水表金额精度全部 DECIMAL尾差已处理用 FLOAT 导致对账不平状态流转有流转表代码集中校验跳级审批事务放款、还款在事务内状态改了计划没生成并发关键操作有行锁或唯一键重复放款文档数据字典与代码一致字段名对不上从那以后我每次带课设都强制要求先把状态流转表和数据字典定稿再动代码最后对照自查表走一遍翻车的概率能降一大半。希望帮到你。本文还有配套的精品资源点击获取