1. 项目整体架构与设计思路1.1 助农网站这个选题到底在解决什么问题先说这个选题的切入点。农产品的销售和信息发布在很多欠发达地区仍然停留在“熟人介绍、线下交易”的阶段信息严重不对称。种出来的东西再好找不到合适的销路价格就被中间商压得很低。毕业生选“助农网站系统”这个方向其实抓住了两个层面的需求一是给农户和农业合作社一个展示农产品、发布种植资讯的窗口二是给采购商和普通消费者提供一个直接对接产地、减少中间环节的渠道。很多同学做毕业设计容易陷入“为了做系统而做系统”的误区功能堆了一大堆但逻辑链条不成立。助农网站和普通商城不一样的地方在于它的核心不是“交易”而是“信息对接”。所以在设计时我并没有一上来就铺开复杂的商城体系而是把重心放在了三个基础能力上商品信息管理、资讯内容发布、用户身份分级。这三点能讲清楚整个系统的骨架就立住了后面无论是功能扩展还是论文写创新点都有话可说。1.2 技术选型为什么是Spring Boot做Java方向的毕设Spring Boot几乎是绕不开的选择。它解决的问题非常明确Spring Framework本身配置繁琐XML、注解、依赖管理一大堆新手光是搭环境就要耗掉两周Spring Boot用自动配置和starter机制把这些东西全部收敛了一个几十行的启动类就能把Web项目跑起来。对毕业设计这种“要快速出成果、还要写出东西”的场景再合适不过。选型时我把常见方案对比了一下方案优势劣势适合场景Spring Boot MyBatis MySQL配置少、上手快、资料多复杂业务需要自己写SQL大多数Java毕设项目Spring Boot JPA/Hibernate实体映射省事复杂查询难调优面试容易被追问细节简单CRUD为主的项目Spring Cloud微服务展现架构能力部署复杂、理论要求高容易玩砸课题本身是分布式方向SSH/SSM传统框架经典配置地狱耗时间长想展示“基本功”的老派做法我最终选的是Spring Boot 2.x MyBatis MySQL这套组合。原因很直接助农网站的业务复杂度控制在中等水平MyBatis手写SQL反而灵活分页、多表联查、条件检索写起来都直观而Spring Boot的门槛低意味着我能把更多精力放在业务逻辑和论文质量上而不是天天和配置较劲。还有一点毕设答辩时老师问“为什么用Spring Boot”你可以理直气壮地说“它简化了Spring的配置复杂度通过自动配置和起步依赖提升了开发效率”这种回答是能加分的。1.3 系统设计原则与整体架构整个系统设计遵循三条原则模块化、统一返回、前后端分离。模块化不用多说按业务边界拆成用户、商品、订单、资讯、轮播图、后台管理几个独立模块谁出了问题改谁互不牵连。统一返回是指所有接口固定返回一个Result对象前端拿到的数据结构永远是code、message、data三件套不会有的接口返回Map、有的返回List把前端的判断逻辑搞得很乱。前后端分离则是把Vue和Spring Boot拆开部署开发时用axios调接口部署时把前端打包成静态资源挂到Nginx下。架构上采用了经典的三层架构加领域划分Controller层负责参数接收和路由转发Service层处理业务逻辑和事务Mapper层负责数据库交互。领域划分横向展开用户、商品、订单、资讯各自成包。处理请求的完整链路是这样的浏览器发起请求到NginxNginx把/api开头的请求反向代理到Spring Boot服务Controller接收到参数后调用ServiceService校验权限和业务规则再通过Mapper操作数据库结果逐层返回到前端渲染。这样做的好处是每层职责清晰出了问题能快速定位是参数问题、逻辑问题还是SQL问题。Controller只做参数接收和结果封装不该出现业务判断Service只做业务逻辑不该出现SQL拼接Mapper只做数据存取不该出现业务判断。这三条边界守住代码审查和论文里的“系统设计”章节都好写得多。2. 功能模块拆分与数据库设计2.1 功能模块到底怎么拆助农网站按照用户角色可以分成两大端前台用户端和后台管理端。前台面向普通用户和农户后台只开放给管理员。前台功能包括用户注册登录、农产品浏览搜索、商品详情查看、加入购物车、提交订单、订单状态查询、资讯文章阅读、轮播图展示。后台功能包括商品管理增删改查、上下架、订单管理发货、状态变更、用户管理禁用、重置密码、资讯发布管理文章增删改查、轮播图管理。模块划分有一个容易被忽视的点不要把“后台”当成一个模块。正确的做法是“商品管理”这个模块同时包含前台的展示逻辑和后台的管理逻辑按业务领域聚合而不是按页面聚合。这样写的好处是Service层的复用性很高比如商品列表接口前台能用、后台也能用只是加不加权限校验的区别。论文里画功能结构图的时候按领域拆分也比按页面拆分显得更有设计感。权限部分我没有引入Spring Security或者Shiro而是用拦截器加Session的方式实现的。理由很简单系统角色只有管理员和普通用户两种权限模型非常扁平用安全框架反而把简单的逻辑搞复杂了而且还要解释一堆过滤器链源码。拦截器通过请求路径判断/admin/**开头的请求检查Session里是否有管理员标记没有就重定向到登录页普通用户接口不做过多拦截只校验登录状态。这套方案虽然简单但能应付毕设场景答辩时把“为什么不用Spring Security”这个问题提前想好回答“系统角色较少安全框架会过度设计基于拦截器的方案能满足需求且易于维护”即可。2.2 数据库表结构设计与关联关系数据库设计是毕设的重头戏。助农网站的表结构我设计了九张核心表用户表、分类表、商品表、购物车表、订单表、订单明细表、资讯表、轮播图表、地址表。表与表之间的关系不算复杂用户对订单是一对多订单对订单明细是一对多订单明细对商品是多对一商品对分类是多对一。购物车和地址都挂在用户下面。用户表是基础表字段包括主键id、用户名、密码MD5加密后存储、昵称、手机号、头像地址、角色标识role0普通用户1管理员、创建时间。密码加密是必须做的即使毕设也不例外明文存储在答辩时是很严重的扣分项。商品表字段包括id、商品名称、分类id、价格、库存、销量、主图地址、轮播图地址组、商品详情富文本、上下架状态、创建时间。价格字段用Decimal类型而不是Float避免精度丢失。订单表和订单明细表的设计要重点提一下。有些同学会把订单和商品直接关联一个订单字段里存一堆商品ID这种做法是反模式的。正确的做法是订单表只记录订单级别的信息订单编号、用户id、订单总金额、收货人信息、订单状态、创建时间订单明细表记录订单id、商品id、商品名称快照、单价、数量、小计金额。商品名称做成快照字段的原因是如果商品被下架或修改名称历史订单仍然能显示当时购买的商品信息这个细节在答辩时讲出来很有说服力。表名核心字段说明userid, username, password, role, phone用户与管理员共用role区分categoryid, name, sort商品分类排序值越小越靠前productid, category_id, name, price, stock, statusstatus控制上下架cartid, user_id, product_id, quantity购物车项ordersid, order_no, user_id, total, status, address订单级信息order_itemid, order_id, product_id, name, price, quantity商品快照明细articleid, title, cover, content, create_time助农资讯文章bannerid, image, url, sort, status首页轮播图addressid, user_id, name, phone, detail收货地址外键我一张表都没加。不是偷懒而是实际开发中外键在数据量上来后会成为写入瓶颈而且辅助删除、更新逻辑反而容易出错。表间的关联关系通过业务代码来维护MyBatis写JOIN查询时指定好关联字段就行。这个做法在互联网公司是常态但在毕设论文里建议不要写“没加外键是因为性能”因为有些保守的老师会认为外键能保证数据一致性你得有心理准备。我在论文里的表述是“通过应用层事务保证数据一致性降低数据库耦合”换个说法就顺了。2.3 接口设计背后的思路接口设计遵循RESTful风格但不是死板地套。比如商品列表用GET /api/product/list带分页和条件参数商品详情用GET /api/product/{id}添加购物车用POST /api/cart提交订单用POST /api/order/create资讯列表用GET /api/article/list。统一返回Result对象前端通过code字段判断业务成功还是失败0表示成功、非0表示业务异常HTTP状态码统一返回200。分页参数我固定接收pageNum和pageSize两个字段用PageHelper插件做物理分页。这里有个细节值得说一下PageHelper是线程局部变量的实现必须在Mapper查询之前调用PageHelper.startPage()如果中间有查询结果被跳过分页就会失效。这个坑我在开发时踩过所以代码里把分页逻辑收口到了Service层Controller层只传页码和大小避免在多处调用startPage导致错乱。接口参数校验放在Controller还是Service这是一个容易被忽略的设计决策。我的做法是语法校验放Controller非空、长度业务校验放Service库存是否足够、状态是否合法。原因是Controller负责把外部请求挡在第一道防线Service则保证核心业务的数据安全。比如下单时检查库存这种判断要是写在Controller里以后如果有内部调用绕过Controller库存判断就形同虚设了。3. 核心功能实现与关键代码解析3.1 用户认证与注册登录模块登录流程走的是Session方案用户提交用户名和密码Controller接收后调用ServiceService从数据库查出用户记录用MD5加盐的方式校验密码校验通过就把用户信息存入Session同时把用户对象返回给前端。整个链路不复杂但有几个细节必须处理到位。第一个细节是密码传输的安全问题。前端传到后端的是明文密码如果直接存数据库一旦数据库泄露所有用户密码就裸奔了。我在后端使用MD5加固定盐的方式加密虽然MD5的安全性放在今天来说不够看但毕设场景下加上盐就能挡住绝大多数问题。答辩时如果老师问“MD5不安全为什么不用BCrypt”答案就说是为了简化依赖生产环境会换成BCryptPasswordEncoder。这个坦诚比硬撑要加分。第二个细节是注册时对用户名的唯一性校验。很多人图省事只在Controller层判断参数非空就插入结果数据库里出现两条相同用户名的记录。我处理的方式是在新增用户前先查一遍用户名是否存在并且把用户名字段加上唯一索引双重保险。加唯一索引的核心意义在于即使业务代码出现并发问题数据库这层兜底也不会让脏数据落库。用户模块的关键代码登录实现如下Override public User login(String username, String password) { User user userMapper.findByUsername(username); if (user null) { throw new BusinessException(用户名不存在); } String md5Pwd Md5Util.encrypt(password, user.getSalt()); if (!md5Pwd.equals(user.getPassword())) { throw new BusinessException(密码错误); } return user; }这段代码的思路是“先查后比”先根据用户名查出用户再比对加密后的密码。注意我没有把“密码错误”和“用户名不存在”分成两个错误提示统一返回“用户名或密码错误”更安全避免恶意用户通过错误提示推断出系统中存在的用户名。这个细节虽然小但能体现安全意识。3.2 农产品展示、搜索与分类筛选商品列表是前台最核心的接口它要同时支持分页、按分类筛选、按关键词搜索、按价格或销量排序。我把这些条件封装成一个查询对象ProductQuery包含pageNum、pageSize、categoryId、keyword、sortType几个字段Mapper层通过动态SQL拼条件。这样设计的优势是接口参数可以随意组合不用为每个组合单独写一个方法。MyBatis的动态SQL是这里的关键select idfindByCondition resultTypecom.example.pojo.Product SELECT * FROM product where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if AND status 1 /where choose when testsortType priceAsc ORDER BY price ASC/when when testsortType priceDesc ORDER BY price DESC/when when testsortType salesDesc ORDER BY sales DESC/when otherwise ORDER BY create_time DESC/otherwise /choose /select使用 标签的好处是当前面没有条件成立时where关键字不会出现当前面有条件时它自动去掉多余的AND避免SQL拼接出错。关键字搜索用LIKE做模糊匹配就可以满足题目这个级别的需求如果数据量大到要上Elasticsearch那就是另一个系统了。商品排序用 做分支每个分支对应一种排序策略代码可读性比Java代码里判断后拼SQL更高。商品上下架状态这里有个容易被忽略的点商家把商品下架不代表历史订单里的商品要删掉更不能影响订单的展示。所以订单明细里保存的商品快照就有用了。但前台接口查询商品列表时一定要过滤status 1不然下架商品还在首页暴露就被用户钻了空子。商品详情的实现相对简单根据id查商品表即可。但需要注意商品点击量统计的时机我是把浏览量累加逻辑放在了Service方法里每次调用详情接口自增一次。有人说应该用异步处理但毕设项目量级不需要那么做直接用UPDATE语句就行不用搞复杂方案。3.3 购物车与订单提交的事务处理购物车设计是“一件商品一行记录”的方式用户把商品加进购物车时如果该商品已经在购物车里就更新数量如果不在就插入新记录。这个逻辑用一句话概括先查询购物车里有没有同user_id和product_id的记录有就update没有就insert。这种“有则改、无则增”的写法很常见在代码里要多加一步检查。订单提交是全局最核心的接口它涉及多张表的数据变更必须放在同一个事务里生成订单主表记录、生成订单明细记录、扣减商品库存、清空购物车中对应商品。任何一个环节失败整个订单都不能成立否则就会出现“订单生成了但库存没扣”或“库存扣了但订单没生成”的数据不一致问题。Spring Boot的Transactional注解在这里就是保命的。订单提交的核心流程如下Transactional(rollbackFor Exception.class) public Order submitOrder(Integer userId, ListCartItemVO items, Address address) { BigDecimal total BigDecimal.ZERO; Order order new Order(); order.setOrderNo(OrderNoGenerator.generate()); order.setUserId(userId); order.setStatus(0); // 计算总金额并校验库存 for (CartItemVO item : items) { Product product productMapper.findById(item.getProductId()); if (product null || product.getStatus() ! 1) { throw new BusinessException(商品不存在或已下架); } if (product.getStock() item.getQuantity()) { throw new BusinessException(商品库存不足); } orderItemMapper.insert(OrderItem.builder() .orderId(order.getId()) .productId(product.getId()) .name(product.getName()) .quantity(item.getQuantity()) .price(product.getPrice()) .build()); total total.add(product.getPrice().multiply(new BigDecimal(item.getQuantity()))); productMapper.deductStock(product.getId(), item.getQuantity()); } order.setTotal(total); orderMapper.insert(order); cartMapper.deleteByUserIdAndProductIds(userId, items.stream().map(CartItemVO::getProductId).collect(Collectors.toList())); return order; }注意这里的事务回滚条件是rollbackFor Exception.class而不是默认的RuntimeException。Spring的Transactional默认只在运行时异常时回滚如果你在代码里抛的是Exception子类比如检查异常它不会自动回滚。我把BusinessException设计成运行时异常加上显式的rollbackFor声明双保险。另外事务方法内部不能自己调自己同类内部调用否则事务注解失效因为Spring的事务是基于动态代理的内部调用不经过代理对象。订单状态流转我用的是整数状态位0待付款、1待发货、2待收货、3已完成、4已取消。状态迁移的校验要做到“只能从当前状态到下一个合理的状态”比如一个待发货订单不能被用户直接改成已完成必须经过发货这个动作。这个校验逻辑放在Service层可以避免前端伪造请求。3.4 后台管理模块的实现要点后台管理模块的本质就是一组受限访问的CRUD接口外加数据统计。说它简单是因为逻辑本身就那么多说它难是难在要保证“只有管理员能操作”这条安全线。后台商品管理的接口包括商品列表后台版要显示全部状态包括下架商品、新增商品、编辑商品、上下架切换、删除商品。删除商品我做的不是物理删除而是逻辑删除给product表加一个deleted字段查询时统一过滤。物理删除会把数据库里所有关联数据弄丢订单明细里的商品快照一旦找不到来源历史订单就查不到了。这个细节虽然不是系统功能的重要组成部分但做出来以后运维层面的处理会顺手不少。后台资讯发布模块相对简单就是文章的增删改查。文章表包含标题、封面图、内容、发布时间。内容我存的是富文本HTML前台直接通过v-html渲染。这里有个安全提醒直接渲染HTML存在XSS风险后台必须有过滤机制至少要对script标签做转义处理。我的做法是在后端增加一个简单的HTML过滤工具把