当前位置：首页 > news >正文

关于Java的毕业设计：从零实现一个高内聚低耦合的实战项目架构

news 2026/3/26 3:36:18

最近在帮学弟学妹们看毕业设计代码，发现一个挺普遍的现象：项目功能看起来挺全，登录注册、增删改查都有，但代码一打开，Controller里直接调DAO，SQL字符串拼接满天飞，异常全靠e.printStackTrace()，配置文件里都是硬编码的IP和密码。这样的项目，别说通过答辩了，自己后期想加个功能都头疼。

所以，今天想结合一个我做过的小型电商后台项目，聊聊怎么从零搭建一个高内聚、低耦合、能写进简历的Java毕业设计。咱们不搞花架子，就聚焦于如何用一套清晰的结构，把学过的Spring Boot、MyBatis、Redis这些技术真正“工程化”地应用起来。

1. 先聊聊痛点：为什么你的项目看起来“很学生气”？

很多同学的项目跑是能跑，但经不起推敲。我总结了几点最常见的“学生气”问题：

面条式代码：所有逻辑都堆在Servlet或Controller的一个方法里，成百上千行，读起来像看小说，改起来牵一发而动全身。
沉默的异常：到处是try-catch然后只打印日志，或者干脆不处理。前端永远收到500，用户和调试者都一头雾水。
魔法数字与硬编码：数据库连接信息、第三方接口的URL、各种状态码（如1代表成功，0代表失败）直接写在代码里。换个环境部署就得全局搜索替换。
零测试：几乎没有单元测试或集成测试，功能是否正常全靠手动点页面。一旦修改代码，心里完全没底。
脆弱的身份认证：把用户ID直接放在Session或前端，没有Token机制，更别提Refresh Token，安全性堪忧。

2. 技术选型：为什么是Spring Boot + MyBatis + Redis？

面对SSM（Spring+SpringMVC+MyBatis）和Spring Boot，我强烈建议毕业设计选择后者。

Spring Boot：它不是什么新技术，而是Spring系列的“一站式”解决方案。最大好处是简化配置。以前配SSM，光XML文件就好几个，现在几乎“零配置”启动。内嵌Tomcat，打包成Jar直接java -jar就能运行，非常适合演示和部署。它约定大于配置的理念，能让我们更专注于业务逻辑。
MyBatis：相比JPA，MyBatis的SQL更灵活直观，对于复杂查询和性能优化更友好。而且，它和我们熟悉的SQL语句直接对应，学习曲线平缓。配合MyBatis-Plus这类增强工具，单表CRUD几乎不用写SQL，效率极高。
Redis：这是让项目脱颖而出的关键。我们用它主要做两件事：
- 缓存：将热点数据（如商品分类、用户信息）存入Redis，减轻数据库压力，响应速度提升一个数量级。
- 防重提交与幂等性：这是面试常考点。用户快速点击提交订单按钮，如果没有防护，可能创建多个订单。我们可以用Redis的setnx命令或Redisson的分布式锁，为每个请求生成一个唯一键，短时间内重复请求直接拒绝，保证接口的幂等性。

3. 核心实现：搭建一个健壮的骨架

一个好的项目，应该像乐高，模块清晰，拼接容易。我们按分层架构来构建。

3.1 统一响应与全局异常处理

这是给前后端约定好“对话语言”。我们定义一个通用的响应体Result：

@Data @AllArgsConstructor @NoArgsConstructor public class Result<T> { private Integer code; // 状态码，如200成功，500服务器错误 private String msg; // 提示信息 private T data; // 返回的数据 // 快速构建成功响应 public static <T> Result<T> success(T data) { return new Result<>(200, "操作成功", data); } // 快速构建失败响应 public static <T> Result<T> error(String msg) { return new Result<>(500, msg, null); } }

然后，利用Spring的@ControllerAdvice和@ExceptionHandler实现全局异常处理：

@RestControllerAdvice // 增强所有@RestController public class GlobalExceptionHandler { private static final Logger log = LoggerFactory.getLogger(GlobalExceptionHandler.class); // 处理业务异常 @ExceptionHandler(BusinessException.class) public Result<Void> handleBusinessException(BusinessException e) { log.warn("业务异常: {}", e.getMessage()); return Result.error(e.getMessage()); } // 处理系统异常（兜底） @ExceptionHandler(Exception.class) public Result<Void> handleException(Exception e) { log.error("系统异常: ", e); return Result.error("系统繁忙，请稍后再试"); } }

这样，任何地方抛出BusinessException，前端都会收到结构化的错误信息，而不是崩溃的白屏。

3.2 基于Token的用户认证

Session在集群环境下扩展麻烦，我们采用无状态的JWT Token。

登录成功：服务端用JJWT库生成一个Token（包含用户ID、角色等信息），返回给前端。
前端存储：前端将Token存入localStorage或Cookie，并在后续请求的Header（如Authorization: Bearer <token>）中携带。
服务端校验：我们编写一个JwtInterceptor拦截器（或使用Spring Security），在请求到达Controller前，校验Token的有效性和过期时间，并将用户信息存入当前请求上下文（如ThreadLocal）。

关键代码片段（拦截器核心逻辑）：

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); if (StringUtils.isEmpty(token) || !token.startsWith("Bearer ")) { throw new BusinessException("Token无效或已过期"); } token = token.substring(7); // 去掉"Bearer " // 验证并解析Token Claims claims = JwtUtil.parseToken(token); Long userId = Long.valueOf(claims.getSubject()); // 将用户ID存入ThreadLocal，方便后续Service层使用 UserContext.setCurrentUserId(userId); return true; } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { // 请求结束后，清除ThreadLocal数据，防止内存泄漏 UserContext.clear(); } }

