尧图网页设计 
简介本资源是一套基于SSMSpringSpringMVCMyBatis框架开发的社区物业管理系统完整源码工程面向计算机专业本科生开展毕业设计、课程设计或期末大作业实践。系统聚焦传统社区管理中费用收缴低效、报修响应滞后、信息孤岛等痛点实现了物业缴费查询、住户信息维护、公共设施管理、在线报修流程等核心功能并集成Spring Security权限控制与Maven规范化构建兼顾安全性、可扩展性与工程规范性。压缩包共898个文件含167个Java业务逻辑类、156个JavaScript前端交互脚本、58个Vue组件、58个HTML页面、46个CSS样式文件、2个SQL建库脚本及配套配置文件整体16.37MB目录结构清晰含标准bat启动/安装/构建脚本便于快速部署与二次开发。目前已有23人学习下载提供开箱即用的完整项目骨架、符合第三范式的数据库设计说明、模块化前后端代码及典型业务流程实现是SSM技术栈实战落地的优质参考范例。1. 从物业的日常混乱出发这个系统到底要管哪些事先说一个我观察到的现象很多小区物业还在用Excel加微信群管理日常事务。业主报修在群里喊一嗓子维修工带不带料全靠运气物业费催缴靠月底打印一张名单挨个打电话访客登记翻一本纸质本子丢没丢都不知道。这种模式不是不能用而是越往后越失控——当小区入住率上到八成以上报修单、缴费记录、投诉反馈这些数据叠加起来靠人脑和表格去维护很快就变成一笔烂账。社区物业管理系统要解决的正是这种账本分散、流程失控、数据断层的问题。它是一个典型的管理信息系统把业主、房屋、报修、缴费、公告、访客这些实体全部数据化再通过固定的业务流程把它们串起来。基于SSM框架来做这样的系统是Java后端开发里非常经典的一条路线Spring管对象和事务Spring MVC管请求路由MyBatis管数据库访问。这三个框架合在一起正好覆盖了一个Web项目从浏览器请求到数据库操作再到响应返回的完整链路。从定位上看这个系统属于中小型管理类Web应用的范畴特别适合作为毕业设计、课程设计或者个人练手项目。它的业务复杂度不算高但五脏俱全用户权限、增删改查、状态流转、文件上传这些Web开发里的常见能力都能覆盖到。我在设计这个项目的时候最核心的出发点不是把功能做得越多越好而是先把业务闭环打通一个业主提交的报修单从提交到受理、到派工、到完工、到回访每一步都要有状态记录每一步都要能追查到操作人。这个闭环贯通了整个系统的骨架就立住了。1.1 业务角色与权限边界系统的用户分成三类业主、物业工作人员、系统管理员。这里建议不要只建一张user表加一个role字段就完事而是把角色表单独拆出来。原因很简单后续如果要加一个小区门岗角色只开放访客登记和查询权限单靠user表里的字符串字段去判断会非常痛苦。角色和权限分离的设计虽然初期多写一点代码但扩展性完全不一样。三类角色的权限边界大致这样划分业主能看自己的房屋信息、提交报修、查报修进度、查自己的缴费账单并在线缴费、接收公告物业工作人员能处理报修工单、录入缴费账单、发布公告、登记访客、管理业主和房屋信息系统管理员在物业工作人员的基础上增加用户管理、角色分配和数据统计的权限。这里有一个设计要点权限不是一个静态标签而是体现在每一次接口请求上。后端每个接口都要校验当前登录用户有没有访问权限这是SSM项目中容易偷懒也容易踩坑的地方。1.2 四条核心业务闭环我梳理下来整个系统的业务闭环有四条主线报修闭环业主提交报修单 - 物业人员受理 - 派工给维修师傅 - 维修完成后回填处理结果 - 业主确认。这条线是整个系统最有价值的部分因为它包含了状态流转和多人协作最能体现系统的设计能力。缴费闭环物业后台录入物业费/水费/停车费等账单 - 业主查看账单 - 在线缴费或线下缴纳后由工作人员标记已缴 - 生成缴费记录。这是跟钱相关的环节数据一致性一定要保证。信息发布闭环管理员发布公告 - 业主端在首页或者消息中心看到公告 - 后台记录已读人数。访客管理闭环门岗登记访客信息 - 关联到被访业主 - 生成访客记录 - 访客离场时标记离开时间。这四条闭环不需要一次性全做完但业务流程必须设计好。我在做这个项目时把报修闭环作为主模块优先开发因为它涵盖了最难的状态流转和并发处理问题跑通了它其他模块基本就是类似操作的重复。2. 为什么还选SSM老牌组合的技术定位与实际取舍说实话现在从零开始做一个全新Java Web项目大部分团队会直接选Spring Boot。那为什么这个项目还要用SSM不是因为SSM比Spring Boot好而是因为SSM是一个更底层的组合它逼着你把很多Spring Boot自动帮你做了的事情亲手做一遍。Spring Boot里一个注解就能启动内置Tomcat一个starter就能引入MyBatis但在SSM项目里你需要手动配置DataSource、SqlSessionFactory、事务管理器、视图解析器、拦截器。这个过程比较繁琐但做完之后对Spring的IoC和AOP理解完全是两个层次。2.1 三个框架各管哪一段Spring是容器框架负责管理对象的创建和依赖注入。在项目里ServiceImpl类注册为Spring的BeanController通过Autowired注入ServiceService通过构造器或者字段注入Mapper这种松耦合关系是Spring解决的。Spring MVC是Web层框架负责处理HTTP请求和响应。浏览器发来的请求先经过DispatcherServlet再根据GetMapping/PostMapping等注解映射到具体的方法上。它还负责参数解析、类型转换、视图渲染。MyBatis是持久层框架负责SQL和执行结果到Java对象的映射。它的核心价值是控制SQL不需要写一整套Hibernate那样的对象关系映射规则复杂的多表查询、动态条件SQL都能直接写。这三者的分界线很干净Controller层不写业务逻辑Service层不出现SQLMapper层不写业务判断。很多SSM项目烂就烂在这条分界线被打破了Controller里直接注入Mapper查数据库短期看省事后期维护起来就是灾难。2.2 和Spring Boot对比怎么选如果这个项目是为了上生产、拼开发速度直接用Spring Boot合理。但如果是学习、做毕设、或者想夯实JavaWeb基础SSM反而是更好的选择。原因有三点手动配置一遍web.xml或注解配置类你才能真正理解DispatcherServlet和CharacterEncodingFilter是什么、为什么要在最前面配编码过滤器、为什么静态资源需要额外放行。SSM的包结构通常更清晰controller、service、mapper、entity、config各归其位没有Spring Boot那种自动扫描的魔法出了问题更容易沿着调用链排查。面试和答辩的时候SSM项目的每一个配置都能讲出原理而Spring Boot项目往往只能说加了starter就自动配置了。当然如果读者手头这个项目是Spring Boot做的也不冲突。SSM里的业务设计和事务处理思路在Spring Boot里几乎完全一样换框架只是换配置方式不换程序设计逻辑。2.3 前端方案JSP还是前后端分离这个问题很多做SSM项目的人都会纠结。传统的SSM学习路线是JSP加JSTL后端返回ModelAndViewJSP页面里用EL表达式渲染数据。这种方案的优势是简单直接不用管跨域不需要额外启动一个前端工程打包成一个war直接部署到Tomcat就能跑。前后端分离的方案是SSM后端只返回JSON前端单独用Vue3或者其他框架开发通过axios调用接口。这种方案更贴近实际开发场景联调时候遇到的问题也更多。如果项目要求里有Vue3连接SSM这类的表述那走前后端分离路线会更有亮点。我推荐的做法是后端优先设计成纯JSON接口前端页面单独跑一个Vue3工程。这样既保留了SSM的后端设计逻辑也紧跟了当前前端技术栈。3. 数据库设计社区物业系统的地基怎么打数据库设计是这个项目最不能省步骤的阶段。我见过太多项目代码写到一半发现表结构不对回头改表、改Mapper、改Service来回折腾的时间比重新建表还多。物业系统的数据模型不算复杂但核心表之间的关联关系一定要提前想清楚。3.1 核心表结构从业主到缴费单的数据主线我设计表结构时遵循了一条主线用户是登录主体业主关联房屋房屋产生费用报修单和缴费单都挂在房屋下。这样查询路径非常清晰比如某栋某室有哪些未缴费用一条SQL就能搞定。先看用户和角色这两张表CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, salt VARCHAR(32) NOT NULL, real_name VARCHAR(50), phone VARCHAR(20), role_id INT NOT NULL, status TINYINT DEFAULT 1 COMMENT 1启用 0禁用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_role ( id INT PRIMARY KEY AUTO_INCREMENT, role_name VARCHAR(50) NOT NULL, role_code VARCHAR(30) NOT NULL UNIQUE COMMENT OWNER/STAFF/ADMIN );注意密码字段长度不能设太短因为一般会做加盐哈希64个字符比较保险。salt字段很多人容易漏掉没它的话密码一般只能明文存或者用固定算法加密安全性差很多。房屋和业主的关系是数据库设计里比较有代表性的场景。一个房屋对应一个业主但业主可以有多套房屋。所以我设计了owner表和house表owner_id挂在house上一个owner可以关联多条house记录反过来单套房屋只能属于一个业主这样用外键或者逻辑外键去约束都方便。核心业务表的建表思路CREATE TABLE repair_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 报修单号, owner_id INT NOT NULL COMMENT 提交人, house_id INT NOT NULL, title VARCHAR(100) NOT NULL, content TEXT, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待受理 1受理中 2待确认 3已完成 4已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, finish_time DATETIME, processor_id INT COMMENT 处理人, remark VARCHAR(500) ); CREATE TABLE payment_order ( id INT PRIMARY KEY AUTO_INCREMENT, payment_no VARCHAR(32) NOT NULL, house_id INT NOT NULL, item_name VARCHAR(100) NOT NULL COMMENT 物业费/水费/停车费, amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已退款, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME );3.2 几个容易被忽略的字段设计细节第一个细节金额字段永远用DECIMAL不要用FLOAT或者DOUBLE。浮点数在计算机里是近似存储算钱的时候会出现0.10.2!0.3的问题这在缴费模块上是不可接受的。DECIMAL(10,2)表示最大支持到1亿元两位小数够用了。第二个细节状态字段不要叫state建议叫status并且用TINYINT存数字而不是字符串。数字状态的好处是扩展方便比如报修单从0到4的状态流转数字之间不会产生歧义。但注意每个数字代表什么含义一定要用COMMENT写清楚否则过两周自己看都会忘记。第三个细节单号字段很有用。自增主键id可以做关联查询但不能直接暴露给用户当业务编号因为别人可以通过id的连续性猜到业务量。order_no和payment_no这种业务单号一般用时间戳加随机数生成比如202506141530120001含义是2025年6月14日15点30分12秒的第1单。第四个细节逻辑外键而不是物理外键。很多教材喜欢强调外键约束但在实际的互联网项目里物理外键会带来插入更新时的锁竞争和耦合。我的习惯是只建索引不建物理外键约束关联关系的正确性靠Service层代码保证。这个做法不一定适合所有场景但在SSM这种中小型项目里是挺实用的。4. 后端核心实现一张报修单从业主提交到管理员处理的完整旅程这一节我以报修模块为例子把SSM后端的一个完整业务链路拆开讲。因为报修模块最典型包含了表单提交、状态流转、权限校验、事务处理这四个SSM项目里的核心动作。搞懂它缴费、公告这些模块就是换汤不换药。4.1 Controller层参数接收与统一返回格式请求首先被DispatcherServlet捕获经过HandlerMapping找到对应Controller里的方法。比如业主提交报修单前端发送一个POST请求到/api/repair/add携带的JSON参数是title、content、houseId。Controller方法长这样RestController RequestMapping(/api/repair) public class RepairController { Autowired private RepairService repairService; PostMapping(/add) public Result submit(RequestBody RepairSubmitRequest req, HttpSession session) { UserVO user (UserVO) session.getAttribute(CURRENT_USER); if (user null) { return Result.error(401, 未登录); } if (!user.getRoleCode().equals(OWNER)) { return Result.error(403, 只能由业主提交报修); } repairService.createRepairOrder(user.getId(), req); return Result.success(); } }这里有几个细节值得说。一个是RestController和Controller的区别前者自动把返回的对象序列化成JSON省去在方法上加ResponseBody。第二个是RequestBody接收前端传来的JSON对象这个要和form表单提交区分开后面Vue3联调那节我详细讲。第三个是统一返回格式Result它一般就三个字段code、message、data。所有接口都返回这个结构前端处理逻辑才能统一而不是每个接口返回一个乱七八糟的Map。4.2 Service层事务边界与状态流转Service层是报修模块的重点因为状态流转和事务控制都在这层。我要强调一个原则业务逻辑里不要相信前端传过来的状态值。比如业主提交报修的时候前端可以传一个status1表示已完成但后端必须忽略这个字段强制将status初始化为0。状态流转应该是后端根据当前状态和用户角色推导出来的而不是前端说了算。报修单的状态机我设计成这样待受理(0) - 受理中(1) - 待确认(2) - 已完成(3)另外加一个取消状态(4)。可执行的操作只有有限几个业主只能取消待受理状态下的单子物业人员可以把待受理变为受理中也可以把受理中变为待确认业主确认后变为已完成。如果状态不对操作直接抛异常。为了防并发更新状态一般用条件更新写法Transactional(rollbackFor Exception.class) public void processRepair(Long orderId, Integer expectStatus, Integer targetStatus, Long processorId) { int rows repairOrderMapper.updateStatus(orderId, expectStatus, targetStatus, processorId); if (rows 0) { throw new BizException(订单状态已变更请刷新后重试); } // 其他与报修单关联的更新操作... }对应的Mapper SQLupdate idupdateStatus update repair_order set status #{targetStatus}, processor_id #{processorId} where id #{orderId} and status #{expectStatus} /updateupdateStatus这个SQL的精妙之处在于where条件里带了expectStatus。如果两个管理员同时点受理按钮只有第一个执行update的人能成功影响一行第二个更新的是0行通过rows0就能判断出冲突。这种乐观锁的思路比先查再改要安全得多而且天然利用了数据库的行锁机制。事务边界也很重要。这个案例里Transactional加在Service方法上可以保证状态更新和后续关联操作要么一起成功要么一起回滚。特别注意rollbackFor要设置为Exception.class因为Spring默认只在抛出RuntimeException时回滚如果业务方法里catch了异常又抛出自定义Exception不指定rollbackFor的话事务是不会回滚的。这个坑我在项目里栽过一次查了很久才发现是事务回滚配置的问题。4.3 Mapper层动态SQL与条件查询MyBatis最实用的功能就是动态SQL。报修列表查询会有很多过滤条件比如按状态查、按时间范围查、按房屋查这些条件组合在一个查询里用Java代码去拼SQL非常痛苦。MyBatis的 标签就很好用。select idlistRepairOrders resultTypecom.example.entity.RepairOrderVO select r.*, h.building_no, h.unit_no, h.room_no, u.real_name as owner_name from repair_order r left join house h on r.house_id h.id left join sys_user u on r.owner_id u.id where if teststatus ! null and r.status #{status} /if if testhouseId ! null and r.house_id #{houseId} /if if teststartTime ! null and endTime ! null and r.create_time between #{startTime} and #{endTime} /if /where order by r.create_time desc /select这里的 标签会自动处理掉第一个and前缀这是我特别喜欢的一个细节。写动态查询的时候尽量避免用where 11这种写法虽然在功能上没问题但在答辩或者代码评审的时候会显得不够专业。MyBatis从3.x版本开始就支持多参数Param注解绑定如果有多个查询参数建议在Mapper接口方法签名上显式标注Param这样XML里取值清晰也避免参数名在编译时被改掉的问题。5. 登录鉴权与角色权限三种角色三种入口的落地方式权限控制这块很多SSM项目做得很草率。最常见的就是登录了就放行每个页面单独判断是否登录结果权限校验散落在各个Controller方法里代码重复度极高还容易漏掉。我推荐的做法是用Spring MVC的拦截器做一个统一登录校验再用角色判断去控制接口访问。5.1 登录拦截器的实现public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(false); if (session ! null session.getAttribute(CURRENT_USER) ! null) { return true; } response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\message\:\请先登录\}); return false; } }登录之后的用户信息存到Session里。这里存的是一个UserVO对象包含用户id、用户名、角色code而不是只有userId。因为后续很多地方要用到角色判断如果Session里只有userId每次都要再查一次数据库效率低不说代码也啰嗦。在Spring MVC配置类里注册拦截器同时要放行登录接口和静态资源Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register); }角色权限的校验可以复用拦截器思路也可以直接在Controller方法里判断。我建议在需要特定角色的接口上用一个自定义的角色判断逻辑比如在Service层里检查当前用户角色或者简单一点在Controller方法开头用一个静态工具方法校验。项目规模不大时别引入过重的权限框架把权限逻辑写在业务代码里简单直接。5.2 密码安全与登录细节密码存储我建议“加盐哈希”不推荐MD5直接存储。最稳妥的做法是每个用户随机生成一个salt存的是saltpassword的SHA-256结果的十六进制字符串。登录验证时后端拿用户传的密码拼上DB里的salt重新计算哈希与DB中的结果比对。虽然MD5也能跑但在项目文档或者答辩里写出加盐哈希至少能让人觉得你有安全意识。登录接口还有一个细节区分“用户名不存在”和“密码错误”两种异常提示。正常情况下这两个提示应该合并成“用户名或密码错误”防止攻击者通过提示信息枚举有效用户名。再结合登录失败次数限制比如连续失败5次锁定账号15分钟这个小功能在答辩时是加分项。5.3 前端按角色控制菜单与按钮后端权限校验做了之后前端的菜单控制其实变成了一种体验优化。登录成功后后端返回当前用户信息包括角色code。Vue3前端根据角色code去渲染不同的菜单和按钮。比如业主端只显示“我的报修”“我的账单”“公告中心”物业端显示“工单处理”“账单管理”“房屋管理”。注意菜单隐藏不等于接口安全真正的安全防线永远在后端。即便前端把管理员菜单隐藏了懂技术的人直接调接口也能访问所以后端权限校验不能省。6. Vue3连接SSM后端跨域、Session与接口联调前面留了个尾巴说Vue3前端和SSM后端联调的时候有一些坑这里展开讲。SSM后端默认部署在Tomcat的8080端口Vue3开发服务器默认跑在5173端口。这两个端口不一样浏览器发请求就会产生跨域问题。6.1 跨域配置不能只配前端跨域的解决方案有很多简单来说后端配置CORS是最直接的。在Spring MVC里写一个配置类Configuration public class WebConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:5173) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里最容易踩的坑是allowCredentials和allowedOrigins同时使用的问题。allowCredentials(true)表示允许携带Cookie也就是Session需要靠Cookie来维持但跨域情况下如果不允许携带Cookie即使后端返回了SessionId前端也不会保存下一次请求又是新的会话登录状态就丢了。如果设置了allowCredentials(true)allowedOrigins不能写成*必须明确指定来源地址。6.2 axios配置与Session保持前端axios需要做两件事设置baseURL指向后端接口地址设置withCredentials为true。示例import axios from axios const request axios.create({ baseURL: http://localhost:8080/community, timeout: 10000 }) request.defaults.withCredentials true request.interceptors.response.use( response { const res response.data if (res.code 401) { window.location.href /login } return res }, error { if (error.response error.response.status 401) { window.location.href /login } return Promise.reject(error) } ) export default request注意baseURL里的/community是项目的context-path如果后端部署时设置了context-path这个必须对上。另外前后端联调时如果访问的是localhostCookie的domain是一致的但如果后端地址写成了127.0.0.1前端访问的是localhostCookie可能因为域不一致而存不下来。建议统一用localhost或者统一用127.0.0.1别混着写。6.3 JSON提交与表单提交的差异这个坑特别隐蔽也特别常见。如果前端用axios的默认行为提交数据数据会被序列化成JSON格式后端用RequestBody能接收到如果前端用了URLSearchParams或者FormData提交后端需要用普通的RequestParam来接收两种写法不能混。// 方式一JSON提交后端用RequestBody接收 const res await request.post(/api/repair/add, { title: 厨房水管漏水, content: 水槽下方漏水比较严重, houseId: 3 }) // 方式二表单提交后端用RequestParam接收 const params new URLSearchParams() params.append(username, zhangsan) params.append(password, 123456) const res await request.post(/api/user/login, params)我之前帮朋友排查过一个bug前端用JSON提交登录接口后端却用RequestParam接收username和password结果一直401。花了大半天才意识到是参数格式不匹配。调试时最简单的方法是在浏览器开发者工具里看请求头如果Content-Type是application/json那后端必须用RequestBody如果是application/x-www-form-urlencoded就必须用RequestParam。7. 部署运行的踩坑记录与调试经验这个项目我前后跑了好几遍每次都会碰到新的坑。这里把最主要的几个记下来给读者一个排查思路而不是直接给答案因为环境问题千奇百怪背答案没用掌握排查思路才能举一反三。7.1 MySQL 8与JDBC驱动的坑项目用MySQL 8的话JDBC驱动类名已经变了不再是com.mysql.jdbc.Driver而是com.mysql.cj.jdbc.Driver。如果还在用老驱动启动项目连数据库时会直接ClassNotFoundException。连接串也要加上时区参数jdbc.urljdbc:mysql://localhost:3306/community?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrueserverTimezone这个参数特别容易忘不配的话大概率报time zone相关错误。allowPublicKeyRetrievaltrue这个参数是MySQL 8新加的如果连的是MySQL 8并且客户端不是通过SSL连接不加可能报Public Key Retrieval is not allowed。7.2 数据库连接池配置SSM项目一般用Druid或者C3P0作为连接池。我建议用Druid因为它有监控页面能看到连接池的使用情况。但配置时要注意initialSize、minIdle、maxActive这几个参数的关系不要把maxActive设得很大而initialSize设得很小这样并发一上来就要频繁创建新连接性能反而不稳定。一个合理的配置可以是initialSize5minIdle5maxActive20maxWait60000。连接池的坑还有一个长时间闲置后数据库连接会被MySQL服务端断开客户端拿到一个失效连接再去执行SQL就报Communications link failure。解决办法是在jdbcUrl里加上autoReconnecttrue或者在Druid配置里开启testWhileIdle和validationQuerySELECT 1。这是我做SSM项目时比较常见的一个线上问题。7.3 Tomcat部署与打包的注意点SSM项目一般打包成war包部署到Tomcat。这里有几个点确保pom.xml里的打包方式设置了war并且Spring的字符编码过滤器配置在最前面。如果页面中文乱码先看过滤器的urlPattern是不是/*。项目如果叫communitywar包名要跟context-path一致否则访问路径很容易搞混。部署的时候war包名决定了访问路径改war包名比去改配置文件要简单。如果本地是Tomcat 10注意javax.servlet和jakarta.servlet的包名变更SSM的老代码大多是javax.servlet直接上Tomcat 10会报ClassNotFoundException。稳妥起见用Tomcat 9。把war包丢进webapps后启动的时候注意看logs/catalina.out的日志特别是Bean创建失败、Mapper映射文件找不到这类错误一般是配置路径写错了仔细检查mybatis的mapper-locations路径是否匹配。7.4 接口404和500的快速定位联调阶段最常见的两个状态码接口404大概率是路径不对或者没进Controller。先用浏览器的Network面板确认请求的URL然后看后端控制台有没有打印日志。如果Controller的RequestMapping路径和前端请求的对不上404很正常。还有一种情况是项目部署的context-path没算进去比如接口路径实际是/community/api/repair/add前端只写了/api/repair/add。接口500重点看后端异常栈的前十行。如果是指针异常NPE八成是某个查询结果为空但没做判空处理往下找是哪个对象为空就能定位。如果是MyBatis绑定异常BoundException通常是Mapper接口方法和XML里的id对不上或者namespace写错。如果是SQL语法异常把SQL复制到Navicat里跑一下很容易看出问题。8. 项目优化方向与个人的一点体会这个项目跑通之后我建议不用急着加新功能先把三件事做好一是给报修单的查询加索引尤其是(owner_id, status)这个联合索引业主列表页会快很多二是把接口的异常处理统一起来用ControllerAdvice写一个全局异常处理器把BizException和系统异常分开处理返回给前端的错误信息要友好三是把密码重置、报修单导出这些低频但必要的管理功能补上。从个人经验来说我做完这个SSM版本的物业系统后最大的收获不是学会了多少框架API而是想明白了业务闭环和数据模型怎么对齐。很多初学者拿到需求就开始写代码结果表结构设计不合理前后端接口对不上来回返工。我建议动手前先花两三天把业务流程画清楚把每个状态流转的边界列出来把每张表的字段设计好后面的开发会发现顺畅得多。最后分享一个调试小技巧SSM项目启动慢别每次改完代码就重启Tomcat。把Spring的日志级别调整到DEBUG开发阶段开启热部署改Java代码时通过DevTools或者JRebel自动重启改前端页面时直接用Vue3的dev模式数据通过接口联调这样开发体验会好很多。本文还有配套的精品资源点击获取 基于SSM框架的社区物业管理系统设计实践
简介本资源是一套基于SSMSpringSpringMVCMyBatis框架开发的社区物业管理系统完整源码工程面向计算机专业本科生开展毕业设计、课程设计或期末大作业实践。系统聚焦传统社区管理中费用收缴低效、报修响应滞后、信息孤岛等痛点实现了物业缴费查询、住户信息维护、公共设施管理、在线报修流程等核心功能并集成Spring Security权限控制与Maven规范化构建兼顾安全性、可扩展性与工程规范性。压缩包共898个文件含167个Java业务逻辑类、156个JavaScript前端交互脚本、58个Vue组件、58个HTML页面、46个CSS样式文件、2个SQL建库脚本及配套配置文件整体16.37MB目录结构清晰含标准bat启动/安装/构建脚本便于快速部署与二次开发。目前已有23人学习下载提供开箱即用的完整项目骨架、符合第三范式的数据库设计说明、模块化前后端代码及典型业务流程实现是SSM技术栈实战落地的优质参考范例。1. 从物业的日常混乱出发这个系统到底要管哪些事先说一个我观察到的现象很多小区物业还在用Excel加微信群管理日常事务。业主报修在群里喊一嗓子维修工带不带料全靠运气物业费催缴靠月底打印一张名单挨个打电话访客登记翻一本纸质本子丢没丢都不知道。这种模式不是不能用而是越往后越失控——当小区入住率上到八成以上报修单、缴费记录、投诉反馈这些数据叠加起来靠人脑和表格去维护很快就变成一笔烂账。社区物业管理系统要解决的正是这种账本分散、流程失控、数据断层的问题。它是一个典型的管理信息系统把业主、房屋、报修、缴费、公告、访客这些实体全部数据化再通过固定的业务流程把它们串起来。基于SSM框架来做这样的系统是Java后端开发里非常经典的一条路线Spring管对象和事务Spring MVC管请求路由MyBatis管数据库访问。这三个框架合在一起正好覆盖了一个Web项目从浏览器请求到数据库操作再到响应返回的完整链路。从定位上看这个系统属于中小型管理类Web应用的范畴特别适合作为毕业设计、课程设计或者个人练手项目。它的业务复杂度不算高但五脏俱全用户权限、增删改查、状态流转、文件上传这些Web开发里的常见能力都能覆盖到。我在设计这个项目的时候最核心的出发点不是把功能做得越多越好而是先把业务闭环打通一个业主提交的报修单从提交到受理、到派工、到完工、到回访每一步都要有状态记录每一步都要能追查到操作人。这个闭环贯通了整个系统的骨架就立住了。1.1 业务角色与权限边界系统的用户分成三类业主、物业工作人员、系统管理员。这里建议不要只建一张user表加一个role字段就完事而是把角色表单独拆出来。原因很简单后续如果要加一个小区门岗角色只开放访客登记和查询权限单靠user表里的字符串字段去判断会非常痛苦。角色和权限分离的设计虽然初期多写一点代码但扩展性完全不一样。三类角色的权限边界大致这样划分业主能看自己的房屋信息、提交报修、查报修进度、查自己的缴费账单并在线缴费、接收公告物业工作人员能处理报修工单、录入缴费账单、发布公告、登记访客、管理业主和房屋信息系统管理员在物业工作人员的基础上增加用户管理、角色分配和数据统计的权限。这里有一个设计要点权限不是一个静态标签而是体现在每一次接口请求上。后端每个接口都要校验当前登录用户有没有访问权限这是SSM项目中容易偷懒也容易踩坑的地方。1.2 四条核心业务闭环我梳理下来整个系统的业务闭环有四条主线报修闭环业主提交报修单 - 物业人员受理 - 派工给维修师傅 - 维修完成后回填处理结果 - 业主确认。这条线是整个系统最有价值的部分因为它包含了状态流转和多人协作最能体现系统的设计能力。缴费闭环物业后台录入物业费/水费/停车费等账单 - 业主查看账单 - 在线缴费或线下缴纳后由工作人员标记已缴 - 生成缴费记录。这是跟钱相关的环节数据一致性一定要保证。信息发布闭环管理员发布公告 - 业主端在首页或者消息中心看到公告 - 后台记录已读人数。访客管理闭环门岗登记访客信息 - 关联到被访业主 - 生成访客记录 - 访客离场时标记离开时间。这四条闭环不需要一次性全做完但业务流程必须设计好。我在做这个项目时把报修闭环作为主模块优先开发因为它涵盖了最难的状态流转和并发处理问题跑通了它其他模块基本就是类似操作的重复。2. 为什么还选SSM老牌组合的技术定位与实际取舍说实话现在从零开始做一个全新Java Web项目大部分团队会直接选Spring Boot。那为什么这个项目还要用SSM不是因为SSM比Spring Boot好而是因为SSM是一个更底层的组合它逼着你把很多Spring Boot自动帮你做了的事情亲手做一遍。Spring Boot里一个注解就能启动内置Tomcat一个starter就能引入MyBatis但在SSM项目里你需要手动配置DataSource、SqlSessionFactory、事务管理器、视图解析器、拦截器。这个过程比较繁琐但做完之后对Spring的IoC和AOP理解完全是两个层次。2.1 三个框架各管哪一段Spring是容器框架负责管理对象的创建和依赖注入。在项目里ServiceImpl类注册为Spring的BeanController通过Autowired注入ServiceService通过构造器或者字段注入Mapper这种松耦合关系是Spring解决的。Spring MVC是Web层框架负责处理HTTP请求和响应。浏览器发来的请求先经过DispatcherServlet再根据GetMapping/PostMapping等注解映射到具体的方法上。它还负责参数解析、类型转换、视图渲染。MyBatis是持久层框架负责SQL和执行结果到Java对象的映射。它的核心价值是控制SQL不需要写一整套Hibernate那样的对象关系映射规则复杂的多表查询、动态条件SQL都能直接写。这三者的分界线很干净Controller层不写业务逻辑Service层不出现SQLMapper层不写业务判断。很多SSM项目烂就烂在这条分界线被打破了Controller里直接注入Mapper查数据库短期看省事后期维护起来就是灾难。2.2 和Spring Boot对比怎么选如果这个项目是为了上生产、拼开发速度直接用Spring Boot合理。但如果是学习、做毕设、或者想夯实JavaWeb基础SSM反而是更好的选择。原因有三点手动配置一遍web.xml或注解配置类你才能真正理解DispatcherServlet和CharacterEncodingFilter是什么、为什么要在最前面配编码过滤器、为什么静态资源需要额外放行。SSM的包结构通常更清晰controller、service、mapper、entity、config各归其位没有Spring Boot那种自动扫描的魔法出了问题更容易沿着调用链排查。面试和答辩的时候SSM项目的每一个配置都能讲出原理而Spring Boot项目往往只能说加了starter就自动配置了。当然如果读者手头这个项目是Spring Boot做的也不冲突。SSM里的业务设计和事务处理思路在Spring Boot里几乎完全一样换框架只是换配置方式不换程序设计逻辑。2.3 前端方案JSP还是前后端分离这个问题很多做SSM项目的人都会纠结。传统的SSM学习路线是JSP加JSTL后端返回ModelAndViewJSP页面里用EL表达式渲染数据。这种方案的优势是简单直接不用管跨域不需要额外启动一个前端工程打包成一个war直接部署到Tomcat就能跑。前后端分离的方案是SSM后端只返回JSON前端单独用Vue3或者其他框架开发通过axios调用接口。这种方案更贴近实际开发场景联调时候遇到的问题也更多。如果项目要求里有Vue3连接SSM这类的表述那走前后端分离路线会更有亮点。我推荐的做法是后端优先设计成纯JSON接口前端页面单独跑一个Vue3工程。这样既保留了SSM的后端设计逻辑也紧跟了当前前端技术栈。3. 数据库设计社区物业系统的地基怎么打数据库设计是这个项目最不能省步骤的阶段。我见过太多项目代码写到一半发现表结构不对回头改表、改Mapper、改Service来回折腾的时间比重新建表还多。物业系统的数据模型不算复杂但核心表之间的关联关系一定要提前想清楚。3.1 核心表结构从业主到缴费单的数据主线我设计表结构时遵循了一条主线用户是登录主体业主关联房屋房屋产生费用报修单和缴费单都挂在房屋下。这样查询路径非常清晰比如某栋某室有哪些未缴费用一条SQL就能搞定。先看用户和角色这两张表CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, salt VARCHAR(32) NOT NULL, real_name VARCHAR(50), phone VARCHAR(20), role_id INT NOT NULL, status TINYINT DEFAULT 1 COMMENT 1启用 0禁用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_role ( id INT PRIMARY KEY AUTO_INCREMENT, role_name VARCHAR(50) NOT NULL, role_code VARCHAR(30) NOT NULL UNIQUE COMMENT OWNER/STAFF/ADMIN );注意密码字段长度不能设太短因为一般会做加盐哈希64个字符比较保险。salt字段很多人容易漏掉没它的话密码一般只能明文存或者用固定算法加密安全性差很多。房屋和业主的关系是数据库设计里比较有代表性的场景。一个房屋对应一个业主但业主可以有多套房屋。所以我设计了owner表和house表owner_id挂在house上一个owner可以关联多条house记录反过来单套房屋只能属于一个业主这样用外键或者逻辑外键去约束都方便。核心业务表的建表思路CREATE TABLE repair_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 报修单号, owner_id INT NOT NULL COMMENT 提交人, house_id INT NOT NULL, title VARCHAR(100) NOT NULL, content TEXT, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待受理 1受理中 2待确认 3已完成 4已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, finish_time DATETIME, processor_id INT COMMENT 处理人, remark VARCHAR(500) ); CREATE TABLE payment_order ( id INT PRIMARY KEY AUTO_INCREMENT, payment_no VARCHAR(32) NOT NULL, house_id INT NOT NULL, item_name VARCHAR(100) NOT NULL COMMENT 物业费/水费/停车费, amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已退款, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME );3.2 几个容易被忽略的字段设计细节第一个细节金额字段永远用DECIMAL不要用FLOAT或者DOUBLE。浮点数在计算机里是近似存储算钱的时候会出现0.10.2!0.3的问题这在缴费模块上是不可接受的。DECIMAL(10,2)表示最大支持到1亿元两位小数够用了。第二个细节状态字段不要叫state建议叫status并且用TINYINT存数字而不是字符串。数字状态的好处是扩展方便比如报修单从0到4的状态流转数字之间不会产生歧义。但注意每个数字代表什么含义一定要用COMMENT写清楚否则过两周自己看都会忘记。第三个细节单号字段很有用。自增主键id可以做关联查询但不能直接暴露给用户当业务编号因为别人可以通过id的连续性猜到业务量。order_no和payment_no这种业务单号一般用时间戳加随机数生成比如202506141530120001含义是2025年6月14日15点30分12秒的第1单。第四个细节逻辑外键而不是物理外键。很多教材喜欢强调外键约束但在实际的互联网项目里物理外键会带来插入更新时的锁竞争和耦合。我的习惯是只建索引不建物理外键约束关联关系的正确性靠Service层代码保证。这个做法不一定适合所有场景但在SSM这种中小型项目里是挺实用的。4. 后端核心实现一张报修单从业主提交到管理员处理的完整旅程这一节我以报修模块为例子把SSM后端的一个完整业务链路拆开讲。因为报修模块最典型包含了表单提交、状态流转、权限校验、事务处理这四个SSM项目里的核心动作。搞懂它缴费、公告这些模块就是换汤不换药。4.1 Controller层参数接收与统一返回格式请求首先被DispatcherServlet捕获经过HandlerMapping找到对应Controller里的方法。比如业主提交报修单前端发送一个POST请求到/api/repair/add携带的JSON参数是title、content、houseId。Controller方法长这样RestController RequestMapping(/api/repair) public class RepairController { Autowired private RepairService repairService; PostMapping(/add) public Result submit(RequestBody RepairSubmitRequest req, HttpSession session) { UserVO user (UserVO) session.getAttribute(CURRENT_USER); if (user null) { return Result.error(401, 未登录); } if (!user.getRoleCode().equals(OWNER)) { return Result.error(403, 只能由业主提交报修); } repairService.createRepairOrder(user.getId(), req); return Result.success(); } }这里有几个细节值得说。一个是RestController和Controller的区别前者自动把返回的对象序列化成JSON省去在方法上加ResponseBody。第二个是RequestBody接收前端传来的JSON对象这个要和form表单提交区分开后面Vue3联调那节我详细讲。第三个是统一返回格式Result它一般就三个字段code、message、data。所有接口都返回这个结构前端处理逻辑才能统一而不是每个接口返回一个乱七八糟的Map。4.2 Service层事务边界与状态流转Service层是报修模块的重点因为状态流转和事务控制都在这层。我要强调一个原则业务逻辑里不要相信前端传过来的状态值。比如业主提交报修的时候前端可以传一个status1表示已完成但后端必须忽略这个字段强制将status初始化为0。状态流转应该是后端根据当前状态和用户角色推导出来的而不是前端说了算。报修单的状态机我设计成这样待受理(0) - 受理中(1) - 待确认(2) - 已完成(3)另外加一个取消状态(4)。可执行的操作只有有限几个业主只能取消待受理状态下的单子物业人员可以把待受理变为受理中也可以把受理中变为待确认业主确认后变为已完成。如果状态不对操作直接抛异常。为了防并发更新状态一般用条件更新写法Transactional(rollbackFor Exception.class) public void processRepair(Long orderId, Integer expectStatus, Integer targetStatus, Long processorId) { int rows repairOrderMapper.updateStatus(orderId, expectStatus, targetStatus, processorId); if (rows 0) { throw new BizException(订单状态已变更请刷新后重试); } // 其他与报修单关联的更新操作... }对应的Mapper SQLupdate idupdateStatus update repair_order set status #{targetStatus}, processor_id #{processorId} where id #{orderId} and status #{expectStatus} /updateupdateStatus这个SQL的精妙之处在于where条件里带了expectStatus。如果两个管理员同时点受理按钮只有第一个执行update的人能成功影响一行第二个更新的是0行通过rows0就能判断出冲突。这种乐观锁的思路比先查再改要安全得多而且天然利用了数据库的行锁机制。事务边界也很重要。这个案例里Transactional加在Service方法上可以保证状态更新和后续关联操作要么一起成功要么一起回滚。特别注意rollbackFor要设置为Exception.class因为Spring默认只在抛出RuntimeException时回滚如果业务方法里catch了异常又抛出自定义Exception不指定rollbackFor的话事务是不会回滚的。这个坑我在项目里栽过一次查了很久才发现是事务回滚配置的问题。4.3 Mapper层动态SQL与条件查询MyBatis最实用的功能就是动态SQL。报修列表查询会有很多过滤条件比如按状态查、按时间范围查、按房屋查这些条件组合在一个查询里用Java代码去拼SQL非常痛苦。MyBatis的 标签就很好用。select idlistRepairOrders resultTypecom.example.entity.RepairOrderVO select r.*, h.building_no, h.unit_no, h.room_no, u.real_name as owner_name from repair_order r left join house h on r.house_id h.id left join sys_user u on r.owner_id u.id where if teststatus ! null and r.status #{status} /if if testhouseId ! null and r.house_id #{houseId} /if if teststartTime ! null and endTime ! null and r.create_time between #{startTime} and #{endTime} /if /where order by r.create_time desc /select这里的 标签会自动处理掉第一个and前缀这是我特别喜欢的一个细节。写动态查询的时候尽量避免用where 11这种写法虽然在功能上没问题但在答辩或者代码评审的时候会显得不够专业。MyBatis从3.x版本开始就支持多参数Param注解绑定如果有多个查询参数建议在Mapper接口方法签名上显式标注Param这样XML里取值清晰也避免参数名在编译时被改掉的问题。5. 登录鉴权与角色权限三种角色三种入口的落地方式权限控制这块很多SSM项目做得很草率。最常见的就是登录了就放行每个页面单独判断是否登录结果权限校验散落在各个Controller方法里代码重复度极高还容易漏掉。我推荐的做法是用Spring MVC的拦截器做一个统一登录校验再用角色判断去控制接口访问。5.1 登录拦截器的实现public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(false); if (session ! null session.getAttribute(CURRENT_USER) ! null) { return true; } response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\message\:\请先登录\}); return false; } }登录之后的用户信息存到Session里。这里存的是一个UserVO对象包含用户id、用户名、角色code而不是只有userId。因为后续很多地方要用到角色判断如果Session里只有userId每次都要再查一次数据库效率低不说代码也啰嗦。在Spring MVC配置类里注册拦截器同时要放行登录接口和静态资源Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register); }角色权限的校验可以复用拦截器思路也可以直接在Controller方法里判断。我建议在需要特定角色的接口上用一个自定义的角色判断逻辑比如在Service层里检查当前用户角色或者简单一点在Controller方法开头用一个静态工具方法校验。项目规模不大时别引入过重的权限框架把权限逻辑写在业务代码里简单直接。5.2 密码安全与登录细节密码存储我建议“加盐哈希”不推荐MD5直接存储。最稳妥的做法是每个用户随机生成一个salt存的是saltpassword的SHA-256结果的十六进制字符串。登录验证时后端拿用户传的密码拼上DB里的salt重新计算哈希与DB中的结果比对。虽然MD5也能跑但在项目文档或者答辩里写出加盐哈希至少能让人觉得你有安全意识。登录接口还有一个细节区分“用户名不存在”和“密码错误”两种异常提示。正常情况下这两个提示应该合并成“用户名或密码错误”防止攻击者通过提示信息枚举有效用户名。再结合登录失败次数限制比如连续失败5次锁定账号15分钟这个小功能在答辩时是加分项。5.3 前端按角色控制菜单与按钮后端权限校验做了之后前端的菜单控制其实变成了一种体验优化。登录成功后后端返回当前用户信息包括角色code。Vue3前端根据角色code去渲染不同的菜单和按钮。比如业主端只显示“我的报修”“我的账单”“公告中心”物业端显示“工单处理”“账单管理”“房屋管理”。注意菜单隐藏不等于接口安全真正的安全防线永远在后端。即便前端把管理员菜单隐藏了懂技术的人直接调接口也能访问所以后端权限校验不能省。6. Vue3连接SSM后端跨域、Session与接口联调前面留了个尾巴说Vue3前端和SSM后端联调的时候有一些坑这里展开讲。SSM后端默认部署在Tomcat的8080端口Vue3开发服务器默认跑在5173端口。这两个端口不一样浏览器发请求就会产生跨域问题。6.1 跨域配置不能只配前端跨域的解决方案有很多简单来说后端配置CORS是最直接的。在Spring MVC里写一个配置类Configuration public class WebConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:5173) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里最容易踩的坑是allowCredentials和allowedOrigins同时使用的问题。allowCredentials(true)表示允许携带Cookie也就是Session需要靠Cookie来维持但跨域情况下如果不允许携带Cookie即使后端返回了SessionId前端也不会保存下一次请求又是新的会话登录状态就丢了。如果设置了allowCredentials(true)allowedOrigins不能写成*必须明确指定来源地址。6.2 axios配置与Session保持前端axios需要做两件事设置baseURL指向后端接口地址设置withCredentials为true。示例import axios from axios const request axios.create({ baseURL: http://localhost:8080/community, timeout: 10000 }) request.defaults.withCredentials true request.interceptors.response.use( response { const res response.data if (res.code 401) { window.location.href /login } return res }, error { if (error.response error.response.status 401) { window.location.href /login } return Promise.reject(error) } ) export default request注意baseURL里的/community是项目的context-path如果后端部署时设置了context-path这个必须对上。另外前后端联调时如果访问的是localhostCookie的domain是一致的但如果后端地址写成了127.0.0.1前端访问的是localhostCookie可能因为域不一致而存不下来。建议统一用localhost或者统一用127.0.0.1别混着写。6.3 JSON提交与表单提交的差异这个坑特别隐蔽也特别常见。如果前端用axios的默认行为提交数据数据会被序列化成JSON格式后端用RequestBody能接收到如果前端用了URLSearchParams或者FormData提交后端需要用普通的RequestParam来接收两种写法不能混。// 方式一JSON提交后端用RequestBody接收 const res await request.post(/api/repair/add, { title: 厨房水管漏水, content: 水槽下方漏水比较严重, houseId: 3 }) // 方式二表单提交后端用RequestParam接收 const params new URLSearchParams() params.append(username, zhangsan) params.append(password, 123456) const res await request.post(/api/user/login, params)我之前帮朋友排查过一个bug前端用JSON提交登录接口后端却用RequestParam接收username和password结果一直401。花了大半天才意识到是参数格式不匹配。调试时最简单的方法是在浏览器开发者工具里看请求头如果Content-Type是application/json那后端必须用RequestBody如果是application/x-www-form-urlencoded就必须用RequestParam。7. 部署运行的踩坑记录与调试经验这个项目我前后跑了好几遍每次都会碰到新的坑。这里把最主要的几个记下来给读者一个排查思路而不是直接给答案因为环境问题千奇百怪背答案没用掌握排查思路才能举一反三。7.1 MySQL 8与JDBC驱动的坑项目用MySQL 8的话JDBC驱动类名已经变了不再是com.mysql.jdbc.Driver而是com.mysql.cj.jdbc.Driver。如果还在用老驱动启动项目连数据库时会直接ClassNotFoundException。连接串也要加上时区参数jdbc.urljdbc:mysql://localhost:3306/community?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrueserverTimezone这个参数特别容易忘不配的话大概率报time zone相关错误。allowPublicKeyRetrievaltrue这个参数是MySQL 8新加的如果连的是MySQL 8并且客户端不是通过SSL连接不加可能报Public Key Retrieval is not allowed。7.2 数据库连接池配置SSM项目一般用Druid或者C3P0作为连接池。我建议用Druid因为它有监控页面能看到连接池的使用情况。但配置时要注意initialSize、minIdle、maxActive这几个参数的关系不要把maxActive设得很大而initialSize设得很小这样并发一上来就要频繁创建新连接性能反而不稳定。一个合理的配置可以是initialSize5minIdle5maxActive20maxWait60000。连接池的坑还有一个长时间闲置后数据库连接会被MySQL服务端断开客户端拿到一个失效连接再去执行SQL就报Communications link failure。解决办法是在jdbcUrl里加上autoReconnecttrue或者在Druid配置里开启testWhileIdle和validationQuerySELECT 1。这是我做SSM项目时比较常见的一个线上问题。7.3 Tomcat部署与打包的注意点SSM项目一般打包成war包部署到Tomcat。这里有几个点确保pom.xml里的打包方式设置了war并且Spring的字符编码过滤器配置在最前面。如果页面中文乱码先看过滤器的urlPattern是不是/*。项目如果叫communitywar包名要跟context-path一致否则访问路径很容易搞混。部署的时候war包名决定了访问路径改war包名比去改配置文件要简单。如果本地是Tomcat 10注意javax.servlet和jakarta.servlet的包名变更SSM的老代码大多是javax.servlet直接上Tomcat 10会报ClassNotFoundException。稳妥起见用Tomcat 9。把war包丢进webapps后启动的时候注意看logs/catalina.out的日志特别是Bean创建失败、Mapper映射文件找不到这类错误一般是配置路径写错了仔细检查mybatis的mapper-locations路径是否匹配。7.4 接口404和500的快速定位联调阶段最常见的两个状态码接口404大概率是路径不对或者没进Controller。先用浏览器的Network面板确认请求的URL然后看后端控制台有没有打印日志。如果Controller的RequestMapping路径和前端请求的对不上404很正常。还有一种情况是项目部署的context-path没算进去比如接口路径实际是/community/api/repair/add前端只写了/api/repair/add。接口500重点看后端异常栈的前十行。如果是指针异常NPE八成是某个查询结果为空但没做判空处理往下找是哪个对象为空就能定位。如果是MyBatis绑定异常BoundException通常是Mapper接口方法和XML里的id对不上或者namespace写错。如果是SQL语法异常把SQL复制到Navicat里跑一下很容易看出问题。8. 项目优化方向与个人的一点体会这个项目跑通之后我建议不用急着加新功能先把三件事做好一是给报修单的查询加索引尤其是(owner_id, status)这个联合索引业主列表页会快很多二是把接口的异常处理统一起来用ControllerAdvice写一个全局异常处理器把BizException和系统异常分开处理返回给前端的错误信息要友好三是把密码重置、报修单导出这些低频但必要的管理功能补上。从个人经验来说我做完这个SSM版本的物业系统后最大的收获不是学会了多少框架API而是想明白了业务闭环和数据模型怎么对齐。很多初学者拿到需求就开始写代码结果表结构设计不合理前后端接口对不上来回返工。我建议动手前先花两三天把业务流程画清楚把每个状态流转的边界列出来把每张表的字段设计好后面的开发会发现顺畅得多。最后分享一个调试小技巧SSM项目启动慢别每次改完代码就重启Tomcat。把Spring的日志级别调整到DEBUG开发阶段开启热部署改Java代码时通过DevTools或者JRebel自动重启改前端页面时直接用Vue3的dev模式数据通过接口联调这样开发体验会好很多。本文还有配套的精品资源点击获取