企业官网建设流程全解析

简介：基于SSM框架（Spring、Spring MVC、MyBatis）和MySQL数据库实现的超市会员积分管理系统，是一套面向计算机相关专业在校学生、老师及企业员工的高分成品毕业设计，适用于毕业设计、课程设计、作业或初期立项演示。项目内容涵盖完整后端源码、往届论文、说明文档与数据库脚本，能够帮助学习者深入理解会员信息维护、积分累计、积分兑换、消费记录查询等核心业务模块的实现流程。压缩包内共989个文件，文件类型以java、jsp、css、js、sql及png等为主，其中java和xml负责服务端逻辑与配置，jsp和html等构建页面，css与js完善样式和交互，sql提供初始化数据，包体大小约11.48MB，目录结构完整，便于对照源码、论文和文档进行学习。目前已有83人学习或下载，下载后建议先阅读README与论文说明，运行中遇到问题可联系作者获得远程指导。总体而言，这份资料既能作为毕业设计答辩的参考资料，也可用于练习SSM框架整合开发，价值较为实用。

1. 为什么毕业设计选型总绕不开 SSM+MySQL 组合

超市会员积分管理系统是 JSP/SSH 之后毕业设计里出现频率最高的一类业务系统，原因在于它的业务模型非常标准：会员档案、积分累计、积分兑换、等级成长，每张表之间的外键关系和事务边界清晰，刚好能覆盖一个 Java Web 项目从数据建模到页面展示的完整链路。而 SSM 三件套加 MySQL 的组合至今没有被淘汰，并非因为它新，而是因为 Spring 的 IoC/声明式事务、Spring MVC 的请求分发、MyBatis 的半自动 SQL 控制这三层耦合方式足够"经典"，在简历上写出来，面试官能顺着这条链路连环追问，你也能顺着回答。

以我过去带毕设的经验来看，绝大多数同学卡住的地方不在业务逻辑，而在框架整合的配置文件上。SSM 整合涉及的 XML 或配置类往往有七八个，任何一个路径写错、依赖版本冲突，启动时就报 BeanDefinitionStoreException 或 Invalid bound statement，这一卡就是两三天。这篇文章围绕"如何把超商积分系统从零搭建到可跑通积分累计和兑换"展开，给出一个能落地的工程路径和关键参数说明。适合正在做毕设答辩准备、或者想在实际项目里复用这套技术栈的读者。

2. SSM 框架整合的底层逻辑与 Maven 工程搭建

2.1 三个框架各管哪一段：从请求到数据库的完整旅程

SSM 与其说是三个框架的并列，不如说是一条责任链。Spring MVC 负责接待 HTTP 请求，把 URL 映射到 Java 方法；Spring 容器负责管理 Service 层和 DAO 层的对象生命周期，以及控制事务边界；MyBatis 负责把接口方法变成 SQL 执行，再把结果集映射成 POJO。三者之间通过 Spring 的 IoC 容器统一装配，Spring MVC 的 Controller 是容器里的 Bean，MyBatis 的 Mapper 接口代理对象也注册在容器里。

这条链路上最容易被误解的是 MyBatis 的"半自动"定位。Hibernate 用 HQL 和对象关系映射来屏蔽 SQL，MyBatis 则把 SQL 写在 Mapper XML 里，由开发者完全掌控。对于超商积分系统这种有复杂报表查询、多表关联统计的场景，MyBatis 这种模式有明显优势。比如查询"本月每个会员的积分变动明细"，用 Hibernate 要写 Criteria 或 HQL 关联，用 MyBatis 直接写一条带 JOIN 和 GROUP BY 的 SQL 就可以了。面试时如果被问到为什么选 MyBatis 而不是 Hibernate，这就是最好的回答素材。

2.2 从零初始化 Maven 工程：pom.xml 的版本仲裁

创建项目时最稳妥的方式是使用 Maven 的 webapp 原型，或者直接手工建一个普通 Java 工程再补上 src/main/webapp 目录。我建议不要用 Spring Initializr 生成，因为那默认是 Spring Boot 工程，和 SSM 的 war 包部署方式有本质区别。一个标准 SSM 的 pom.xml 核心依赖如下：

<properties> <spring.version>5.3.39</spring.version> <mybatis.version>3.5.16</mybatis.version> <mybatis-spring.version>2.1.2</mybatis-spring.version> <mysql.version>8.0.33</mysql.version> <jackson.version>2.15.4</jackson.version> </properties> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>${mybatis.version}</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>${mybatis-spring.version}</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <version>${mysql.version}</version> <scope>runtime</scope> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>${jackson.version}</version> </dependency> </dependencies>

