企业官网建设流程全解析

简介：一套基于SSM（Spring+SpringMVC+MyBatis）整合layui与Echarts的酒店管理系统完整源码，附带数据库SQL脚本，适合JavaWeb课程设计、SSM项目实战学习或毕业设计参考。项目围绕酒店日常运营，实现客房管理、预订入住、退房结算、系统日志等模块，后端采用SpringMVC+MyBatis分层处理业务，前端以layui构建操作界面，Echarts呈现经营统计图表。压缩包共523个文件，容量约9.88MB，其中150个gif功能预览图便于直观了解页面效果，103个java源码与28个jsp页面构成主要业务代码，30个xml文件承载Spring/MyBatis配置，另有71个js脚本、css样式及1个sql数据库脚本，可直接导入数据库后部署运行。目前已有192人浏览学习，适合从数据库设计、后端业务编码到前端交互与数据可视化全流程研读。通过这套源码可以掌握SSM框架整合技巧、layui组件使用方法和Echarts图表配置思路，是不可多得的JavaWeb综合实践素材。

1. 一套能直接跑起来的SSM酒店管理系统：课程设计、毕业设计都能用

如果你在找JavaWeb课设的完整案例，这套基于SSM（Spring + SpringMVC + MyBatis）+ layui + Echarts的酒店管理系统，属于那种"拿到手就能跑、跑起来就能演示"的项目。它不是只有几个孤立的类文件拼出来的demo，而是一个覆盖了用户登录、客房管理、入住登记、退房结算、营业额统计的完整业务闭环，数据库脚本、Mapper映射、页面模板都在同一个工程目录下，这在课程设计资源里属于稀缺品。适合三类人：一是准备交JavaWeb课设但还没定题的学生，二是想搞懂SSM三层架构和MyBatis实际操作的在职初学者，三是需要一个可二次开发模板、想快速改造成毕设或实训项目的开发者。接下来我会按"目录结构 → 启动部署 → 核心业务代码 → 数据可视化 → 踩坑记录"这条线把它拆透，你照着操作，大概率一个下午就能让系统在自己电脑上跑起来。

2. 先把工程拆开看：目录结构、数据库脚本与SSM框架的运行原理

2.1 目录结构与三层架构：src下的每个包是干什么的

拿到压缩包解压后，主目录是hotel_system-master。第一次打开这类老牌SSM工程，别急着点运行，先看清目录，否则后面改了代码都不知道改在哪一层。

标准SSM项目分成四块：src/main/java放Java源码，src/main/resources放Spring和MyBatis的XML配置，src/main/webapp放JSP页面、layui框架的静态资源以及WEB-INF/web.xml，根目录还有pom.xml或lib文件夹用来管理依赖。这套系统的Java源码里，我从类名上能看到UserVo、OrdersVo、CheckinVo、CheckoutVo、AccountVo、ChartsVo、PieChartsEntity这一批VO类，还有DataVO这类统一返回结构。在SSM架构里，这些类的位置通常是这样的：

hotel_system-master ├── src/main/java │ ├── com.xxx.controller # SpringMVC控制器，所有请求入口 │ ├── com.xxx.service # 业务接口和实现类 │ ├── com.xxx.mapper # MyBatis的Mapper接口（DAO层） │ ├── com.xxx.entity # 数据库实体类（和表结构一一对应） │ ├── com.xxx.vo # ViewObject，给前端页面用的组合对象 │ ├── com.xxx.common # 通用工具类、统一返回结果DataVO │ └── com.xxx.config # Spring、SpringMVC配置类 ├── src/main/resources │ ├── spring-mvc.xml # 控制器扫描、视图解析器 │ ├── spring-mybatis.xml # 数据源、SqlSessionFactory、事务管理 │ ├── mybatis-config.xml # MyBatis全局配置 │ └── mapper # 与Mapper接口对应的XML文件，写SQL的地方 ├── src/main/webapp │ ├── static # layui、Echarts等前端资源 │ ├── WEB-INF │ │ └── web.xml # Servlet容器配置文件 │ └── *.jsp # 页面文件 └── sql └── hotel.sql # 数据库初始化脚本，导入MySQL即可用

