企业官网建设流程全解析

简介：本资源是一套基于SSM框架与MySQL数据库开发的网约车用户服务平台完整实现方案，面向Java Web初学者、课程设计学生及毕业设计开发者，解决轻量级出行服务系统从需求分析到部署落地的全流程实践问题。压缩包共包含源码、MySQL数据库脚本及配套设计文档，总大小61.55MB，涵盖Spring、SpringMVC、MyBatis三层架构代码、可直接导入的SQL建表与初始化数据、以及含ER图、功能模块说明与接口设计的详细文档，便于快速理解系统结构与二次开发。已有28952人学习下载，资源结构清晰，用户端支持游客浏览、注册登录、新闻查看、在线打车与订单查询；司机端提供信息管理、接单操作与订单状态处理等核心业务逻辑，代码注释充分，数据库字段定义明确，适合作为教学参考、项目复现或功能扩展的基础模板。 做网约车平台的毕业设计或者项目练手，很多同学第一反应是“不就一个打车软件吗”，真动手才发现，光是订单状态怎么流转、司机和乘客的位置信息怎么关联、数据库表怎么设计才能扛住并发，就能卡住好几天。我这次用SSM+MySQL把网约车用户服务平台完整落地了一遍，源码、数据库脚本、设计文档都整理齐了，这篇就系统性拆解一下整个项目的设计与实现过程，把那些网上零散讲不清楚的细节一次说透。

这个项目适合正在做Java Web方向毕业设计的学生，也适合准备入职外包或中小型公司、想快速熟悉SSM整合流程的初级开发。整个平台围绕用户、司机、订单、支付、评价这几个核心域展开，采用经典的分层架构，前端用JSP+Ajax，后端走SpringMVC的Controller-Service-Mapper三层调用，数据库端负责事务和存储过程。我会从业务模块划分、库表设计、核心流程实现、避坑经验四个角度展开，前半部分偏设计思路，后半部分全是实操细节。

1. 网约车用户服务平台的需求边界：先理清业务再动手写代码

网约车平台表面上只有“乘客叫车、司机接单”两个动作，但作为一个完整的用户服务平台，业务模块远不止这些。我在做需求分析时，把整个系统拆成了五个核心子模块：用户管理、司机管理、订单管理、支付与结算、评价与投诉。每个子模块再往下拆，才进入具体的表结构和接口设计。

1.1 用户端和管理端的功能差异

用户端的功能聚焦在乘客的使用体验上：注册登录、实名认证、发起订单、行程展示、支付车费、历史订单查询、投诉建议。管理端则侧重于平台运营侧的管控能力：司机入驻审核、车辆信息管理、订单监控、异常订单处理、数据统计。这两端的功能并不是对称的，很多人在设计时会犯一个错误——把用户端和管理端做成两套完全割裂的系统，导致代码大量重复。

我的做法是：底层共享同一套Service层，用户端Controller和管理端Controller分别指向不同的接口方法。比如订单查询，用户端只需要看到自己的订单，管理端需要看到全量订单，但底层的订单查询逻辑是完全一致的，只是条件参数不同。这样既避免了两套代码维护的麻烦，又保证了权限隔离。

1.2 角色权限模型怎么设计

网约车平台天然存在三种角色：乘客、司机、平台管理员。在SSM框架下，我使用拦截器（HandlerInterceptor）实现最简单的基于Session的角色访问控制。

public class RoleInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); // 从请求路径中判断当前访问的资源属于哪类角色 String uri = request.getRequestURI(); if (uri.startsWith("/admin/")) { if (user == null || !"ADMIN".equals(user.getRole())) { response.sendRedirect(request.getContextPath() + "/login"); return false; } } else if (uri.startsWith("/driver/")) { if (user == null || !"DRIVER".equals(user.getRole())) { response.sendRedirect(request.getContextPath() + "/login"); return false; } } return true; } }

这里有一个容易被忽略的细节：网约车平台中乘客和司机共用一张用户表，通过role字段区分。很多设计会把司机单独建一张表，看起来是两个体系，实际上司机也拥有乘客身份（司机下班后也要打车），共用一张表反而更贴合真实业务。我在user表中增加一个is_driver字段，司机额外的资质信息放在driver_info表中，用外键关联，这样既保持了用户基础的统一，又让司机扩展属性不污染用户表。