这段配置里最需要关注的是mybatis-spring的版本。它不能随便选，2.x 版本的 mybatis-spring 要求 Spring 5.x 以上，如果你用了 Spring 4.x，就必须退回 mybatis-spring 1.3.x，否则启动时直接报 NoSuchMethodError。mysql-connector-j这个依赖从 MySQL Connector/J 8.0.31 开始改了 artifactId，老写法mysql:mysql-connector-java虽然还能用但已经停止维护了。数据库驱动类名也变了，老项目写com.mysql.jdbc.Driver，8.x 版本要写com.mysql.cj.jdbc.Driver。

2.3 Spring 与 MyBatis 的装配：SqlSessionFactory 的三种配置方式

Spring 整合 MyBatis 的核心是让 Spring 容器来管理 SqlSessionFactory，这样 Mapper 接口的代理对象才能注入到 Service 里。最常见的做法是用SqlSessionFactoryBean来创建工厂，它接收一个DataSource和一组 Mapper XML 的位置。另一个关键点是 Mapper 接口扫描，用MapperScannerConfigurer或<mybatis:scan>标签把指定包下的接口全部注册成 Spring Bean。

<!-- spring-dao.xml --> <context:property-placeholder location="classpath:jdbc.properties"/> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="configLocation" value="classpath:mybatis-config.xml"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="typeAliasesPackage" value="com.supermarket.entity"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.supermarket.dao"/> <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/> </bean>

这段配置里有几个细节值得说清楚。property-placeholder的 location 用了classpath:前缀，这意味着 jdbc.properties 放在 src/main/resources 下，而不是和 web.xml 放一起。mapperLocations配置的是 Mapper XML 的路径，如果这里漏配或写错，启动时不会立刻报错，但要调用 DAO 方法时才抛Invalid bound statement (not found)。typeAliasesPackage的作用是把实体类的完整限定名简化成类名，这样 XML 里可以不写全限定路径。

提示：开发环境建议在 DriverManagerDataSource 与 Druid 连接池之间选择后者。毕设答辩时如果被问"为什么用连接池"，答案是因为 DriverManagerDataSource 每次拿连接都走 TCP 握手，高并发下性能差，而 Druid 复用连接并带监控页面。

3. 超商积分系统的数据库设计与 MyBatis 持久层实现

3.1 三张核心表：会员表、积分流水表、积分规则表

超市会员积分系统的核心不是会员表，而是积分流水表。积分余额只是一个冗余字段，真正的积分变动必须逐条记录，否则无法追溯"这个月为什么少了 200 分"。设计上，会员表member保存静态信息和当前积分余额，积分流水表points_log保存每一笔收入/支出，积分规则表points_rule定义每种业务行为对应的积分值。三张表的关系是：member 1:N points_log，points_rule与业务行为关联，不直接建外键，而是用biz_type字段在代码里做映射。