如果你打开Idea后看到的目录结构和上面这个大致一致，说明工程是完整的。这里有一个常见误用：有人拿到项目后，直接把Mapper接口当成Dao层强行调用，其实SSM里Mapper就是Dao层，不需要再包一层DaoImpl。控制器调Service接口，Service调Mapper接口，Mapper的SQL写在XML里，这个链路理顺了，后面改业务逻辑就不会手忙脚乱。

2.2 数据库初始化：用SQL脚本建库，别手动建表

系统里所有房间、订单、入住记录、统计报表都依赖数据库。项目里一般会提供sql/hotel.sql或类似名称的脚本，里面包含了建库、建表和少量初始数据。我一般用Navicat或命令行操作，两种方式都可以：

# 命令行方式，先登录MySQL mysql -u root -p # 登录后执行脚本（注意脚本路径换成你本机的） source D:/hotel_system-master/sql/hotel.sql;

如果是用Navicat或者DataGrip，新建连接后右键数据库选择"运行SQL文件"，选中hotel.sql执行即可。执行完后，你会在库里看到用户表、房间表、订单表这几张核心表。这套系统的表设计我没有细看原稿，但从业务上推断通常包含这几张：

建库这一步最容易翻车的是字符集。老项目的SQL脚本里，有些表的默认字符集是latin1或没加UTF-8，插入中文姓名和备注时直接变成乱码。解决方法是执行前先看脚本里有没DEFAULT CHARSET=utf8，没有的话手动改一下，或者建完库统一执行ALTER TABLE user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;。这是个花两分钟就能避免后面所有乱码问题的习惯，值得养成。

2.3 SSM框架整合与配置参数：Spring、SpringMVC、MyBatis在项目里的分工

SSM三件套在旧版JavaWeb项目里几乎是标配，理解它们的装配方式，比单纯跑通项目重要得多，因为你答辩时老师大概率会问"三个框架是怎么协同工作的"。

Spring负责管对象。spring-mybatis.xml里定义了数据源、连接池参数和Mapper扫描路径。数据源这一块，老项目常用的是c3p0或Druid，Druid的配置大概是这样的：

<!-- 数据源配置：这里以Druid为例 --> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="com.mysql.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/hotel?useUnicode=true&amp;characterEncoding=UTF-8&amp;useSSL=false"/> <property name="username" value="root"/> <property name="password" value="你的数据库密码"/> <!-- 连接池参数：初始连接数5，最大活跃连接数20 --> <property name="initialSize" value="5"/> <property name="maxActive" value="20"/> </bean> <!-- SqlSessionFactory：把数据源和Mapper XML整合到一起 --> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> </bean>

SpringMVC负责接请求。spring-mvc.xml里配了控制器扫描路径、JSP视图解析器，还有静态资源的放行。注意这一行很关键：如果static目录下的layui和Echarts加载不出来，多半是拦截器把静态资源拦掉了，通常用<mvc:resources mapping="/static/**" location="/static/"/>放行。MyBatis负责写SQL。它的Mapper接口和XML通过命名空间绑定，比如com.xxx.mapper.RoomMapper接口对应mapper/RoomMapper.xml，XML里的namespace必须写全限定接口名，方法id要和接口方法同名，否则启动就报BindingException。

这个工程能跑起来的前提，就是spring-mybatis.xml和spring-mvc.xml两个配置文件里的路径、账号、密码都对。这个项目是实测能跑通的，属于那种"不分叉、不折腾"的完整案例。

3. 从入住到退房：核心业务表的增删改查链路与参数细节

3.1 用户登录与客房管理：最标准的CRUD写法

登录功能是每个JavaWeb课设的起点。这套系统里用户表大概有username和password字段，登录时先按用户名查用户，再比对密码。安全上老项目通常只是MD5加密，能跑通但不符合现代要求，如果你答辩想加分，可以用BCryptPasswordEncoder做哈希存储。

客房管理是典型的单表CRUD。Controller接收页面传参，Service调用Mapper，Mapper在XML里写SQL。以房间列表查询为例，Service层的常见写法是：

// 房间查询Service实现类 public List<Room> getRoomList(RoomQuery query) { // 调用Mapper查询房间列表 // 分页参数由前端layui table传递：page为当前页，limit为每页条数 return roomMapper.selectRoomList(query); }

