1. 项目需求与功能边界怎么定1.1 实验中心器材管理的真实痛点先说说这个项目的由来。某高校实验中心以前管器材靠的是纸质台账加一张Excel大表谁借了什么、什么时候还、库存还剩多少全靠管理员手动记。碰到学期末集中做实验几十个人排队借仪器台账本翻得哗哗响经常出现器材明明已经借出去了、账面上却显示还在库里的情况。后来设备多了、借用频率高了这套纯人工的模式彻底撑不住。所以这次的Web课程设计我选了实验中心器材管理系统这个题目目标很明确把借还流程搬到线上让库存状态实时可见让每一笔记录都可追溯。这个系统的使用场景比较清晰不需要做成大而全的ERP。它要服务三类人普通学生用户负责提交借用申请和查看自己的记录实验员负责审核、登记归还和维护器材信息管理员除了拥有实验员的所有权限之外还能查看统计报表。围绕这三个角色把权限切好核心链路打通这个项目就已经超过大多数课程作业的水平了。1.2 功能清单与角色权限划分我在做需求梳理的时候把所有功能列出来然后做了一个必须做和加分做的区分。必须做的是用户登录注册、器材信息的分页展示与条件检索、借用申请、库存自动扣减、归还登记、借用记录查询。加分做的是逾期自动标记、借阅排行榜、按分类统计使用率、简单图表展示。功能边界这个东西很多人做课程设计容易犯一个毛病想做的太多结果每个功能都只做了一半。我的建议是先保证主链路完整再去加花活。主链路就是用户登录→浏览器材→提交借用→库存减少→归还→库存恢复这条线这条线只要有一个环断了整个系统就不能用。把这条线跑通了再考虑统计报表之类的增强功能。权限划分我用的是角色字段控制没有引入Spring Security那套重量级框架因为课程设计没必要把复杂度抬那么高。用户表里加一个role字段管理员和普通用户走不同的菜单和接口权限用一个拦截器统一做登录校验和角色校验简单直接好解释也好答辩。1.3 为什么没有引入复杂设计有一点我想特别说一下就是不要为了体现技术含量而人为增加复杂度。比如器材审批流有人觉得学生的借用申请必须经过实验员审核之后才能借。这个逻辑在真实场景下合理但在课程设计里会让演示变得很拖沓。我做的是申请即借出的简化模型用户提交借用申请时系统自动检查库存库存足够就直接扣减并生成借用记录库存不足就提示失败。归还的时候由实验员操作点击归还后系统自动释放库存并计算是否逾期。这个设计是我反复考虑过的。课程设计的核心是让业务闭环、逻辑自洽而不是流程多复杂。简化之后学生体验顺畅管理员操作少演示的时候节奏也舒服。真实的实验中心当然可以再加审核环节这个作为扩展点写在文档里就够了。2. 技术选型与数据库设计2.1 技术栈课程设计够用就好技术栈这块我选的是Java那一套经典组合Spring Boot 2.7做后端MyBatis Plus操作数据库MySQL 8.0存储数据前端用Thymeleaf服务端渲染加Bootstrap和原生JavaScript。这套组合的最大优点是生态成熟、资料多、遇到问题一搜就有答案对课程设计来说容错率很高。有人会问为什么不用Vue前后端分离。实话实说如果做前后端分离前端Vue加Element UI确实好看但会引入跨域、Token管理、接口联调一堆额外问题而且答辩的时候老师很可能揪着这些问题追问。服务端渲染的Thymeleaf把页面和Controller直接打通整个项目只有一套代码部署也省心非常适合一个人单挑全部开发的课程设计场景。数据库连接这块建议加上连接池参数配置虽然默认配置也能跑但把maximum-pool-size这类参数写清楚答辩的时候可以多一个加分点。我当时的配置是这样spring: datasource: url: jdbc:mysql://localhost:3306/lab_equipment?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 10 minimum-idle: 2 connection-timeout: 30000注意数据库连接参数里的serverTimezone一定要设置不设的话在高版本MySQL驱动下会报时区错误。这个坑几乎每个初学者都会踩一次。2.2 核心表设计与字段说明数据库设计是整个项目的地基。我设计了三张核心业务表加一张用户表下面是每张表的用途和关键字段。用户表user用来存登录信息和身份标识字段包括id、用户名、加密后的密码、真实姓名、学院、联系电话、角色。密码一定要加密存储我用的是BCrypt这是Spring Security自带的一个加密工具类单独引入security-crypto包就能用不需要引入完整的安全框架。器材表equipment是系统的数据核心字段包括id、器材名称、分类、总数量、可用数量、存放位置、状态、描述、创建时间、更新时间。这里最关键的设计是总数量和可用数量分开存。总数量是这件器材一共买了多少可用数量是当前还能借多少。每次借出只动可用数量总数量保持不变这样统计损耗和报废情况的时候才有依据。借用记录表borrow_record记录每一次借和还的全过程字段包括id、用户id、器材id、借用数量、借用时间、应还时间、实际归还时间、状态、备注。状态我用int类型存0表示借出中1表示已归还2表示已逾期逾期是归还时自动计算的派生状态。用数字存状态的好处是后续扩展状态机比较方便加一个3表示挂失不需要改表结构。这三张表的关系很清晰用户和器材是多对多的关系通过借用记录这张关联表来体现。我在设计阶段还画了ER图放在课程设计文档里虽然代码实现的时候并不需要真正用外键去约束但ER图对理清业务非常有帮助。2.3 索引设计与数据一致性约束很多课程设计不注重索引但我觉得这个项目的索引设计恰好是可以拿出来说的亮点。借用记录表里的几个查询场景按用户查个人记录、按器材查借用历史、按状态筛选待处理记录都要用到where条件。我这样建索引ALTER TABLE borrow_record ADD INDEX idx_user_id (user_id); ALTER TABLE borrow_record ADD INDEX idx_equipment_id (equipment_id); ALTER TABLE borrow_record ADD INDEX idx_status (status); ALTER TABLE borrow_record ADD INDEX idx_borrow_time (borrow_time);器材表的分类字段也要加索引因为统计模块需要按分类分组查询。索引不是越多越好但针对高频查询条件建索引是性价比很高的操作这个知识点值得在文档里写透。数据一致性方面我没有用数据库外键而是在Service层做逻辑校验。原因是我希望删除器材的时候不被借用记录的外键卡住实际开发中先查有没有未归还记录有就不允许删除没有就逻辑删除这个业务规则比外键更灵活。业务层的逻辑校验配合事务使用效果完全够用。3. 核心业务功能的实现细节3.1 登录鉴权拦截器与角色控制登录模块是整个系统的入口。我用了Session方案用户登录成功后把用户对象放进Session同时封装了一个拦截器对所有非登录请求做拦截。拦截器里做的事情可以拆成三步第一步检查Session里有没有用户对象没有就直接重定向到登录页第二步拿到当前请求的URI判断是否是以/admin开头的管理端路径第三步检查用户的角色不是管理员就返回403页面是管理员就放行。这里我学到了一个经验拦截器放行规则一定要精确不然会出现静态资源被拦截导致页面完全没样式的问题。我第一次就是把/css/**、/js/**这些静态资源路径漏掉了结果登录页打开以后光秃秃的排查了半天才发现是拦截器把所有静态资源也挡住了。后来我改成在WebMvcConfigurer里用addPathPatterns和excludePathPatterns组合控制问题就解决了。Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authInterceptor) .addPathPatterns(/**) .excludePathPatterns( /login, /doLogin, /register, /doRegister, /css/**, /js/**, /images/**, /error ); }角色控制我是在Controller层做的管理端的所有Controller都加上了一个简单的角色判断或者用注解加AOP切面的方式。考虑到课程设计的代码量我选择了直接在拦截器里统一校验减少注解反射带来的理解成本。3.2 器材管理核心CRUD与分页检索器材管理这一块包含新增、编辑、删除、分页查询、分类筛选和关键字搜索。界面用Bootstrap做了表格和表单查询区域放了一个关键字输入框和一个分类下拉框下面是一个分页组件。分页这块我用的是MyBatis Plus内置的分页插件配置一个MybatisPlusInterceptor就能用不需要手写limit逻辑。前端传current页码和size每页条数后端返回一个Page对象里面包含当前页数据、总条数、总页数Thymeleaf模板里直接遍历就是一套完整的分页。还有一点值得说器材列表页的搜索条件我做了防抖处理。用户输入关键字的时候不急着发请求等停止输入500毫秒以后才重新查询不然每敲一个字就触发一次查询数据库压力大页面也会出现请求错乱的情况。这是我在联调阶段发现的问题快速连续输入多个汉字的时候后面发出去的请求可能比前面先返回导致表格内容来回跳。防抖虽然是个很小的技巧但在课程设计里写出来就是加分项。删除器材的时候需要先检查借用记录表里有没有未归还的借用记录如果有就在前端弹窗提示并且禁止删除。我的处理方法是给删除接口加了状态校验器材表本身用逻辑删除用一个deleted字段标记而不是物理删除数据库记录。逻辑删除让历史数据得以保留万一要审计数据还能恢复成本只是查询时多一个deleted0的条件MyBatis Plus的TableLogic注解就可以自动处理。3.3 借用归还流程库存扣减与状态流转借用流程是整个系统里业务逻辑最密集的地方。我把借用的Service方法完整设计了一遍这里面有几个步骤的顺序特别关键。用户提交借用申请时先校验器材是否存在、是否处于可借状态再校验数量拿用户要借的数量和器材当前可用数量做比较不够就直接返回库存不足提示。校验全部通过后进入一个事务方法扣减器材的可用数量同时插入一条借用记录状态设为借出中应还时间默认是借用时间往后推7天。扣减库存这个操作有一个非常重要的细节我当时排查了很久才搞清楚。正常情况下先查可用数量再判断是否大于要借的数量这种先查后改的操作在高并发场景下会有超卖问题。两个用户同时提交借用两边查到可用数量都是1都认为是够的结果两个人都借出去了库存变成了-1。解决办法是把判断和扣减合并成一条update语句UPDATE equipment SET available_count available_count - #{count} WHERE id #{equipmentId} AND available_count #{count}这条SQL返回的影响行数如果是1说明扣减成功如果是0说明库存不足或者器材状态不对。用数据库层面的条件更新来保证原子性比用Java代码判断再update可靠得多。这个点我在答辩的时候专门做了演示面试官一听就点头。归还流程就简单一些。实验员在待归还列表里找到对应记录点击归还按钮后端做三件事把器材的可用数量加回去、把借用记录的实际归还时间设为当前时间、计算借用天数并判断是否逾期逾期就把记录状态改成2。归还操作的幂等性也需要注意如果用户连续点了两次归还按钮第二次要能识别出记录已经是已归还状态并给出友好提示。借用记录的列表查询默认只展示未归还的记录追加了一个状态筛选下拉框。为了让列表页能显示用户名和器材名而不是直接显示外键ID我用了连表查询SELECT br.*, u.real_name, u.username, e.name AS equipment_name, e.category, e.location FROM borrow_record br LEFT JOIN user u ON br.user_id u.id LEFT JOIN equipment e ON br.equipment_id e.id WHERE br.deleted 0 ORDER BY br.borrow_time DESC一开始我图省事打算用两个循环分别查User和Equipment再手动组装数据后来数据量一大发现这方式太笨重了N1查询问题非常明显。改成连表之后一次查询全搞定代码也干净很多。MyBatis Plus的注解SQL在这里很顺手Select注解直接写原生SQL就行。4. 统计报表模块的实现思路4.1 借用排行榜与器材使用率统计模块是给实验员和管理员看的做得好非常出彩。我实现了两个维度的统计借用次数排行榜和器材使用率统计。排行榜的实现比较简单对借用记录表按器材ID分组统计每个器材的借用次数连表查出器材名称按次数倒序排列取前10条。这个SQL写出来几乎不用后端处理SELECT e.id, e.name, COUNT(br.id) AS borrow_count FROM borrow_record br LEFT JOIN equipment e ON br.equipment_id e.id WHERE br.deleted 0 GROUP BY e.id, e.name ORDER BY borrow_count DESC LIMIT 10器材使用率稍微复杂一点需要同时考虑借出次数和器材总数。我设计了一套计算口径跟实验中心的老师聊过之后确认这个口径是符合实际管理需求的器材使用率 该器材累计借用次数 / 该器材总数量。单次借阅全部库存就算一次满负荷使用。虽然这个口径不是绝对严谨但它能直接反映哪些器材使用频繁哪些器材常年闲置对采购决策有参考价值。4.2 图表展示与前端渲染方案图表这块我前后对比了两个方案。一是用ECharts展示图表美观且交互体验好但需要异步加载数据二是用纯CSS加HTML画简易条形图实现简单对服务端渲染项目更友好。最终我选择了ECharts。原因也很实际ECharts的引入并不复杂通过官方CDN引入一个echarts.min.js文件就行。后端返回JSON数据前端用fetch请求拿到数据之后用setOption方法填充图表。图表这样做出来的效果非常直观柱状图加折线图混搭视觉冲击力强答辩演示的时候观感好这属于投入产出比很高的表面功夫。有一件事必须提醒数据接口返回的JSON里不要直接返回数据库实体对象尤其是用户表里的密码字段。我当时封装了一个VO类只返回图表需要的字段顺便复习了VO和实体类分离的重要性。前端拿到手的数据结构清晰也对安全性有好处。统计模块的定时刷新没有做因为这个系统是内网部署的课程设计数据刷新频率不需要太高。每次进入统计页面时重新拉取数据就够了加上一个刷新按钮手动刷新即可。真实的生产环境可以考虑用定时任务或者Redis缓存来优化这些作为优化方向写在开发文档里答辩的时候也有话可说。5. 开发过程中的典型问题与排查记录5.1 库存超卖问题从应用层到数据库层前面提到过的库存超卖问题这里展开细说。最早我是在Service里判断可用数量判断通过后执行update扣减。学生那边两个人同时操作测试的时候真的复现了库存变成负数的情况。这种问题在演示的时候被发现是非常尴尬的我当时立刻排查定位到是先Query再Update这个模式有竞态窗口直接把判断逻辑合并到Update里解决了。除了SQL层解决我还在用户提交借用按钮上加了前端防重复点击。点击之后按钮置灰1秒内不可重复点击。这个技巧简单有效我建议所有涉及写操作的按钮都加上。虽然前后端双重防护看着多余但实际场景里用户双击提交是很容易发生的。5.2 日期区间查询的边界条件借阅记录的按时间筛选功能是我调试时间最长的一个点。一开始前端传过来的是两个字符串日期我在SQL里用BETWEEN去比较结果查询结果总是少一天。举个例子选了2024年5月1日到2024年5月10日结果5月10日当天的记录查不出来。问题出在日期和时间的转换上。前端的日期选择器默认传的是2024-05-10后端解析成日期之后如果直接跟数据库里的datetime字段比较datetime字段会带上时间部分2024-05-10 09:23:45所以日期会被当成2024-05-10 00:00:00当天的记录自然不包含在内。解决办法是把结束日期加上一天然后用左闭右开的区间条件用和来比较。这个细节很多人会在真实项目中碰到属于典型的差一天问题。5.3 外键约束与数据删除的冲突在设计初期我在借用记录表和器材表之间建了外键。后来测试删除器材功能时发现只要这个器材有过借用记录删除就报外键约束错误。本来我想的是先删借用记录再删器材但这样会丢失历史数据与我保留审计轨迹的需求冲突了。最终我决定去掉数据库外键改为在Service层做业务校验。删除器材的时候先查是否有未归还的借出记录有的就拦截并提示没有的就执行逻辑删除。这个取舍是一个典型的架构设计服务于业务需求的案例写进文档里很有说服力数据库外键保证的是引用完整性业务校验保证的是业务规则的完整性两者选其一优先满足业务规则。5.4 账号越权访问与权限漏洞开发过程中我专门测试过一个场景普通学生用户手动在浏览器地址栏输入管理端的URL能不能绕过前端菜单直接访问管理页面。结果是第一次还真能访问因为后端接口没有做角色校验前端只是隐藏了管理入口这不能算真正的安全控制。修复方案是在拦截器里加角色判断管理端路径请求必须是管理员角色才放行否则返回403。这个测试给了我一个很重要的教训前端控制只能提升体验后端校验才是安全屏障。课程设计里的这个点其实很加分说明开发者有安全意识不是只会写业务代码。6. 测试、演示与课程设计答辩准备6.1 自测用例设计与数据准备做完系统功能之后我没有急着部署答辩而是先设计了一份功能测试清单。测试用例需要覆盖正常流程、异常流程和边界情况。正常流程是登录→借器材→看个人记录→归还异常流程是借库存不足的器材、未登录访问管理端、删除有未归还记录的器材边界情况是借器材数量为0或负数、归还已归还的器材、选择跨月的日期区间查询。数据准备上我造了一份比较有层次的数据集。器材品类覆盖了电子类、机械类、光学类、化学类四个大类每个大类下面放了3到5个具体器材库存数量也从1到20不等有的够用有的故意设置了少量库存用于测试不足场景。借用记录造了50多条时间分布在一个季度内既有已归还的记录也有未归还的记录还造了两条故意逾期的记录。这样演示统计报表的时候图表有数据支撑不会像刚部署的空系统那样看起来干巴巴的。6.2 演示流程的设计思路答辩演示环节很多人会直接从头到尾把系统点一遍看似完整实则平铺直叙老师记不住重点。我是反着设计的先讲痛点再讲解决方案一上来就用一组对比数据说明人工登记方式的问题然后引出系统里的器材列表和库存状态顺势演示一次完整的借还过程。演示的时候我重点展示三个细节第一个是借出后器材列表的可用数量立即减少第二个是归还后数量恢复且记录状态更新第三个是手动造一次库存不足的借阅申请让系统给出明确提示。这三个细节恰好覆盖了系统最核心的业务规则比按页面顺序点一遍更有说服力。6.3 答辩前要准备的几个技术问题根据多次答辩的经验老师问的问题基本集中在几个方向为什么选这套技术栈、数据库为什么这样设计、如何处理并发问题、系统有什么安全措施、后续如何扩展。我在答辩前把这些问题做成了一张速查表问题方向回答要点展开内容技术栈选择生态成熟、资料多、一人开发效率高对比过前后端分离方案最终选服务端渲染数据库设计三张核心表加用户表重点讲解总量与可用量分离的设计理由并发问题条件更新保证原子性演示超卖复现和修复前后的对比安全措施密码加密、拦截器权限控制、参数校验提到防SQL注入和逻辑删除扩展方向审批流、消息通知、数据可视化大屏说明在现有表结构上可以平滑演进这套准备方案的目标不是让老师问到一句答一句而是每个回答都能主动引出自己项目的亮点。比如问安全措施的时候我顺便讲了一下拦截器放行规则的细节老师就能感受到这个项目确实是自己从零做的不是从网上随便下载的。最后再分享一个我个人的习惯课程的文档、SQL脚本和演示录像一定要整理齐全。答辩的时候把Git提交记录打开放在屏幕上能够直观展示项目的开发过程这个细节和实践时间远比口头讲述有说服力。系统完成之后的体验是很有成就感的尤其是看到自己设计的页面在真实场景里跑通业务流程的时候。做课程设计与其追求功能数量不如把一个主流程做到极致所有功能闭环、逻辑自洽答辩的时候自然会从容很多。