简介这是一份基于JSPSSMSpring、Spring MVC、MyBatis的智能出差报销管理系统课程设计项目面向高校计算机专业学生及需要完成Java Web实践课题的开发者。系统围绕企业出差报销场景实现了用户权限管理、出差申请与审批、报销单创建提交、多级审批、报表统计与系统维护等功能可帮助理解SSM框架整合与JSP动态页面开发。资源包共10个文件约89.63MB内含项目源码压缩包、MyEclipse工程文件、Navicat可导入的SQL数据库脚本、Word需求分析文档、开发报告、操作演示视频AVI、界面截图PNG及环境配置说明资料结构完整。目前已有47人学习下载。借助这份资料既能直接运行体验系统效果也能对照开发报告梳理需求分析、框架配置、接口设计与部署流程尤其适合作为课程设计参考或SSM入门实战素材。1. 智能出差报销管理系统是什么一份 SSM 课程设计源码包背后的完整闭环期末前一周你大概率会碰到这么个东西一个名为“课程设计-jsp2180智能出差报销管理系统ssm-qlkrp.zip”的压缩包。拆开压缩包里面是 Spring Spring MVC MyBatis 搭建的 Java Web 项目前端用 JSP 渲染页面数据库脚本和部署说明一起打包。这套系统解决的是一个非常典型的业务场景员工出差前申请、出差中记录费用、回来后填报报销单部门审批、财务打款每一步都有状态记录。适合正在做 JSP/SSM 课程设计的学生、要二开毕设的开发者以及刚学完框架想找一个完整业务闭环练手的人。这个方向最容易被低估的一点是它表面上是一堆增删改查真正值钱的部分在于报销单状态机、费用标准自动校验和登录拦截那百分之三十的代码。下面从解压源码包开始把整个项目从跑通到演示完整过一遍。2. 从 zip 到可运行SSM 项目结构与跑通首页的完整步骤2.1 解压后先核对四样东西目录分层、SQL、配置和依赖拿到压缩包先别急着往 Tomcat 里扔。我一般先按“Maven 工程还是普通 Web 工程”来分类。绝大多数 SSM 课程设计是 Maven 工程解压后第一件事是确认以下几个目录和文件齐全course-design-ssm ├── pom.xml ├── sql/qlkrp.sql ├── src/main/java/com/qlkrp │ ├── controller │ ├── service │ ├── mapper │ ├── entity │ └── interceptor ├── src/main/resources │ ├── jdbc.properties │ ├── spring-mvc.xml │ ├── applicationContext.xml │ └── mybatis-config.xml └── src/main/webapp ├── WEB-INF/views ├── static └── index.jsp先检查 pom.xml 是否引入了 spring-webmvc、mybatis、mybatis-spring、mysql-connector-java 这些核心依赖再看 sql 目录里有没有建库建表脚本。这两样东西缺一个后面都要花大量时间返工。课程设计项目有一个通病pom.xml 里版本的兼容性非常脆弱。常见的翻车组合是 Spring 5.x 配 MyBatis 3.5.x 没问题但把 druid 连接池版本从 1.1.10 随手改成 1.2.x 后连接池初始化反而报错。所以解压后第一步我建议打开pom.xml确认 spring 版本和 mybatis-spring 版本是否在官方兼容区间内。这一步能省掉后面一晚上的排查时间不要跳过。检查这三样之后把项目以 Maven 方式导入 IDEA 或 Eclipse等依赖下载完毕再进下一步。2.2 SSM 常用注解与三大配置文件扫一眼就知道项目能不能跑SSM 的配置分三条线理解这三条线就能快速定位问题。Spring 管业务 BeanSpring MVC 管 Controller 和请求映射MyBatis 管数据库会话和 Mapper。配置文件里最常改的是jdbc.properties几乎每个课程设计项目的数据库连接都跟这里相关jdbc.drivercom.mysql.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/qlkrp?useUnicodetruecharacterEncodingutf8 jdbc.usernameroot jdbc.password123456这段配置的注意点有两个。第一MySQL 8.x 以上驱动类名应该用com.mysql.cj.jdbc.Driver如果项目里是 8.x 驱动却写着com.mysql.jdbc.Driver启动就会报 ClassNotFoundException。第二characterEncodingutf8必须写否则页面和数据库之间中文乱码的戏码会反复上演。扫完jdbc.properties再看spring-mvc.xml核心是开启注解驱动和视图解析器mvc:annotation-driven / context:component-scan base-packagecom.qlkrp.controller / bean classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/views/ / property namesuffix value.jsp / /beanprefix和suffix决定了 Controller 里 return expense/list 最终映射到哪个物理文件。很多项目 404 不是拦截器问题而是视图路径写错这个后面细说。SSM 常用注解属于那种“背了不一定懂懂了就再也忘不掉”的知识点。我把课程设计里出现频率最高的几个整理成一张表照着对项目里的代码就能明白整个调用链注解作用常见位置Controller标记这是一个 Spring MVC 控制器Controller 类上RequestMapping配置 URL 与方法或类的映射关系可限定 methodController 类或方法上ResponseBody把返回值序列化成 JSON 写回响应体方法上常用于 Ajax 接口Service标记业务层组件交给 Spring 容器管理Service 实现类上Repository标记数据访问层组件Mapper 实现类上Autowired按类型自动注入依赖Service 注入 Mapper、Controller 注入 ServiceTransactional声明事务边界报错自动回滚Service 方法或类上扫配置和注解时有一个很土但很有效的办法把项目跑起来看到控制台“Starting Servlet Engine”之后用浏览器访问首页。如果首页能出说明 Spring 容器和 Spring MVC 基本正常如果首页出不来优先回去查依赖冲突和spring-mvc.xml的 component-scan 路径。2.3 本机启动顺序Tomcat 部署和访问路径的常见问题配置核对完就可以启动了。常见做法是用 IDEA 的 Tomcat 插件直接跑。Deployment 类型建议选war exploded不需要先打 war 包热部署也更灵活。Application context 里填什么决定了你访问系统的 URL 前缀。一个血泪经验是如果 Application context 填了/qlkrp那么登录页的访问地址就是http://localhost:8080/qlkrp/login.jspController 里所有重定向都要写成redirect:${pageContext.request.contextPath}/login或者用redirect:/由框架自动补 context path。很多同学把项目跑起来之后表单提交的 action 里硬编码了/login实际部署路径却带上/qlkrp结果提交请求 404这就是典型的 context path 不匹配。启动顺序上我建议这样做先在 IDEA 里配置好 Tomcat再启动 MySQL 并执行sql/qlkrp.sql最后启动 Tomcat。如果 Tomcat 比 MySQL 先启动等页面触发第一个数据库查询时连接池可能因为初始连接失败而不稳定虽然 MyBatis 一般会重试但课程设计答辩时最容易因为这种时序问题当场翻车。确认项目启动后用默认账号走一遍登录。这一步能通过说明配置、数据库连接和 Controller 三个环节全部打通后面就是要看业务逻辑本身了。3. 报销状态机与智能校验核心表设计与 MyBatis 映射3.1 报销单的五态流转草稿、提交、审批、打款、驳回智能出差报销管理系统里的“智能”二字主要落在两个地方费用标准的自动校验以及审批流程的自动路由。流程上报销单从创建到完成最常出现的状态定义是 0 草稿、1 待部门审批、2 待财务审批、3 已打款、4 已驳回外加一个 5 已撤回。这个状态机决定了所有按钮能不能点、页面显示什么操作列。为什么状态值要用 int 而不是字符串因为判断分支时bill.getStatus() 1比PENDING_APPROVAL.equals(bill.getStatus())更直观而且数据库索引对 int 更友好。缺点是过一周之后你再看代码可能想不起来 2 是什么含义所以建议在实体类里用常量或者枚举把状态名定义出来public class ExpenseBill { public static final int STATUS_DRAFT 0; public static final int STATUS_DEPT_APPROVAL 1; public static final int STATUS_FIN_APPROVAL 2; public static final int STATUS_PAID 3; public static final int STATUS_REJECTED 4; public static final int STATUS_WITHDRAWN 5; private Integer id; private Integer userId; private BigDecimal totalAmount; private Integer status; }课程设计答辩时评审老师最爱问的问题就是“如果用户提交后又在待审批状态改金额怎么办”。所以在 Service 里做状态守卫是必须的只允许从草稿状态提交从待审批状态撤回从审批状态驳回。状态机的每一条边都是显式校验出来的不能直接裸写UPDATE ... SET status ?。3.2 三张核心表与 resultMap联表查询避免 N1报销系统的表结构有几个经典设计报销单主表expense_bill、费用明细表expense_detail、审批记录表approval_record再加一个部门或员工的sys_user。主表存总金额和状态明细表存每一笔费用审批记录表存审批链路上每一步的操作人、结果和意见。MyBatis 里最匹配这种结构的是resultMap的collection标签。从主表查明细时如果用了association加collection的组合一条 SQL 就能把主单信息和明细列表全部查出来避免循环里反复查数据库造成的 N1 问题resultMap idbillDetailMap typecom.qlkrp.entity.ExpenseBill id columnid propertyid / result columntotal_amount propertytotalAmount / result columnstatus propertystatus / collection propertydetailList ofTypecom.qlkrp.entity.ExpenseDetail id columndetail_id propertyid / result columndetail_type propertytype / result columnamount propertyamount / /collection /resultMap select idselectBillWithDetail resultMapbillDetailMap SELECT b.id, b.total_amount, b.status, d.id AS detail_id, d.type AS detail_type, d.amount FROM expense_bill b LEFT JOIN expense_detail d ON b.id d.bill_id WHERE b.id #{billId} /select这里最关键的是列别名。主表和明细表都有id列如果不分别写成detail_id和idMyBatis 会分不清哪个 id 对应主表哪个对应明细resultMap 直接解析错乱。这个坑我在实际项目里见过不止一次现象是查出来的明细数量不对或者主表 id 被覆盖成明细 id。3.3 智能金额试算超标自动校验与职级审批“智能”的另一个落点是费用标准的自动试算。比如住宿标准按城市分级一线城市每天 450 元二线城市每天 350 元超出部分提示“需分管领导特别审批”。这类逻辑写死在 Java Service 里比写在 SQL 里更直观也更容易做单元测试。这里给出一个常见的提交报销单的 Service 写法它把金额汇总、超标校验和状态流转合到一次事务里Service public class ExpenseBillService { Autowired private ExpenseBillMapper billMapper; Autowired private ExpenseDetailMapper detailMapper; Transactional(rollbackFor Exception.class) public Result submitBill(Integer billId, Integer userId) { ExpenseBill bill billMapper.selectById(billId); if (bill null || !bill.getUserId().equals(userId)) { return Result.fail(报销单不存在或不属于当前用户); } if (bill.getStatus() ! ExpenseBill.STATUS_DRAFT) { return Result.fail(只有草稿状态的单据才能提交); } BigDecimal total detailMapper.sumAmountByBillId(billId); boolean overStandard isOverStandard(bill, total); bill.setTotalAmount(total); bill.setOverStandard(overStandard); bill.setStatus(overStandard ? ExpenseBill.STATUS_FIN_APPROVAL : ExpenseBill.STATUS_DEPT_APPROVAL); billMapper.updateStatus(bill); return Result.ok(提交成功); } }这段代码里三个参数值得说透。第一Transactional(rollbackFor Exception.class)指定了任何异常都回滚防止总金额计算一半就提交成功造成明细和主表对不上账。第二提交前先查状态这是第三节说的状态机守卫别把这段删掉图省事。第三updateStatus只更新 state 字段不要连带更新 total_amount 之外的其他字段避免并发覆盖。超标的报销单直接跳到财务审批这就是“智能路由”的最小实现。如果演示时需要展示这个“智能”分支准备一条住宿费超标的测试数据即可。这也是答辩时最加分的演示路径之一。4. JSP 前端三个现场问题个人信息展示、加载刷新和 Element 图标4.1 JSP 个人信息展示页面session 取值和空指针防御SSM 项目里的 JSP 页面和现在前后端分离的 Vue 项目体验完全不同JSP 拿登录用户信息通常是从 session 里取。课程设计常见的写法是登录成功后把用户对象塞进 session然后页面顶部展示“欢迎张三”这样的个人信息。这里最容易翻车的地方是session 里取出来是 null。页面直接渲染还只是显示空白如果脚本里调用user.getName()直接抛空指针异常整个 JSP 变 500 错误页。比较稳的写法是在页面顶部先做一次非空判断% page contentTypetext/html;charsetUTF-8 % % User loginUser (User) session.getAttribute(loginUser); if (loginUser null) { response.sendRedirect(request.getContextPath() /login.jsp); return; } %这段代码在页面渲染前拦截未登录访问同时避免了loginUser.getName()的空指针问题。request.getContextPath()会自动拼上部署路径不管打成/qlkrp还是根路径重定向都不会写死。从这也能看出 JSP 个人信息展示页面最容易被忽略的一点JSP 是服务端渲染session 里的值在页面跳转过程中要保持一致前提是登录拦截器对 /login 放行、对其他页面统一拦截。前面 2.2 节提到拦截器相关问题这二者配合不好就会出现“登录成功却仍然被迫跳回登录页”的闹剧。4.2 JSP 页面让加载完后刷新一次sessionStorage 守卫的写法有同学会遇到一个场景报销单提交成功后跳转到列表页但列表数据还是旧的必须手动刷新一次才能看到最新状态。原因通常是跳转是转发而不是重定向浏览器没有重新发起请求或者提交后返回的数据被前端缓存住了。“加载完后刷新一次”这个需求在 JSP 里有一个很实用的写法script if (!sessionStorage.getItem(expense_refreshed)) { sessionStorage.setItem(expense_refreshed, 1); location.reload(); } /scriptsessionStorage的作用域是当前标签页关掉标签页再打开就失效。所以这段逻辑放在列表页顶部只在从提交页跳转过来的这一次生效刷新完成后标记写入下一次进入不会再形成刷新死循环。为什么不用localStorage因为localStorage是持久化的用户关浏览器再打开expense_refreshed仍在就永远不再自动刷新了。既然要的是“加载完后刷新一次”sessionStorage配合location.reload()是语义最准确的组合。这个技巧在课程设计演示时相当实用因为评审老师看到的是“提交完自动出现最新列表”背后只是这一行守卫逻辑却能让整个演示流畅度上一个档次。4.3 Element 图标在 JSP 里的引法CDN 和字体路径的坑“饿了么 Element 图标前端 JSP”这个点本质上是在 JSP 页面里引入 Element UI 的图标资源。课程设计项目一般不会完整引入 Vue但很多人会单独引入 Element 的样式文件只为用它的图标。最省事的引法是 CDNlink relstylesheet hrefhttps://unpkg.com/element-ui/lib/theme-chalk/index.css把这段放在 JSP 的head里页面上就能用i classel-icon-search这类图标。但是这里有一个非常隐蔽的坑index.css里字体文件用的是相对路径../fonts/element-icons.woff。如果直接 CDN 引入没问题因为浏览器能正确解析 unpkg 上的相对路径但如果把 CSS 下载到本地放进webapp/static/css字体文件必须放在webapp/static/fonts保持和 CDN 相同的目录层级否则图标全部显示为方块。答辩现场往往没有外网所以更稳妥的做法是本地化整个 theme-chalk 目录而不是只下载一个 CSS。此外还有一个 JSP 特有的坑CSS 里通过 url() 引用的字体文件在 JSP 里不会经过 EL 表达式解析所以不需要也不应该写成${pageContext.request.contextPath}/static/fonts保持相对路径即可。很多人在这里绕弯子其实字体加载不上大概率只是物理路径不对。5. SSM 项目避坑乱码、404 和重复报销的四类典型问题5.1 现象页面上一片问号数据库存储也是乱码原因JSP 页面本身是 UTF-8但请求到达 Controller 前没有经过编码过滤器或者 Tomcat 接收到 POST 请求时默认按 ISO-8859-1 解码表单里的中文到后端已经变了形。解决在web.xml里注册 Spring 的编码过滤器放在所有过滤器最前面filter filter-nameencodingFilter/filter-name filter-classorg.springframework.web.filter.CharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param init-param param-nameforceEncoding/param-name param-valuetrue/param-value /init-param /filter filter-mapping filter-nameencodingFilter/filter-name url-pattern/*/url-pattern /filter-mappingforceEncoding设为 true 很关键它强制请求和响应都使用 UTF-8你就不用再去每个方法里手动写setCharacterEncoding。另外数据库连接串里的characterEncodingutf8也要保留三层统一乱码问题才真正根除。我之前见到有人只配了过滤器没改 JDBC 连接串结果页面显示正常、入库还是乱码排查半天才发现是连接串的问题。5.2 现象登录成功后跳转任意页面都 404原因拦截器拦截的路径和 Spring MVC 请求映射不一致或者静态资源被拦截后没有放行。课程设计里经常出现“页面样式全丢”“登录后点菜单跳 404”的反馈二者都指向拦截器配置。解决在spring-mvc.xml中把静态资源和登录相关路径放进白名单mvc:interceptors mvc:interceptor mvc:mapping path/** / mvc:exclude-mapping path/login / mvc:exclude-mapping path/login.jsp / mvc:exclude-mapping path/static/** / mvc:exclude-mapping path/captcha / bean classcom.qlkrp.interceptor.LoginInterceptor / /mvc:interceptor /mvc:interceptors路径匹配有个细节/**能匹配多级目录/*只能匹配一层。如果你的页面在/WEB-INF/views/expense/list.jsp这种多层路径下拦截器用/*是会漏掉的。这两个通配符的区别是很多拦截器“放行了却没完全放行”的常见原因。5.3 现象连续快速点击提交按钮数据库里出现两条相同报销单原因前端没有防重复点击后端也没有做幂等校验。提交前读到的 status 都是草稿两次请求都通过了状态校验。解决后端靠状态守卫降低并发风险前端靠按钮置灰配合。document.getElementById(submitBtn).disabled true;但这只是体验层面的防护。要真正防住推荐在提交接口里用“状态等于草稿”作为更新条件UPDATE expense_bill SET status 1 WHERE id #{billId} AND status 0这条 SQL 的WHERE status 0就是幂等保护第二次更新影响行数为 0Service 里判断返回行数即可拒绝第二次提交。这个方案比单纯前端置灰可靠得多因为接口是能被绕过的。5.4 现象按日期区间查报销单边界日期数据对不上原因实体类里日期字段用了 String数据库里存的是 datetime查询时拼接的字符串格式和数据库字段默认格式不一致导致比较结果失准。比如数据库存2024-06-08 10:30:00前端传2024-06-08MySQL 做字符串比较时会把值按字典序处理边界判断就会出问题。解决日期字段在实体类里用java.util.Date或java.time.LocalDateController 接收前端参数时用DateTimeFormat(pattern yyyy-MM-dd)做解析RequestMapping(/list) public String list(RequestParam DateTimeFormat(pattern yyyy-MM-dd) LocalDate startDate, Model model) { ListExpenseBill bills billMapper.selectByDateRange(startDate.atStartOfDay(), startDate.plusDays(1).atStartOfDay()); model.addAttribute(bills, bills); return expense/list; }另外注意 MyBatis 里如果用了${}拼日期字符串既有 SQL 注入风险又容易出现格式歧义。一律用#{}传参让 PreparedStatement 处理日期类型2024-06-08才能被正确识别为日期边界而不是字符串。6. 交付前把系统跑成可演示状态四个验证动作6.1 演示前必做的流程自检课程设计答辩前一天不要再看代码了把系统当成黑匣子从用户视角完整走一遍流程。准备一个普通员工账号和一个审批人账号按顺序操作新建报销单、添加三条费用明细、提交、部门审批通过、财务审批通过、打款。每一步都要观察页面跳转、金额显示和状态变化任何一个环节断掉都是答辩现场的高危点。注意验证一下超标金额分支把一条住宿明细金额超标提交后看系统是否自动路由到财务审批并且给出提示。这个分支不验证演示时就等于赌运气。6.2 参数核对与日志定位启动时盯住 IDEA 控制台看到“Exception”或“WARN”不要放过很多问题不会直接让系统挂掉只会让某个功能静默失效。比如 MyBatis 的MapUnderscoreToCamelCase没开total_amount映射不到totalAmount页面金额显示 0.00日志里却只有一行不痛不痒的 DEBUG。再核对一遍jdbc.properties里的时区和编码参数这也是演示现场数据库时间显示异常的最常见来源。我自己的习惯是演示前一天把 SQL、部署说明和测试账号整理到一页 README 里放进压缩包重新打包这样即使换一台电脑照着说明也能在三分钟内把系统跑起来。最后一个建议把所有演示用的测试数据做成一键脚本。这样即使现场数据被改乱也能随时重置回演示状态这比带着一份文档到处找数据要省心得多。我在第一次带课程设计时就是没做这件事结果现场把一条关键数据删掉后怎么也恢复不了只能硬着头皮切换分支演示。从那之后我做任何演示项目都会把造数据脚本放在 SQL 文件的第一段注释里用的时候直接执行。希望这些经验能帮你在交付和答辩时少踩几个无声无息的坑把时间和精力留在真正值得展示的功能上。本文还有配套的精品资源点击获取