1.3 这些功能点必须细化到能落地的程度

做毕业设计最容易踩的坑是功能列表写得很大，实际只做了增删改查。我在需求分析阶段，把每个功能点都细化到“字段级别”，比如“发布订单”这个功能，需要明确的字段包括：出发地经纬度、目的地经纬度、预计距离、预计时长、订单类型（实时/预约）、乘客备注、期望车型。字段明确之后，数据库表结构就自然而然出来了，不用对着空白屏幕死想。

2. SSM框架整合的完整过程：为什么这么配，以及配置文件里那些说不清的坑

SSM即Spring + SpringMVC + MyBatis，三个框架各自负责不同层面的职责：Spring管理对象和事务，SpringMVC处理请求路由和参数绑定，MyBatis负责持久层SQL映射。很多人学的时候能看懂单个框架，整合的时候却经常在配置文件上栽跟头——报错信息看不懂，配置顺序颠倒，依赖版本冲突。

2.1 项目依赖的版本搭配，直接决定你少踩一半的坑

我先说一下我这次使用的版本组合，都经过实际验证可以正常协同工作：

这个版本组合里，最需要注意的是MyBatis和MyBatis-Spring的兼容关系。MyBatis 3.5.x必须搭配MyBatis-Spring 2.x，如果用了3.4.x的MyBatis却配了1.x的适配包，启动时会报BindingException。另外Druid的版本不建议太老，1.1.x在某些MySQL驱动版本下会出现连接不释放的问题，1.2.x更稳定。

2.2 Spring配置文件的职责拆分，而不是一堆配置塞一起

SSM框架下配置文件的组织方式很关键，我习惯拆成三个独立文件，每个文件只负责自己的事情。

spring-mvc.xml负责Controller的扫描和视图解析，同时开启注解驱动：

<context:component-scan base-package="com.car.platform.controller"/> <mvc:annotation-driven/> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/views/"/> <property name="suffix" value=".jsp"/> </bean>

spring-service.xml负责Service层Bean的注册和事务管理：

<context:component-scan base-package="com.car.platform.service"/> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close"> <property name="driverClassName" value="com.mysql.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/car_platform?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai"/> <property name="username" value="root"/> <property name="password" value="123456"/> <property name="initialSize" value="5"/> <property name="maxActive" value="20"/> </bean>

spring-mybatis.xml负责Mapper接口和SqlSessionFactory的组装：

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="typeAliasesPackage" value="com.car.platform.entity"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.car.platform.dao"/> </bean>

很多人整合失败是因为没有分清楚哪个配置归谁管。你去排查SSM启动报错，先判断是容器创建失败还是请求映射失败——前者多半是spring-service.xml里的数据源或Bean注入有问题，后者才是spring-mvc.xml的扫描路径不对。

2.3 Mapper层的SQL映射方式：我们不用注解SQL

现在很多人用Spring Boot+MyBatis-Plus习惯了，直接在Mapper接口上写@Select注解。但SSM时代的标准做法是XML映射文件，这也是网约车用户服务平台这类查询条件多变的系统最合适的方式。比如订单列表查询，用户可能按状态查、按时间查、按司机查、按乘客查，条件组合非常多，用XML文件的动态SQL可以优雅处理。

<select id="queryOrders" resultType="com.car.platform.entity.Order"> SELECT * FROM t_order <where> <if test="userId != null"> AND user_id = #{userId} </if> <if test="driverId != null"> AND driver_id = #{driverId} </if> <if test="orderStatus != null"> AND order_status = #{orderStatus} </if> <if test="startTime != null"> AND create_time &gt;= #{startTime} </if> </where> ORDER BY create_time DESC </select>

这个动态SQL的价值在于：用户端和管理端可以复用同一个Mapper方法，只是传入参数不同。如果你用注解写SQL，遇到这种多条件查询就会写一堆字符串拼接，维护起来痛不欲生。

3. MySQL数据库设计：网约车核心表的结构、索引与事务考虑

数据库设计决定整个项目能走多远。网约车业务涉及的金额计算、订单状态变更、并发抢单，如果表结构设计不牢固，后面每做一步都是在补窟窿。

3.1 核心表结构：从用户到订单的完整建模