3.3 关键业务的幂等性设计

以“提交订单”为例，防止用户重复点击。

思路：前端在点击按钮时，生成一个唯一请求号（如UUID）。提交时，将该请求号一同传到后端。后端在执行业务逻辑前，先查Redis中是否存在这个请求号。

如果不存在，则将请求号存入Redis（设置一个较短的过期时间，如5分钟），然后执行创建订单的逻辑。
如果已存在，则直接返回“请勿重复提交”的提示。

@Service public class OrderServiceImpl implements OrderService { @Autowired private RedisTemplate<String, String> redisTemplate; @Override @Transactional(rollbackFor = Exception.class) // 开启事务 public Result<String> createOrder(OrderDTO orderDTO, String requestId) { // 1. 幂等性校验 String key = "order:req:" + requestId; Boolean isAbsent = redisTemplate.opsForValue().setIfAbsent(key, "1", 5, TimeUnit.MINUTES); if (Boolean.FALSE.equals(isAbsent)) { throw new BusinessException("请勿重复提交订单"); } // 2. 业务逻辑：扣减库存、创建订单等... // ... 这里省略具体的业务代码 // 3. 注意：业务成功后，通常不立即删除Redis键，依靠其自动过期。 // 如果业务失败抛出异常，事务回滚，但Redis键已存在，下次相同requestId的请求依然会被拦截。 return Result.success("订单创建成功"); } }

4. 性能与安全：必须考虑的细节

4.1 安全防护

SQL注入：坚决不用字符串拼接SQL。MyBatis务必使用#{}占位符，它会进行预编译，有效防止注入。
敏感信息脱敏：返回用户信息时，手机号、邮箱等字段应在DTO层进行脱敏处理（如138****1234）。日志中打印用户信息时更要小心，可以使用@JsonIgnore注解或自定义日志脱敏工具。
密码存储：绝对不要明文存密码！使用BCryptPasswordEncoder这类强哈希算法进行加密。

4.2 并发场景模拟：库存超卖

这是一个经典问题。在高并发下，查询库存、判断、扣减这三步不是原子操作，会导致超卖。

解决方案：

悲观锁：在查询库存的SQL后加for update，但性能损耗大。
乐观锁：在商品表加一个version字段。更新时带上版本号条件：update product set stock = stock - 1, version = version + 1 where id = ? and version = ?。如果更新条数为0，说明被别人抢了，需要重试或提示失败。
Redis原子操作：将库存预加载到Redis，利用decr或lua脚本保证原子性扣减，然后再异步同步到数据库。这是高性能场景的常用方案。

我们的毕业设计，用乐观锁实现就足够体面了。

5. 生产环境避坑指南（即使只是演示）

数据库连接池：别用默认的。在application.yml中配置HikariCP（Spring Boot默认，性能好）的参数，如最大连接数、超时时间等，防止连接耗尽。
```
spring: datasource: hikari: maximum-pool-size: 20 connection-timeout: 30000 idle-timeout: 600000
```
日志级别控制：开发环境可以用DEBUG，但生产环境一定要设为INFO或WARN。使用Logback或Log4j2配置文件，将日志按级别、按模块输出到不同文件，方便排查问题。
Swagger文档暴露风险：Swagger在线测试接口很方便，但切记不要在正式部署后还暴露在外网。可以通过配置，只在开发环境（profile=dev）启用Swagger，或者为Swagger页面加上简单的登录认证。