对应的Mapper XML里，SQL大概长这样，注意模糊查要用CONCAT('%', #{keyword}, '%')拼接，而不是传一个不带%的keyword进来：

<select id="selectRoomList" resultType="com.xxx.entity.Room"> SELECT id, room_no, type, price, status, remark FROM room <where> <if test="type != null and type != ''"> AND type = #{type} </if> <if test="keyword != null and keyword != ''"> AND (room_no LIKE CONCAT('%', #{keyword}, '%') OR type LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY id DESC <!-- 分页参数由PageHelper或limit传入 --> LIMIT #{offset}, #{limit} </select>

这段SQL里#{}是预编译占位符，能防止SQL注入，这是MyBatis最基础但最重要的特性。如果有人把#写成了${}，那传入参数就会直接拼接进SQL，遇到' or '1'='1这类输入，整张表的数据就全暴露了。课程设计的代码里偶尔能看到这种写法，务必改掉。房间的增删改操作也走同一个套路，Controller接收参数，Service透传，Mapper执行对应的insert/update/delete。这套系统的主线CRUD基本都覆盖了，你把这个链路读通，数据库增删改查这一块在答辩时就不虚。

3.2 入住登记：跨表写入时的事务边界

入住是酒店管理系统里最能体现"业务逻辑"的模块。一次正常入住，不只是往checkin表插一行数据，还要同步更新房间状态为"已入住"，可能还要在order表创建一条订单记录。多个表同时读写，就必须考虑事务。

关于这个模块，从类名能看出有专门的CheckinVo，说明入住页面提交的是一个组合对象，通常包含客户姓名、手机号、所选房间ID、入住日期、预收押金等字段。Service层的入住逻辑一般会长这样：

@Transactional // 声明式事务，所有操作要么全成功，要么全回滚 public void checkin(CheckinVo vo) { // 1. 创建订单记录 Orders order = new Orders(); order.setRoomId(vo.getRoomId()); order.setCustomerName(vo.getCustomerName()); order.setCheckinDate(vo.getCheckinDate()); ordersMapper.insert(order); // 2. 写入入住登记表，关联订单ID Checkin checkin = new Checkin(); checkin.setOrderId(order.getId()); checkin.setDeposit(vo.getDeposit()); checkinMapper.insert(checkin); // 3. 把房间状态改为"已入住"，状态字段0表示空闲，1表示入住 roomMapper.updateStatus(vo.getRoomId(), 1); }

@Transactional这个注解是关键，没有它的话，如果第三步房间状态更新失败，前两步的数据已经写进数据库了，就会出现"订单生成了但房间还是空闲"的脏数据。这个注解默认只在发生RuntimeException时回滚，如果被try-catch吞掉异常，事务照样不会回滚，这是Spring事务里非常经典的坑。我当时在这个项目上踩过一次，后来养成了一个习惯：Service层只抛异常不捕获，让事务管理器统一处理。vue之类的现代前端可能会用ajax提交，但是在这套老SSM项目里，常见做法是表单提交到Controller，Controller通过@RequestBody接收JSON，反序列化成CheckinVo再传给Service。

入住登记这个模块的界面细节，大家做的时候可以参考真实酒店的流程做调整，不需要照搬，重点是理解"一次入住涉及多张表的更新，必须有事务兜底"。这个底层逻辑在真实业务中也是同样的道理。

3.3 退房结算：金额计算、状态回写与报表数据来源

退房结算模块对应CheckoutVo和AccountVo两个类。退房的本质是做一笔结算：算出房费、可能加上其他消费，生成一条结算记录，再把房间状态改回空闲。房费的计算逻辑从代码实现上通常是：取入住日期和当前日期，算出入住天数，再乘以房型的单价。这里有一个经常被忽略的点，就是跨天计算和下半天退房的计算：

// 退房结算核心计算逻辑 public Account settle(CheckoutVo vo) { // 1. 根据入住单查出房间单价，以及入住时间 Checkin checkin = checkinMapper.selectById(vo.getCheckinId()); Room room = roomMapper.selectById(checkin.getRoomId()); // 2. 计算实际入住天数：退房日期减去入住日期，按天数取整 long days = ChronoUnit.DAYS.between( checkin.getCheckinDate(), vo.getCheckoutDate() ); // 如果当天入住当天退，至少按1天算，避免金额为0 if (days < 1) days = 1; // 3. 房费 = 天数 * 单价，再加上其他消费（如有） BigDecimal total = room.getPrice().multiply(BigDecimal.valueOf(days)); BigDecimal extra = vo.getExtraFee() == null ? BigDecimal.ZERO : vo.getExtraFee(); BigDecimal amount = total.add(extra); // 4. 生成结算单并更新房间状态 Account account = new Account(); account.setCheckinId(checkin.getId()); account.setAmount(amount); accountMapper.insert(account); roomMapper.updateStatus(room.getId(), 0); // 0代表空闲 return account; }

这段代码里有几个值得留意的参数细节。第一，日期计算用ChronoUnit.DAYS.between，不要自己去做毫秒除一天的运算，否则遇到夏令时或者时区设置不对，结果会偏差一天。第二，金额计算必须用BigDecimal，不能拿double直接乘，0.1 + 0.2在浮点数里是0.30000000000000004，账单上出现这种数字没法跟老师解释。第三，退房之后除了更新房间状态，还应该检查这笔入住对应的订单是否要完结。有些系统的订单表里有一个status字段，需要置为"已完成"，否则报表统计时订单状态还是"进行中"，数据就乱了。

退房结算是整个系统里"最有味道"的逻辑，因为它串起来三张表的一次联动更新。把这个模块读懂，你对SSM的Service层定位、事务、状态机这几个概念会有一次实打实的质感升级。

4. 从SQL到图表：Echarts可视化模块的完整数据链路

4.1 统计SQL：按天、按房型、按分类统计是报表的核心

课程设计里加了Echarts图表，意味着你需要给前端提供统计后的数据接口。这套系统的ChartsVo和PieChartsEntity就是干这个的。可视化不是把明细表直接丢给前端，而是先让SQL做聚合计算，再把结果封装成图表结构。

最常见的三个统计维度是：按周/月统计营业额、按房型统计入住占比、按天统计订单数量。以"房型入住占比"为例，SQL大概长这样：

-- 统计各房型的入住订单数量 SELECT r.type AS name, COUNT(o.id) AS value FROM room r LEFT JOIN orders o ON r.id = o.room_id WHERE o.status IS NULL OR o.status != '已取消' GROUP BY r.type ORDER BY value DESC;

这个SQL的LEFT JOIN是特意用的，目的是把没有订单的房间也统计成0，防止某些房型直接消失。如果用INNER JOIN，没卖出去的房型就不会出现在饼图里，图表会缺一块，看起来像数据错了。执行完这个查询，拿到的每一行就是name和value两个字段，这正好对应Echarts饼图的数据结构{ name: '大床房', value: 12 }。所以PieChartsEntity这个类里必然有这两个属性，它本质上就是为Echarts饼图做的一次"数据契约"。

再比如按天统计近7天的营业额，SQL里常用DATE_FORMAT(create_time, '%Y-%m-%d')来格式化日期字段，再配上SUM(amount)和GROUP BY日期。处理日期格式时，有两个点容易翻车：一是MySQL和Java的时区不一致，日期差8小时，建连接时在URL后面拼serverTimezone=Asia/Shanghai；二是如果某天没有订单，GROUP BY出来的数据会缺那一天，前端折线图就断档，一般通过后端用Java补齐缺失日期，把值填0。

4.2 前端图表渲染：layui表格与Echarts饼图的联动

前端这块是layui和Echarts分工协作的。layui负责后台管理页面的UI框架，表格、表单、弹窗基本都是layui的组件，比如layui table渲染房间列表、订单列表，layui layer做操作确认弹窗。Echarts单独负责数据可视化图表的绘制，两者是标准配合，没有任何互相干扰。

在展示报表的页面上，常见做法是这样写Echarts初始化：

// 报表图表配置：以饼图为例 var chart = echarts.init(document.getElementById('typeChart')); // 发起ajax请求获取统计数据 $.ajax({ url: '${pageContext.request.contextPath}/admin/chart/roomType', type: 'GET', dataType: 'json', success: function (result) { // 结果外层是DataVO，data字段才是图表数据数组 var data = result.data || []; // 设置Echarts饼图的option chart.setOption({ title: { text: '房型入住占比', left: 'center' }, tooltip: { trigger: 'item' }, legend: { orient: 'vertical', left: 'left' }, series: [{ name: '入住量', type: 'pie', radius: '55%', data: data }] }); } }); // 窗口尺寸变化时自适应，不放的话缩放页面会变形 window.addEventListener('resize', function() { chart.resize(); });

这段代码的两个关键点，直接对应常见的"图表渲染不出来"问题。第一个是echarts.init的容器元素typeChart必须已经有高度，很多人把初始化代码放在页面加载前，div高度还是0，图就只显示一个坐标轴或者干脆空白。解决方式是给容器一个明确的CSS高度，比如height: 400px。第二个是初始化时机，如果页面里既有layui的tab切换又有Echarts，切换tab隐藏的图表容器在重新显示时可能会布局错乱，常见解法是在tab切换事件里调用chart.resize()。数据从后端返回时，用DataVO统一包装是最规范的做法，Controller返回一个JSON对象，里面固定有code、msg、data三个字段，前端拿data喂给图表，逻辑清晰，前端代码也因此非常干净。

4.3 统计接口封装：DataVO如何向Echarts吐数据

这套系统里，DataVO是贯穿前后端的统一返回结构。接口返回的数据通常是一个包含code、msg、data的JSON，data就是具体的内容。如果data是一个List，那它最终会被Echarts拿来直接用。以折线图统计近7天营业额为例，ChartsVo里大概会有一个List<Map<String, Object>>或者直接封装成DateValueVo的结构，每个节点存date和amount两个字段。前端拿到之后再转换成Echarts折线图的xAxis.data和series.data，中间一层转换是可视化模块最常见的代码量所在。

这里有个细节值得学习：后端不要直接返回数据库查询的原生Map，因为SQL查询出来的字段名是下划线风格（total_amount），而Echarts和前端JS习惯驼峰风格（totalAmount）。处理方式有两种，一种是在SQL里用别名转换，另一种是后端Java类用@JsonProperty注解映射。二选一即可，但必须统一，否则前端反复试来试去，图还是空的，最后发现是字段名对不上，纯浪费时间。

5. 避坑指南：这套SSM酒店管理系统最常见的五个翻车现场

5.1 Idea里运行报错：找不到Mapper接口的Bean

现象：启动Tomcat时报Error creating bean with name 'xxxMapper'或BindingException: Invalid bound statement (not found)。

原因：有两种可能。一是spring-mybatis.xml里配置的mapperLocations路径写错了，指定的是classpath:mapper/*.xml，但你的Mapper XML实际放在别的目录下。二是Mapper接口和XML文件在编译后没有放在同一个目录，Maven项目里如果XML没被识别成资源，就会被漏掉。

解决：先检查target/classes目录下有没有mapper文件夹，没有就说明资源没打进去，在pom.xml里加一条<resource>配置，把XML声明为资源。再看XML里的namespace是否和接口的全限定名一致，<select>标签的id是否和接口方法名相同。这两处对了，99%的Mapper问题都能解决。

5.2 数据库中文乱码：页面显示"？？？"或者中文都变成了问号

现象：登录后页面上的房间类型、客户名称显示成问号。

原因：建库时字符集不是UTF-8，或者JDBC连接串没指定characterEncoding。老项目SQL脚本里，有些表默认是latin1，插入中文时MySQL直接丢弃超范围字符。

解决：先把表和库的字符集全部改成utf8mb4，这个字符集兼容emoji，比utf8更安全。再改JDBC连接串，核心是把URL末尾加上?useUnicode=true&characterEncoding=UTF-8。改配置后记得重启Tomcat，并确认hotel.sql里的CREATE TABLE语句都带了DEFAULT CHARSET=utf8mb4。

5.3 layui表格列对不上：列表显示"空"或者列错位

现象：表格能渲染出表头，但每一行的数据全是空，或者字段显示到错误的列上。

原因：layui表格的cols配置里的field名称和后端返回JSON的字段名不一致。后端返回的是roomNo，前端配置写的是room_no，就对不上。

解决：统一以SQL查询的返回字段为准。最简单的方式是在后端SQL里就给字段起别名，返回给前端的字段名直接就是camelCase，比如SELECT room_no AS roomNo FROM room。或者把前端lcols里的field改成和下划线版本一致，两条路选一条，别来回折腾。这个是JavaWeb项目里最家常的翻车，我第一次用layui时在这上面愣是查了一个多小时，很憋屈。

5.4 Echarts图表不显示或显示错位

现象：页面有容器区域，饼图、柱状图都渲染不出来，控制台报Cannot read property 'init' of undefined；或者页面在iframe/弹窗里时图表宽高有问题。

原因：两个方向。第一是Echarts的JS文件没引入，路径写错，浏览器加载404；第二是图表容器初始化时没有高度或宽度。

解决：先打开浏览器的Network面板看有没有红色404，有就改JS引入路径。再检查初始化代码执行时容器是否存在，初始化代码放在body底部或document.ready之后执行，别放在head里。给容器显式加一行CSS：#typeChart { width: 100%; height: 400px; }，基本能解决一大半图表不显示的问题。如果你在layui弹窗里渲染图表，弹窗关闭再打开，图表会重复初始化，比较稳妥的解法是每次打开弹窗后重新init并setOption，这是layui弹窗和Echarts搭配最常见的坑。

5.5 Tomcat部署后页面404：访问路径对不上

现象：Tomcat启动成功，项目列表也有，但访问时404，有些页面能开，有些开不了。

原因：项目上下文路径（context path）和访问URL不对应。Idea默认的Application context是/hotel_system_war_exploded，你访问时没带这一段，或者JSP里的basePath写死成了别的路径。

解决：在Idea的Run Configuration里，把Deployment的Application context改成/，这样访问根路径就能直达项目首页。JSP页面里尽量使用pageContext.request.contextPath拼路径，不要手写绝对路径字符串。用${pageContext.request.contextPath}/admin/login.jsp这种写法，不管部署到哪个上下文都不会404。这一条在答辩前自查时非常重要，有时候代码完全没问题，纯粹是路径没配对，当场翻车就很尬。

6. 答辩前的自我改造：用这三个小动作让课设从"能跑"变成"亮点"

第一件事，给数据库连接串换一个Druid监控。老项目只有c3p0纯连接池的话，在pom.xml里引入druid依赖，把数据源改成Druid，然后访问/druid/index.html就能看到SQL执行次数、慢查询、并发连接数。这不会花超过半小时，但老师问"项目性能怎么样"的时候，你直接打开监控页给他看数据，这个效果比空口说"很流畅"有说服力得多。

第二件事，用AOP加一个操作日志切面。现在系统里有SysLogVo和AccountVo，说明可能已经有日志表。但更完整的做法是写一个切面，拦截所有控制器操作，自动记录"谁在什么时间干了什么"。

// 登录日志切面：记录用户操作到sys_log表 @Aspect @Component public class SysLogAspect { // 登录成功后在controller的login方法执行后记录 @AfterReturning("execution(* com.xxx.controller.LoginController.login(..))") public void recordLoginLog(JoinPoint point) { // 记录操作人IP、时间、请求URL // 常用做法：从request里取IP，从session里取当前用户名 } }

切面功能我不确定原工程里是否完整实现，但如果你发现日志功能只是留了表没写逻辑，自己补上这个切面是答辩场上绝对值得的加分操作，因为AOP是Spring框架面试提问频率相当高的点。

第三件事，改造Echarts图表的交互，接一个点击事件。

// 给饼图加点击联动：点击某房型后刷新下方明细表 chart.on('click', function (params) { $('#roomTypeTable').data('type', params.name); // 重新加载layui表格数据 table.reload('roomTypeTable', { where: { type: params.name } }); });

这个用法都不用解释太多，老师看到的直观效果是"点击图表上的房型，下方的表格自动过滤并显示该房型的订单明细"。图表和表格联动，这种交互在课程设计里比较少见，能把评委的注意力从"这个图表是不是复制来的"转到"这套系统有设计感"上。从那以后我每次带课设项目，都会强制自己至少做一个"图→表联动"的交互，再搭配Druid监控和AOP日志，这三个改造做下来，课设答辩基本稳了。希望帮到你。

本文还有配套的精品资源，点击获取