我最终落地的库表一共9张，核心的5张表分别是用户表、司机信息表、订单表、支付记录表、评价表。

用户表（t_user）的设计要点是：把乘客和司机的公共属性放在一张表，role字段区分身份，手机号做唯一索引，密码使用MD5加盐存储。

CREATE TABLE `t_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `phone` varchar(11) NOT NULL COMMENT '手机号，登录账号', `password` varchar(64) NOT NULL COMMENT '密码，MD5加盐', `username` varchar(32) DEFAULT NULL COMMENT '昵称', `real_name` varchar(20) DEFAULT NULL COMMENT '真实姓名', `id_card` varchar(18) DEFAULT NULL COMMENT '身份证号', `role` varchar(10) NOT NULL DEFAULT 'USER' COMMENT '角色：USER/DRIVER/ADMIN', `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单表（t_order）是整个系统的核心，包含用户与司机的所有关联信息：

CREATE TABLE `t_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `user_id` bigint(20) NOT NULL COMMENT '乘客ID', `driver_id` bigint(20) DEFAULT NULL COMMENT '司机ID，接单后写入', `start_lng` decimal(10,7) NOT NULL COMMENT '出发地经度', `start_lat` decimal(10,7) NOT NULL COMMENT '出发地纬度', `start_addr` varchar(255) NOT NULL COMMENT '出发地地址', `end_lng` decimal(10,7) NOT NULL COMMENT '目的地经度', `end_lat` decimal(10,7) NOT NULL COMMENT '目的地纬度', `end_addr` varchar(255) NOT NULL COMMENT '目的地地址', `order_type` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1实时订单 2预约订单', `order_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待接单 1已接单 2已到达 3行程中 4已完成 5已取消', `amount` decimal(10,2) DEFAULT NULL COMMENT '实际金额', `estimate_amount` decimal(10,2) DEFAULT NULL COMMENT '预估金额', `distance` decimal(10,2) DEFAULT NULL COMMENT '里程（公里）', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `accept_time` datetime DEFAULT NULL COMMENT '接单时间', `finish_time` datetime DEFAULT NULL COMMENT '完成时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`), KEY `idx_driver_id` (`driver_id`), KEY `idx_order_status` (`order_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这个订单表的设计有几个值得细说的点。第一，经纬度使用decimal(10,7)而非float/double，float有精度损失，定位偏差会导致订单派给错误的司机。第二，订单状态使用tinyint类型，并且用注释明确每位数字的含义，避免后续开发时靠猜。第三，订单编号和主键分离，主键是自增id，订单编号是业务唯一键，这样外部系统（比如支付回调）只需要知道订单号，不需要暴露数据库自增id。

3.2 索引设计的实战经验：哪些字段建索引，哪些别乱建

索引这块，我见过很多人把所有查询条件字段都建上索引，结果反而拖慢写入。网约车平台的索引设计要点是：

• 用户表：phone建唯一索引，这是登录查询的直接依据。
• 订单表：user_id、driver_id、order_status都要建索引。订单按用户查询是高频操作，按状态查询是管理端高频操作。order_no建唯一索引，因为支付回调要根据订单号定位记录。
• 支付记录表：pay_no、order_id建索引。

要注意不要单独给create_time建索引，因为查询条件通常是“user_id + create_time”组合，单独建create_time索引几乎不会被用到，反而占用空间。如果确实需要按时间维度统计，等到数据量大了再考虑。

3.3 事务控制：金额相关操作必须保证原子性

网约车平台的资金流水必须使用事务。比如订单完成后的金额结算，涉及到订单状态更新、司机收入增加、平台抽成记录三个操作，任何一个失败都会导致数据不一致。

