做Java后端这些年，经常会遇到一个很现实的问题：业务并不复杂，但信息全靠纸质单据和口口相传，尤其是中小型汽车修配厂，接车、派工、领料、结算、回访，链条一长就乱。我之前帮一家维修厂做过一套基于SSM+JSP的汽车修配厂信息管理系统，今天把整套思路、设计取舍和踩过的坑整理出来，项目本身覆盖了Spring、SpringMVC、MyBatis、JSP这些JavaWeb阶段最核心的技术点，当作课程设计、毕业设计或者想系统梳理SSM开发流程的练手项目都很合适。
这套系统听起来名字很“校园”，但它解决的问题非常实际：修配厂老板想知道今天有几台车在修、每台车用了什么配件、哪位师傅在跟进、月底该给谁结账。把这些问题落到系统里，本质上就是一套围绕“维修工单”和“配件库存”两条主线的数据管理。文章后面我会直接给出模块拆分、表结构设计、核心代码实现思路，以及我在实际开发里遇到的事务、分页、文件上传等高频问题，尽量让读者拿到就能动手。
1. 修配厂信息系统的核心业务需求拆解
1.1 维修业务在修配厂的真实流转过程
在写代码之前，第一件事是把线下业务捋清楚。我去调研的时候发现，修配厂的一天大概是这样的：客户开车进厂，前台登记车主信息和车辆信息，检查车辆后由维修顾问开具维修单，列明故障描述、维修项目、预计费用；然后维修单派给维修班组，班组在维修过程中需要从仓库领取配件，领料单要登记；完工后由质检人员验收，接着是结算，客户付款后开具结算单；如果客户有长期合作关系，可能还有会员卡、挂账、回访记录等。
所以这个系统里“维修工单”是绝对的核心主线，工单上承载的信息包括车辆信息、客户信息、维修项目、维修班组、配件明细、工时费、配件费、总金额、状态节点。配件库存则是另一条辅助主线，领料会扣减库存，采购入库会增加库存，两者结合才能保住修配厂不被呆滞库存吃利润。
很多新手做这类系统时容易犯一个错误：一上来就设计一堆表，客户表、车辆表、工单表、配件表、库存表、员工表、结算表等等，表之间硬关联，反而把业务顺序弄丢了。我更建议的做法是：先用业务流程图把“接车—派工—领料—结算—回访”的状态机画清楚，再反推表结构和页面结构。
1.2 SSM+JSP这套组合为什么至今仍有生命力
提到SSM（Spring+SpringMVC+MyBatis）和JSP，有人会觉得过时了，毕竟现在Spring Boot加Vue前后端分离才是主流。但说句实话，国内大量中小型企业内部系统、高校课程设计、软件外包项目，依然在用SSM加JSP这套结构。原因很直接：它足够轻量、入门曲线平缓、资料多到几乎任何报错都能搜到解决方案。
用SSM而不是Spring Boot做这个项目，还有一个学习价值上的考虑：SSM是手写配置的，Spring容器怎么初始化、SpringMVC的DispatcherServlet如何接管请求、MyBatis的Mapper代理怎么生效，这些核心机制在拆配置的时候会被逼着搞清楚。一旦跑到Spring Boot里，一切都自动装配了，反而少了一层“原来如此”的体验。
JSP在页面层面的优势是服务端渲染，ModelAndView把数据塞进request域，JSP用JSTL和EL表达式直接渲染，刷新页面就能看到数据库的变化。对于修配厂内部的进销存和工单管理这类交互不算复杂的系统，这种模式比前后端分离开发效率更高，不用联调接口，也省去了跨域和Token鉴权的问题。
2. 系统整体设计与技术选型拆解
2.1 功能模块划分：按角色拆解最清晰
系统功能模块的划分方式直接决定开发量和管理体验。我当时没有按传统“增删改查”来凑功能，而是按修配厂里的角色来规划，因为角色决定了权限和操作入口。
- 管理员端：员工账号管理、基础数据维护（车型、配件类别、维修项目价格表）、数据统计报表
- 前台/接待端：客户登记、车辆登记、创建维修工单、结算收费、回访登记
- 维修班组端：查看分配给我的工单、领用配件、填写维修进度、完工提交
- 仓库端：配件入库、出库审核、库存预警、库存盘点
四个角色的需求对应到后台功能，就变成了：用户管理、客户管理、车辆管理、维修工单管理、维修项目管理、配件管理、库存管理、结算管理、统计报表、操作日志。每个模块之间通过工单ID和客户ID关联，形成数据闭环。
这样拆完以后，页面的规划也跟着清晰了：登录页、主框架页（左侧菜单、右侧内容区）、客户管理列表页和编辑页、车辆管理页、工单管理页（工单列表、工单详情）、配件管理的库存页、入库页、出库页、统计报表页。每个页面都是典型的JSP加JSTL渲染，结构统一，后期维护成本很低。
2.2 技术架构：SSM三层结构如何落在项目里
这套系统的代码毫无疑问是三层结构：表现层、业务层、持久层。SpringMVC负责表现层，Controller接收请求、调Service、返回ModelAndView；Spring负责Service层的Bean管理和事务；MyBatis负责数据访问，Mapper接口加XML文件完成SQL操作。
具体落地的工程结构我习惯这样分：
controller：接收前端请求，校验参数，调用serviceservice：业务逻辑处理接口和实现类，事务注解基本加在这一层dao：MyBatis的Mapper接口entity：数据库表对应的实体类vo：页面展示用的视图对象，比如工单列表需要同时展示客户名、车型、维修状态，直接查VO更省事interceptor：登录拦截、权限拦截util：分页工具、日期工具、生成编号工具
一个典型请求的流转路径是：浏览器发起请求到SpringMVC的DispatcherServlet，HandlerMapping找到对应Controller方法，Controller调用Service接口，Service实现类里调用Mapper接口，MyBatis执行SQL并返回结果，Service返回VO对象，Controller把它放进ModelAndView，最后交给JSP渲染成HTML响应给浏览器。
这套链路如果能闭着眼画出来，再去写具体代码就只是“填空”了。很多初学者卡住，其实是没理解SpringMVC的前端控制器模式，老以为Controller就是入口，实际上入口是DispatcherServlet，它负责分发。
2.3 数据库设计：核心表结构与字段规划
我先画出核心表，再逐个说明为什么要这么设计。表不能随手建，字段之间要形成关联，还要兼顾查询效率。
| 表名 | 用途 | 关键字段 |
|---|---|---|
| t_user | 系统用户 | id, username, password, real_name, role_id, phone |
| t_role | 角色表 | id, role_name, description |
| t_customer | 客户信息 | id, customer_name, phone, address, member_level |
| t_car | 车辆信息 | id, customer_id, plate_no, brand, model, vin, engine_no |
| t_maintenance_order | 维修工单 | id, order_no, car_id, customer_id, status, description, assignee, total_amount, create_time, finish_time |
| t_maintenance_item | 维修项目 | id, order_id, item_name, work_hour_fee, price |
| t_part | 配件基础信息 | id, part_no, part_name, category, unit_price |
| t_part_stock | 配件库存 | id, part_id, quantity, safe_stock |
| t_part_inout | 配件出入库记录 | id, part_id, type, quantity, ref_order_id, operator_id, create_time |
| t_settlement | 结算记录 | id, order_id, total_amount, discount, actual_amount, pay_method, create_time |
客户和车辆是分开设计的，因为一个客户名下可能有多个车，比如一个做物流的小老板，三台货车都在这里保养，这时候客户表与车辆表一对多就非常合适。工单表冗余了customer_id，是为了结算和统计时减少联表。
维修工单和维修项目是一对多，一个工单里可能有多个维修项目，比如“更换机油”加上“四轮定位”。维修项目和配件没有直接做成关联表，而是通过工单领料记录去关联，因为实际场景中同一种配件可能用在多个工单，一个工单也可能领多种配件。
配件库存表单独抽出库存量字段，是因为配件基础信息和库存量分开，配件信息维护的是“价目表”，而库存量是动态变化的，每次出入库都去更新基础表容易造成并发更新问题。出入库记录表则是流水账，用于追溯“这个配件什么时候入的、谁领走的、用到了哪个工单上”，对财务对账特别重要。
3. 核心功能模块的落地实现
3.1 维修工单管理：从接车到完工的完整闭环
维修工单是系统里逻辑最复杂的模块。我先定义工单的状态流，再围绕状态去写代码。状态我设计成五个：待派工、维修中、待结算、已完成、已作废。
创建工单时，前台人员填写客户手机号，系统根据手机号自动带出已有客户信息，如果查不到就顺手新增客户。车牌号同样做联动查询，车辆属于哪个客户系统里会显示出来。选完车辆以后，录入故障描述和维修项目，这里设计了复选框加“添加自定义项目”的功能。提交后工单状态为“待派工”，同时生成唯一的工单编号，编号规则我用的格式是202506071001，前缀是年月日加当天流水序号。
派工环节，管理员或前台在工单列表点击“派工”，选择维修班组，工单状态变更为“维修中”，同时系统给对应班组账号下生成待办任务。维修班组登录后只能看见分配给自己的工单，这种列表筛选通过在Service层判断当前登录用户的roleId和assignee实现。
维修完成提交后，工单进入“待结算”。结算页面展示所有维修项目和配件明细，系统自动计算项目工时费加配件材料费，支持输入折扣比例，计算出折后金额和实际收款金额。结算完更新工单为“已完成”，同时生成结算记录存入结算表。
这里要注意：工单状态变更不能随便暴露在URL上，比如直接通过/updateStatus?orderId=1&status=3这种方式跳转，很容易被人篡改。我在代码里用的是一个专门的updateOrderStatus方法，每次变更状态前都校验当前状态和下一状态的合法性，比如“已完成”的工单不允许再回退到“维修中”。状态机的校验逻辑用switch或者状态枚举都行，我个人更推荐枚举，代码更清晰。
3.2 配件库存管理：出入库与预警逻辑
配件库存模块设计的目标只有一个：别让修配厂出现“前台收钱开单，仓库却找不到货”的尴尬。库存表的字段除了配件信息和数量，还有safe_stock安全库存量和update_time最后更新时间。
入库操作比较简单，仓库人员选择配件、填写入库数量、填写采购单价，系统更新库存并写入t_part_inout表，类型记为1（入库）。这里有一个细节：入库单号要和供应商结算挂钩，所以入库记录里我会加一个batch_no批次号，这个批次号用于后续对账，属于实际业务里很常用的设计。
出库操作必须关联工单，出库记录里的ref_order_id字段就是当前维修工单的ID，这样每个工单领了哪些配件，在工单详情页能直接展示出来，结算时也能把配件费汇总。出库时库存不足，系统不能直接抛异常，而是先做一次库存预检，返回“库存不足”的提示，同时显示当前库存量，方便仓库人员决定是采购补货还是换配件。
库存预警我用一个定时的小功能解决：在配件列表页面列出所有当前库存量小于安全库存量的配件，用一个红色标签标记。这个功能用一条SQL就能查出来，不复杂但非常有用，老板打开页面一看就知道哪些配件该补货了。
3.3 客户档案与车辆管理：数据从哪来，怎么关联
客户档案模块看起来是纯增删改查，但有几个点很容易被忽略。客户重复问题一定要处理，车辆和客户是绑定关系，前台输入手机号拉取客户时会自动搜索，但如果客户名输入两三次都没统一，就会出现“张三”和“张先生”这样两个重复档案，数据会越走越脏。我的做法是手机号作为客户唯一键，注册时做唯一校验。
车辆管理同样要防重，车牌号是天然的唯一标识，录入车辆时必须校验重复。如果车辆已经存在于其他客户名下，要明确提示“该车辆已绑定客户XXX”，避免后续结算和回访时出现扯皮。
客户回访记录我单独建了一张t_follow_record表，字段是客户ID、回访日期、回访内容、回访人。因为修配厂比较看重二回访，比如保养完两周后回访用着有没有问题，这个数据直接决定客户的复购率。虽然系统本身不复杂，但加上这个模块，整套系统在业务上会更完整。
3.4 员工登录与权限：多角色怎么控制
权限控制如果用Spring Security，配置会稍微复杂一些，对课程设计来说容易绕进去。我实际用的是拦截器方案：自定义一个AuthInterceptor，在SpringMVC配置里注册，拦截所有/admin/**路径的请求。
拦截器做的事情很简单：先从session里取当前登录用户，没取到就重定向到登录页；取到了再判断该用户角色是否允许访问当前请求的路径前缀。比如/admin/part/**只允许仓库角色和管理员访问，/admin/order/**允许接待、管理员、维修班组访问。这个判断在前端左侧菜单渲染时也做一遍，菜单按角色动态显示，后端拦截器再做一次兜底，双保险足够应付这套系统的场景。
登录密码我用的MD5加盐存储。虽然MD5不够安全，但在这个场景里比明文存储要好很多，而且加盐后碰撞难度也会提高。具体做法是注册时生成一个随机salt，最后保存的是MD5(password + salt)和salt两个字段。登录校验时取出salt再算一遍比对。
4. 开发过程里绕不开的坑与排查经验
4.1 SSM整合配置：jar包冲突与扫描遗漏
SSM整合的第一个拦路虎是配置本身。web.xml、spring-mvc.xml、spring-mybatis.xml三份配置文件要配合得严丝合缝，稍有不慎启动就报错。
我遇到最多的问题有两个：第一个是jar包冲突，典型的是MyBatis和Spring的版本兼容问题。以前用的老版本MyBatis-spring中间件和新版MyBatis主包会有兼容性问题，直接表现是Spring容器初始化报NoClassDefFoundError或者MapperBeanDefinitionParser找不到。我的建议是不要一股脑引入最新版，直接用MyBatis 3.5.x配mybatis-spring 2.0.x，这套组合经过大量项目检验。
第二个问题是SpringMVC容器扫描了Service层。SpringMVC的配置应该只扫描Controller层，Spring的配置扫描Service、Dao、Entity这些。如果不小心两个都扫描了，会出现事务不生效，因为Service被两个容器各实例化了一次，事务代理只在其中一个容器里生效。排查方法是在Service实现类里打日志看实例化的类名，如果后面带着$$EnhancerBySpringCGLIB说明走的是Spring代理，没有则说明配置有问题。
4.2 JSP页面与Java代码交互的坑
JSP开发里经典的问题是路径问题。部署后项目名是带上下文的，所以页面里所有的请求路径和资源引用都必须经过<c:url>标签或者${pageContext.request.contextPath}拼接，不然本地测试好好的，部署到Tomcat后CSS加载不出来、请求404。
还有一个经常踩的坑是EL表达式不生效。有些老项目的web.xml用的Servlet 2.3版本声明，EL表达式默认关闭，需要在JSP页首添加<%@ page isELIgnored="false" %>。更麻烦的是JSP 2.0以上版本对EL表达式的变量名规范更严格，如果request域里存了userInfo，${userInfo.name}能取到，但如果存的是user.info这种中间带点的键名，EL会把点解析成取属性，导致取不到值。命名时就应该避免在key里用点号。
JSP页面里尽量少写Java代码，<% %>字面量脚本虽然在JSP规范里合法，但会让页面非常难维护。用JSTL的<c:forEach>循环列表，用EL表达式取值，自定义函数或者简单的数据格式化用<fmt:formatDate>来解决。我一贯的原则是：ModelAndView里传给页面的数据已经有了所有展示需要的信息，JSP只负责循环输出和格式化，不做任何业务计算。
4.3 事务管理与数据一致性：从一次领料失败说起
我在测试领料功能时遇到过一个问题：如果同时发起“扣减库存”“写入出库记录”“更新工单配件明细”三个数据库操作，当第三个操作失败时，前两个操作已经提交了，就会造成库存扣了但工单上没有配件记录，账实不符。
SSM里事务默认不在每个Service方法上开启，需要在需要事务的方法上添加@Transactional注解。但注解加了不一定生效，最常见的坑是同类内部方法调用，比如ClassA的methodA调用本类的methodB，methodB上有@Transactional注解，这种情况下事务是不生效的，因为Spring的代理机制只拦截外部调用，内部调用直接走this对象，不走代理。
我在实际开发里的做法是将事务边界控制在Service实现类的最外层方法，并且拆分子Service类。领料这个方法我单独放到PartInOutService里，由它统一管理扣库存和写流水的原子性。如果事务失败回滚的代价比较大，比如一个工单里领了三种配件，我想让前两种成功的领料不跟着回滚，就在每个领料方法内部捕获异常并记录到错误表，由人工介入，这也是真实项目中常见的设计。
4.4 数据显示问题：日期格式化与金额精度
日期格式化在SSM项目里是个高频问题。后端返回java.util.Date，JSP页面直接${order.createTime}输出的是Tue Jun 07 10:28:51 CST 2025这种英文格式，很丑。解决方案有两种：一种是在JSP里用<fmt:formatDate value="${order.createTime}" pattern="yyyy-MM-dd HH:mm:ss"/>格式化，第二种是在实体类添加@JsonFormat注解，但因为我们是服务端渲染而不是返回JSON，所以更实用的方式是用JSTL格式化。
金额精度这里，数据库里我统一用decimal(10,2)类型，Java实体用BigDecimal接收。千万别用double或float，金额在结算时频繁加减乘除，浮点数误差会累积出钱数不对。计算工单总金额时，如果配件费和工时费都是BigDecimal，用add()方法相加而不是直接用+操作符。
5. 项目部署、测试与二次开发建议
5.1 本地开发到服务器部署的完整操作
本地环境建议直接用IntelliJ IDEA加Maven加Tomcat 8.5或9.0版本。JSP项目在IDEA里部署有一个坑：默认的Artifacts配置可能不包含lib目录下的依赖，启动时会报ClassNotFoundException，需要在Project Structure — Artifacts里把Available Elements中的依赖jar包添加进去。
配置数据源我用的是阿里Druid连接池，配置文件里注意数据库用户名密码不要硬编码，从jdbc.properties读取。Druid的监控页面非常实用，可以看到SQL执行次数和慢查询，排查性能问题时第一件事就是打开/druid/index.html看一眼。
打包部署的时候，我用的命令是mvn clean package，生成war包丢到Tomcat的webapps目录下。有一个特别容易被忽略的点：数据库连接配置文件在war包外单独放置。这样生产环境数据库地址变更时，不用重新打包，直接改外部配置文件并重启Tomcat即可。我踩过的坑是直接把jdbc.properties打进war包，结果客户换了数据库地址还要我重新给包，很被动。
5.2 后续扩展：从单体走向模块化
这套系统做完第一版能满足日常使用，但如果修配厂业务量上涨，有几个位置是可以优先扩展的。一个是进销存和财务对账，目前结算模块比较简单，没有应收应付的概念，实际上很多修配厂给企业客户是月结模式，这个要专门开发一个对账单模块。另一个是移动端报修，维修师傅在现场修车时打开手机就能申报完工和领料，效率会高很多。这个扩展方向不复杂，在后端加几个接口，前端做一个H5页面就行。
如果有人想在这个项目基础上继续深入，我的建议是把框架升级到Spring Boot加Vue前后端分离，服务端只暴露REST接口，这样前端可以做微信小程序或者钉钉工作台入口。但升级的前提是先把SSM版本里的业务逻辑梳理清楚，不要为了用新技术而重写业务，否则很容易把原来稳定的逻辑改出bug来。
6. 一些心里话与实际经验
这个项目最核心的价值不在技术难度，而在于“用工程的方式去解构一个真实业务”。修配厂的信息化管理本质上是车辆、客户、工单、库存、结算这几条线如何高效串联的问题。做这套系统的过程，前端后台、数据库、权限、事务、部署都要亲自过一遍，对JavaWeb开发整体有了一次完整的体检。
最后分享两个我反复验证过的实用经验。第一个是不要迷信“功能越多越好”，我给修配厂做的第一个版本只做了五个核心模块：客户、车辆、工单、配件库存、结算，用起来反而比后来加了十几个报表功能更顺手。第二个是开发过程中每次调整数据库表结构，要先备份旧数据再改，尤其是有真实业务数据跑着的时候，一次误操作就能让账户余额对不上账。做管理系统，稳定和准确永远比花哨更重要。