CREATE TABLE `member` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `card_no` varchar(32) NOT NULL COMMENT '会员卡号', `name` varchar(64) NOT NULL, `phone` varchar(20) DEFAULT NULL, `points_balance` int(11) NOT NULL DEFAULT '0' COMMENT '积分余额', `level` tinyint(4) NOT NULL DEFAULT '1' COMMENT '会员等级 1-普通 2-白银 3-黄金', `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_card_no` (`card_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `points_log` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `member_id` bigint(20) NOT NULL, `change_points` int(11) NOT NULL COMMENT '变动积分，正数增加负数减少', `biz_type` varchar(32) NOT NULL COMMENT '业务类型：CONSUME-消费 BIRTHDAY-生日 RECHARGE-充值 EXCHANGE-兑换', `remark` varchar(255) DEFAULT NULL, `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_member_id` (`member_id`), KEY `idx_created_time` (`created_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

积分流水表的change_points字段设计了正负号规则，这是这个系统的关键约定。消费得积分时写入正数，兑换商品扣积分时写入负数。查询"当前总积分"时执行SUM(change_points)，这样即使用户手动修改了 member 表的points_balance字段，也能通过对账 SQL 发现数据不一致。biz_type用字符串而不用数字枚举，是因为字符串在代码里可读性好，出现未知类型时日志里直接能看到业务含义，不需要再查字典表。

3.2 Mapper XML 里的动态 SQL：积分流水分页查询

MyBatis 的 Mapper XML 是 SQL 的最终归宿。积分流水查询需要支持按会员 ID、业务类型、时间范围三个条件组合过滤，这种场景最适合用 MyBatis 的动态 SQL 来拼查询条件。一个典型的实现如下：

<select id="selectPointsLogPage" resultType="com.supermarket.entity.PointsLog"> SELECT id, member_id, change_points, biz_type, remark, created_time FROM points_log <where> <if test="memberId != null"> AND member_id = #{memberId} </if> <if test="bizType != null and bizType != ''"> AND biz_type = #{bizType} </if> <if test="startTime != null"> AND created_time &gt;= #{startTime} </if> <if test="endTime != null"> AND created_time &lt;= #{endTime} </if> </where> ORDER BY created_time DESC, id DESC LIMIT #{offset}, #{pageSize} </select>

这个<where>标签做的事情值得给面试官讲清楚：如果所有条件都为空，它不会生成 WHERE 关键字，SQL 就是纯SELECT ... FROM points_log ORDER BY created_time DESC；如果第一个条件不为空，它会自动去掉AND member_id = ?前面的 AND。这是 MyBatis 对 JDBC 拼 SQL 最友好的改进之一，但你也要知道它的边界——如果你在<where>外面自己写了 WHERE，再配合<if>就很容易拼出语法错误。

#{}和${}的区别是这个项目里必问的一个点。上面的#{memberId}会被 MyBatis 解析成占位符?，走 PreparedStatement 的参数绑定，天然免疫 SQL 注入。而${}是字符串拼接，只适用于表名、列名这种不能预编译的场景。在这个系统里，ORDER BY后面的排序字段如果要支持前端传入，不能直接拼${}，需要做白名单校验。

3.3 事务边界设计：积分累计与流水写入必须同生共死

积分变动的写入涉及两个操作：更新 member 表的points_balance，插入 points_log 流水。这两个操作必须在一个事务里完成。如果只更新余额而流水插入失败，对账就对不上；如果流水插入成功而余额更新失败，用户看到的积分没变但流水里多了一条记录。Spring 声明式事务解决这个问题的标准做法是在 Service 方法上加@Transactional注解。

@Service public class PointsServiceImpl implements PointsService { @Autowired private MemberDao memberDao; @Autowired private PointsLogDao pointsLogDao; @Transactional(rollbackFor = Exception.class) @Override public void addPoints(Long memberId, int points, String bizType, String remark) { Member member = memberDao.selectById(memberId); if (member == null) { throw new BusinessException("会员不存在，memberId=" + memberId); } int updated = memberDao.increasePoints(memberId, points); if (updated != 1) { throw new BusinessException("会员积分更新失败"); } PointsLog log = new PointsLog(); log.setMemberId(memberId); log.setChangePoints(points); log.setBizType(bizType); log.setRemark(remark); pointsLogDao.insert(log); } }

rollbackFor = Exception.class是必须写的一行。Spring 的默认事务回滚策略是只回滚 RuntimeException 和 Error，如果你在 Service 里抛出自定义的BusinessException且它继承的是 Exception，不加这个属性事务就不会回滚。我见过很多毕设在这上面翻车，结果是一条业务流程执行了一半，数据库里留下脏数据。

increasePoints这条 SQL 建议写成UPDATE member SET points_balance = points_balance + #{points} WHERE id = #{memberId}，而不是先 SELECT 再 UPDATE。前者是数据库原子操作，并发场景下两个请求同时加积分不会丢更新；后者是典型的 read-modify-write，必须加悲观锁或乐观锁才能保证正确性。对于这个系统的并发量来说，原子更新已经足够。

4. Spring MVC 层：积分兑换接口的参数校验与横切逻辑

4.1 Controller 层的"薄"与 Service 层的"厚"

积分系统的 Controller 层不应该写业务逻辑，它的职责只有三件事：接收 HTTP 参数、调用 Service、把结果包装成统一响应结构。很多毕设把积分兑扣除规则直接写在 Controller 里，答辩时被问"如果多个入口都要调用积分扣减，你怎么复用"就答不上来。正确的分层是 Controller 只做参数接收和异常兜底，所有规则判断下沉到 Service，这样需求变更时只会改 Service 的一个方法。

@RestController @RequestMapping("/api/points") public class PointsController { @Autowired private PointsService pointsService; @PostMapping("/exchange") public Result exchange(@RequestBody @Valid ExchangeRequest request) { if (request.getMemberId() == null) { return Result.error("会员ID不能为空"); } try { pointsService.exchange(request.getMemberId(), request.getProductId(), request.getQuantity()); return Result.success("兑换成功"); } catch (BusinessException e) { return Result.error(e.getMessage()); } } }

@Valid注解配合@NotNull、@Min等 JSR-303 校验注解，可以在进入 Controller 方法体之前就完成参数合法性检查。像quantity这种字段必须大于 1，memberId必须不为空，都写在 DTO 里比写在业务代码里更清晰。处理的顺序是：请求进来 → Spring MVC 参数绑定 → 校验框架执行校验 → 校验失败抛出 MethodArgumentNotValidException → 进入 @RestControllerAdvice 异常处理器 → 返回统一错误信息。

4.2 Redis 能不能用在这里：并发扣减的两种方案取舍

积分兑换场景存在一个典型并发问题：用户点击兑换按钮时，前端如果没做防抖，同一请求可能连发两次，导致积分被扣两次。传统 SSM 项目的标准防重方案是给 Service 方法加synchronized关键字，但这样锁粒度太大，所有会员的兑换操作都被串行化。更好的做法是利用 MySQL 的乐观锁机制，在 member 表里加一个version字段。

UPDATE member SET points_balance = points_balance - #{cost}, version = version + 1 WHERE id = #{memberId} AND version = #{oldVersion}

执行这条 UPDATE 时，如果返回值是 0，说明 version 不匹配，意味着这条记录已经被其他事务修改过，此时应该整个事务回滚并提示用户"操作过于频繁"。这个方案不需要引入 Redis，在纯 SSM 项目里最简单可靠。当然，如果系统真到了需要扛高并发的地步，那就是 Redis + Lua 脚本的场景了，这会超出这个毕设的核心范围。

4.3 Jackson 日期序列化：MySQL datetime 与 JSON 字符串的格式战争

后端返回积分流水列表时，created_time字段如果直接序列化成 Java Date 对象，Jackson 默认会输出时间戳数字，前端 JS 还得new Date(timestamp)转换。更统一的做法是在 Spring MVC 配置里全局指定日期格式。但这会引入另一个坑：MySQL 的 datetime 类型没有时区概念，而 Java 的 Date 有，如果双方处理不当，查询出来的时间会偏差 8 小时。

解决方案是在 JDBC 连接串里显式指定时区参数。jdbc.url中 serverTimezone 参数写Asia/Shanghai，同时确保 MySQL 侧使用CURRENT_TIMESTAMP默认值插入记录，这样从数据库到应用程序到浏览器前端的时间认知就完全一致了。

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/supermarket?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true jdbc.username=root jdbc.password=123456

useSSL=false要加上，MySQL 8.x 默认尝试 SSL 连接，本地开发如果没有配置证书会频繁报 SSL 握手告警。allowPublicKeyRetrieval=true是 MySQL 8.0 的另一个坑，使用 caching_sha2_password 认证时，非 SSL 连接下第一次请求会触发公钥检索，没有这个参数可能直接报 Public Key Retrieval is not allowed。这两个参数在部署到云服务器时要格外注意，它们只会出现在开发环境连接串里。

5. 用 MyBatis 实现多表联查与报表统计的实用配置

5.1 会员等级统计：resultType 映射与临时 POJO

积分系统的管理后台经常需要一个统计报表，展示"各等级会员数量及平均积分"。这条查询涉及聚合函数，返回的字段和 member 实体类对不上，一般做法是创建一个临时统计类LevelStatVO，它的字段对应查询结果的列名。

<select id="selectLevelStats" resultType="com.supermarket.vo.LevelStatVO"> SELECT level, COUNT(*) AS member_count, ROUND(AVG(points_balance), 2) AS avg_points, MAX(points_balance) AS max_points FROM member GROUP BY level ORDER BY level </select>

这段 SQL 里 AVG 函数会返回一个 BigDecimal 类型的长小数，ROUND(..., 2)把它限制到两位小数。resultType写的是 VO 类的全限定名，MyBatis 会按列名自动映射到同名字段。如果此时开启了mapUnderscoreToCamelCase配置，数据库列名member_count会被自动转换成memberCount，字段命名风格在 Java 侧保持一致。

这个配置项的位置在mybatis-config.xml里，它是全局性的，开启后对所有 resultType 映射生效。但对resultMap手动映射不生效，因为 resultMap 的 column 和 property 是你显式指定的，MyBatis 不会帮你做蛇形转换。这算是一个容易混淆的细节，如果遇到"字段明明叫 same_name，结果却是 null"的问题，优先检查这里。

5.2 一对多映射：会员与其积分流水的分页查询陷阱

管理后台的会员详情页要展示"会员基本信息 + 最近 10 条积分流水"，用嵌套 Select 可以实现，但真正执行时会产生 N+1 次数据库查询。更好的方案是用一次 JOIN 查询配合 resultMap 的 collection 标签，把一对多关系一次性查出来。

<resultMap id="MemberWithLogsMap" type="com.supermarket.vo.MemberWithLogsVO"> <id property="id" column="m_id"/> <result property="cardNo" column="m_card_no"/> <result property="name" column="m_name"/> <collection property="logs" ofType="com.supermarket.entity.PointsLog"> <id property="id" column="l_id"/> <result property="changePoints" column="l_change_points"/> <result property="bizType" column="l_biz_type"/> </collection> </resultMap>

这个 resultMap 有几个关键点。<id>标签必须配置，MyBatis 用它来判断两行记录是否属于同一个 Member 对象，如果漏配，每一行 SQL 结果都会被认为是一个新的 Member，导致列表里的会员对象重复。column 属性用了m_id、l_id这样的别名，是因为 JOIN 查询里两个表都有 id 字段，别名冲突时需要用前缀区分。ofType必须写成集合元素的完整类名，不能省。

提示：MyBatis 一级缓存默认开启且作用域是 SqlSession，在 Spring 整合环境下，一个线程的 SqlSession 对应一个数据库事务。如果你在循环里执行同一条查询且参数相同，第二次命中缓存不会真正查库。调试时如果发现改了数据库但查询结果没变，先检查当前线程事务是否还没提交，或者直接加flushCache="true"。

5.3 MySQL 存储过程在这个设计里用不用

网上很多毕设模板喜欢把积分清算逻辑写成 MySQL 存储过程，这其实是把业务逻辑塞进数据库的坏味道。存储过程在运维时不可见，不参与 Git 版本管理，迁移数据库时容易漏，调试时也不能像 Java 代码一样打日志。这个系统的积分计算规则——比如"消费满 100 元积 10 分"——放在 Java Service 层里可以用单元测试覆盖，放在存储过程里只能靠手工构造数据来验证。只有一种场景建议考虑存储过程：数据量达到千万级别时，积分月度汇总放在数据库端执行可以避免大量数据传到应用层，但这不是毕设需要考虑的量级。

6. 上线部署时的架构注意点：数据源切换与容器化踩坑

6.1 从开发环境到生产环境的配置切换方案

毕设项目从本地跑到云服务器部署，最常见的错误是直接把 jdbc.properties 里的密码改成服务器数据库密码了事。更稳的做法是给每个环境准备独立的配置文件，例如application-dev.properties、application-prod.properties，用 Maven 的 profile 机制在打包时选择加载哪一份，而不是在代码里硬编码。

<profiles> <profile> <id>dev</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <env>dev</env> </properties> </profile> <profile> <id>prod</id> <properties> <env>prod</env> </properties> </profile> </profiles>

打包命令mvn clean package -Pprod时，Maven 会优先使用 profile 定义的资源目录。这种做法的一个隐藏好处是，打包好的 war 包里只包含你选定的那一份配置文件，不会出现误用测试环境数据库连接的问题。注意activeByDefault只在没有显式指定-P参数时生效，一旦指定了 prod，dev 的默认激活状态就会失效。

6.2 Docker 部署 SSM 应用的三个注意事项

容器化部署这个 SSM 系统时，典型架构是 MySQL 容器 + Tomcat 容器分别运行，用 Docker Compose 编排。这里最常见的坑有三个。第一个是 MySQL 容器首次启动时，MYSQL_ROOT_PASSWORD只对初始化阶段生效，容器把数据库文件持久化到宿主机 volume 之后，修改环境变量不会改变 root 密码。第二个是 Tomcat 容器里的 war 包部署时间，从 COPY 到应用真正可用往往有 30 秒到 1 分钟的延迟，健康检查必须用wget探测应用上下文路径，而不是探测默认的 8080 端口首页。第三个是配置文件里的数据库地址，必须写服务名而不是localhost，因为在 Compose 网络里，localhost指向的只是 Tomcat 容器自己的回环接口。

6.3 答辩演示前的数据样本准备技巧

演示时最怕遇到空数据库带来的白屏和报错。建议在导入系统前先执行一段精心设计的种子数据脚本，构造至少三组典型会员数据：一个新注册的无积分会员、一个黄金等级的消费大户、一个刚兑换完商品积分余额很少的普通会员。这样演示积分累计、升级提醒、兑换扣减时，每一步都有对应的现实数据支撑。更重要的是，种子数据里要刻意保留一笔biz_type='EXCHANGE'的负积分记录，演示流水对账 SQL 时可以直接引用。积分规则表里配置消费 1 元积 1 分、生日双倍积分等规则，让评委感觉这个系统是被真实运营过的，而不是临时填的假数据。

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