@Transactional(rollbackFor = Exception.class) public void finishOrder(Order order, PaymentRecord payment) { // 1. 更新订单状态为已完成 orderMapper.updateStatus(order.getId(), 4, new Date()); // 2. 记录支付流水 paymentMapper.insert(payment); // 3. 更新司机账户余额 driverAccountMapper.increaseAmount(order.getDriverId(), order.getAmount() * 0.8); }

这里的rollbackFor = Exception.class很重要。Spring默认只对运行时异常回滚，如果代码里抛的是检查异常（比如IOException），不加这个参数的话事务不会回滚，会造成非常隐蔽的金额问题。这是面试常问、项目里容易踩的经典坑。

4. 订单核心流程实现：从叫车到订单完成的状态机设计

订单是整个网约车平台的灵魂，状态流转的合理性直接决定系统好不好用。我设计了6个订单状态，对应从创建到结束的完整生命周期：

4.1 为什么用状态值而不是直接改字符串

新手写订单状态最容易犯的错误是直接在数据库存文字描述，比如order_status = '已完成'。这样看似直观，但有几个严重问题：

第一，中文作为条件查询在数据库里需要字符集完全匹配，大小写、空格都会导致查询不到；第二，如果后续增加新状态，字符串长度和描述都可能需要改表结构；第三，程序里判断状态必须写中文常量，容易出拼写错误。用数字枚举值，代码里定义好常量，数据库里存数字，展示层再映射为文字，这是正规项目的标准做法。

4.2 并发场景下的抢单处理：数据库行锁保证不超卖

网约车平台最核心的并发问题是“多个司机同时抢同一个订单”。如果不做控制，两个司机可能同时读到订单状态为“待接单”，然后同时更新为“已接单”，造成订单被抢两次。

我的解决办法是使用乐观锁，在订单表中增加version字段：

@Update("UPDATE t_order SET driver_id = #{driverId}, order_status = 1, accept_time = NOW(), version = version + 1 WHERE id = #{orderId} AND order_status = 0 AND version = #{version}") int grabOrder(@Param("orderId") Long orderId, @Param("driverId") Long driverId, @Param("version") Integer version);

执行UPDATE后，通过返回的受影响行数判断是否抢单成功。如果行数为0，说明其他司机已经抢先一步，当前驱动需要提示“手慢了，订单已被接走”。这种利用数据库原子性实现并发控制的方式，对比Java层加锁可控性更强——即使应用部署在多台服务器上，数据库层的行锁也能保证全局唯一。

4.3 取消订单的超时处理：定时任务还是懒取消

用户叫车后如果没有司机接单，订单会一直停留在“待接单”状态。我采用的方案是：在用户发起订单时设置一个有效期（比如5分钟），查询订单时自动过滤超过有效期的订单，并将其标记为“已超时取消”。

这里我刻意没有引入Quartz定时任务去“清理”超时订单，而是用懒取消的方式——只有当某个用户或司机查询到这个超时订单时，才把它更新为取消。这样避免了一个定时任务高频扫描订单表，也简化了整个系统的复杂度。对于毕业设计来说，这个设计思路够用且好理解，面试时还能讲清楚为什么这么取舍。

public List<Order> getPendingOrders() { List<Order> orders = orderMapper.selectByStatus(0); Date now = new Date(); for (Order order : orders) { // 如果超过5分钟没有司机接单，自动标记为超时取消 if (now.getTime() - order.getCreateTime().getTime() > 5 * 60 * 1000) { orderMapper.updateStatus(order.getId(), 5); continue; } list.add(order); } return list; }

4.4 计费规则的实现：如何做到预估金额和实际金额一致

计费是网约车平台最容易被较真的环节。我的计费方式是：基础起步价 + 里程费 + 时长费，不同城市配置不同，所以我单独建了一张计费规则表，而不是把价格写死在代码里。

司机端开始行程时，前端定时上报经纬度，后台计算距离。对于毕业设计，不需要真的做路线规划和高精度轨迹纠偏，用高德地图API计算两点的行驶距离，累计得到总里程，再按公式金额 = 起步价 + max(0, 总里程 - 起步里程) * 每公里单价 + 总时长 * 每分钟单价计算。这样实现简单，演示效果也足够。

5. 前端页面与后端交互：JSP + Ajax + JSON 的联调细节

前端在这一类传统SSM项目里往往不是重点，但它决定了答辩时展示效果好不好。我采用的是JSP页面配合Ajax异步请求，后端返回JSON数据，前端动态渲染。

5.1 为什么不用模板引擎而是选择前后端分离思路

SpringMVC本身支持JSP的功能很成熟，但纯JSP渲染有个难受的点——每次页面跳转都会刷新整个页面，用户的体验接近于传统Web应用，不符合网约车这类以单页交互为主的产品调性。

我的方案是：页面加载时后端只返回一个壳子（包含静态HTML、CSS、JS引用），数据全部通过Ajax从后端接口获取，前端用jQuery或者原生JS动态生成DOM。这种半前后端分离的方式，对于SSM项目来说性价比很高：保留了JSP静态页面的简单性，又获得了接近现代Web应用的操作体验。

5.2 SpringMVC返回JSON的配置与常见报错

在spring-mvc.xml中，还需要配置消息转换器，否则Controller返回的对象不能正常序列化为JSON：

<mvc:annotation-driven> <mvc:message-converters> <bean class="org.springframework.http.converter.json.MappingJackson2HttpMessageConverter"> <property name="objectMapper"> <bean class="com.fasterxml.jackson.databind.ObjectMapper"> <property name="dateFormat"> <bean class="java.text.SimpleDateFormat"> <constructor-arg value="yyyy-MM-dd HH:mm:ss"/> </bean> </property> </bean> </property> </bean> </mvc:message-converters> </mvc:annotation-driven>

这个配置里有几个点值得说：第一，如果没有引入Jackson的依赖，这里会报ClassNotFoundException: com.fasterxml.jackson.databind.ObjectMapper，需要在pom.xml中添加jackson-databind；第二，如果ObjectMapper没有配置日期格式化，Java的Date字段序列化出来是一串时间戳，前端根本没法用，所以必须在这里统一日期格式。

提示：如果用了@ResponseBody接口却报406 Not Acceptable，排查顺序：先确认Jackson依赖已加，再确认spring-mvc.xml里mvc:annotation-driven存在且消息转换器注册成功，最后检查后端返回类型是否被正确识别为JSON。90%的406都是依赖缺失或者配置遗漏。

5.3 联调时涉及到的跨域与浏览器兼容问题

本地开发时，前端可能跑在8080端口，后端跑在8081端口，这个时候浏览器会拦截跨域请求。我开发时在Controller上加了统一跨域处理：

@CrossOrigin(origins = "*", maxAge = 3600) public class BaseController { }

让所有Controller继承BaseController，这样开发阶段前后端分离部署不会跨域报错。上线阶段如果前后端部署在同一域下，可以再把@CrossOrigin去掉。实际操作中，Chrome浏览器还会遇到一个问题：如果JSP页面用window.location.href跳转，URL中的中文参数会被浏览器自动编码，后端接收时需要先URLDecoder.decode，这个坑在行程地址搜索功能上特别常见。

6. 项目部署与演示：从本地跑通到答辩演示的完整准备

做这类项目，代码写完只是第一步，成功部署并稳定运行才是项目完成的标志。我用Windows本地环境部署了一套可演示版本，把关键步骤和容易出错的地方都记录下来。

6.1 本地部署的三步流程：环境、数据库、Tomcat

环境要求很简单：JDK 1.8、Maven 3.x、MySQL 5.7、Tomcat 8.5。依次确认这四个基础环境都安装好之后，部署过程分为三步：

1. 导入数据库：用Navicat或命令行执行项目中的car_platform.sql脚本，执行完成后确认9张表都创建成功，没有报错。
2. 修改配置文件：打开jdbc.properties，将数据库用户名和密码改为本地环境的值。
3. 启动Tomcat：项目打包成war包放到Tomcat的webapps目录，启动Tomcat，访问http://localhost:8080/car_platform/。

如果启动过程中报ClassNotFoundException: org.springframework.web.context.ContextLoaderListener，说明Spring的jar包没有被Tomcat加载，检查Maven的pom.xml中Spring相关的依赖是否设置了<scope>provided</scope>。这个是Maven项目的经典问题，很多从Eclipse直接导出的war包也会遇到。

6.2 答辩演示的脚本设计：让面试官/老师一眼看出系统完整度

一个功能点全做但没有演示脚本，答辩时容易手忙脚乱。我按照“正常业务流 + 异常场景”两个维度设计了演示流程：

• 正常业务流：用户注册（演示手机号唯一校验）→ 用户登录 → 发起实时订单 → 切换到司机账号 → 司机接单 → 到达起点 → 开始行程 → 到达目的地 → 订单完成 → 查看支付记录 → 乘客评价。
• 异常场景演示：未登录状态点击“发布订单”，验证拦截器是否生效；用户重复注册同一手机号，验证唯一约束；两个司机同时抢单，验证只有一个能成功。

这个演示流程覆盖了系统四大核心功能（用户、订单、支付、评价），同时展示了角色的权限控制能力，是答辩时最加分的部分。

6.3 项目文档的组织方式

很多同学源码写完了，文档却不会写。我的文档结构分为五个部分：需求分析（含用例图与功能列表）、数据库设计（含ER图和表结构说明）、系统设计（含架构图和模块划分）、核心功能实现说明（含关键代码解释）、测试与部署说明。文档里附了每一个接口的请求参数和返回示例，这样后续扩展功能时，照着文档就能快速定位到对应代码位置。

7. 做这个项目踩过的坑与最终收获

我最终把整套项目跑通，最值钱的并不是“能跑”这个结果，而是踩坑过程中积累的那些排查思路。这里把印象最深的几个问题往后复盘一次，希望对你有直接的帮助。

7.1 时间字段的时区问题，让数据凭空少了8小时

第一次做项目时，数据库里的时间字段显示正常，但经过MyBatis映射到Java实体后，所有时间都多了8小时。排查了很久，根因是MySQL连接URL中没有指定serverTimezone参数，系统默认用了UTC时区，而本地是东八区。

解决方案就是在数据库连接URL中加入serverTimezone=Asia/Shanghai。这个问题在部署到Linux服务器时更容易出现，因为服务器默认时区往往不是中国时区，建议在启动参数中加上-Duser.timezone=GMT+08兜底。

7.2 MyBatis的</if>标签坑：动态SQL的边界条件

动态SQL用起来方便，但标签写错时MyBatis的报错信息非常不友好。有一次我写了<where>标签，内部的<if>条件全部不满足，MyBatis生成了WHERE关键字后面没有任何条件的SQL，查询报语法错误。

排查这个问题的方法是把MyBatis的日志级别设为DEBUG，在日志中打印实际执行的SQL语句：

<logger name="com.car.platform.dao" level="DEBUG"/>

这样日志里能看到动态SQL拼接后的完整语句，一眼就能定位是标签逻辑错误还是SQL本身的问题。这个排查技巧比盯着XML文件看十分钟高效得多。

7.3 数据源的连接泄漏问题：Druid监控竟然能救你一命

项目在长时间运行时，偶尔出现页面响应特别慢，重启Tomcat即可恢复。通过Druid的监控页面查看连接池使用情况，发现activeCount（活跃连接数）持续增长，说明有连接没有被正确归还。

根因是某些查询方法中，我手动获取了Connection对象，开启了事务，但在异常分支没有调用connection.close()，导致连接泄漏。通过Druid的Web监控页面，可以看到是哪个SQL占用了连接，快速定位到代码位置。

Druid监控的配置方式：

<servlet> <servlet-name>DruidStatView</servlet-name> <servlet-class>com.alibaba.druid.support.http.StatViewServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>DruidStatView</servlet-name> <url-pattern>/druid/*</url-pattern> </servlet-mapping>

访问http://localhost:8080/car_platform/druid/，输入配置的用户名密码即可查看连接池状态、慢SQL统计、活跃连接等信息。这个监控工具对排查连接泄漏和SQL性能问题帮助巨大，面试时主动提这个，远比你背八股文印象深刻。

7.4 最终收获：SSM没你想的那么“老”，它是一套更扎实的基础认知

做完整套项目后，我的感受是：SSM并不“老”，它去掉了很多Spring Boot或MyBatis-Plus的自动化封装，让你必须自己动手配置数据源、事务、映射关系，这反而让底层逻辑变得非常清晰。你今天用Spring Boot开发MyBatis-Plus时感觉一切理所当然，正是因为SSM踩坑阶段已经把那些封装遮住的知识都补上了。

如果你也要做网约车平台或者类似的SSM项目，我的建议是：不要急着写代码，先把表结构设计到位，然后让订单状态机完全跑通，再补业务细节。中间遇到任何报错，把错误信息贴到搜索引擎之前，先自己读一遍项目日志，很多时候答案就在日志里。

最后再分享一个小的经验：给这个平台做测试数据时，不要只用1、2这种编号，制造20个用户、20个司机、50条订单，模拟出真实的数据密度。你才会发现列表分页的必要性、查询条件的优化空间，甚至表索引设计是否合理——这些只有数据量上来之后才看得出来，也是动手项目中“实践”二字真正的价值。

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