企业官网建设流程全解析

1. 项目整体定位与需求拆解

1.1 这套SSM水果蔬菜商城到底在做什么

手头这个"基于SSM的水果蔬菜商城系统"，乍一看就是一个典型的Java Web课程设计，但真正把它从头到尾跑通、部署、交付，你会发现它几乎是SSM技术栈的"全要素演练场"。项目本身并不花哨，核心是围绕生鲜果蔬的线上销售场景，做了一套包含前台购物和后台管理的完整闭环系统。前台面向普通消费者，提供注册登录、商品浏览、分类筛选、购物车、下单结算、订单查询这些基础电商能力；后台面向运营人员，提供商品管理、分类管理、会员管理、订单处理、库存调整等功能模块。

这类项目之所以在各大高校的项目库里长盛不衰，是因为它踩中的技术点非常典型：SSM三大框架的整合、MySQL数据库设计、Maven依赖管理、三层架构分层思想、会话状态管理、事务控制，基本覆盖了Java企业级开发入门阶段的全部核心技能。你把这个项目吃透，往后去看Spring Boot项目，很多东西都能无缝迁移，因为底层思路是一致的。

整套系统适合谁？两类人最值得花时间研究：第一类是正在做课程设计或者毕业设计的学生，需要一个能演示、能答辩、能扩展的完整项目；第二类是自学Java Web开发、想通过一个综合实战把SSM知识点串起来的开发者。我自己带过不少新人走这套流程，说实话，这个项目的难度曲线设计得相当友好——它不是那种"一看就会、一写就废"的玩具，而是有一定业务复杂度、但每一步都有成熟方案可以参考的实战型项目。

1.2 生鲜电商场景的特殊性在哪里

如果只是做一个普通商城，那这个项目也就是平平无奇的CRUD练习。但主题落在"水果蔬菜"上，业务逻辑就开始有意思了。生鲜商品跟数码产品、服装最大的区别在于：库存管理更敏感、商品规格更多样、配送时效要求高、价格波动频繁。你在数据库设计的时候，就不得不考虑这些因素。

比如水果蔬菜的计价单位就很麻烦。苹果可以按斤卖，也可以按箱卖；土豆按斤，但有的精品超市按份卖；还有按"个"卖的脐橙、按"串"卖的香蕉。如果商品表里只放一个简单的price字段和unit字段，后期扩展会很痛苦。我当时做这套系统的时候，在商品表里单独设计了price字段配合unit字段，同时预留了originalPrice用于展示划线价，还加了一个salesCount做销量排序——这些都是从真实生鲜电商平台学来的细节。

另外，生鲜商品的分类层级也值得多琢磨。水果、蔬菜是一级分类，往下还可以分叶菜类、根茎类、瓜果类、热带水果、进口水果等。虽然这个项目用一级分类也能跑通，但如果分类表设计成pid自关联的无限级结构，你会发现前端菜单渲染、后台分类管理都会灵活很多。我建议在动手写代码之前，先把分类表的自关联结构想清楚，后面能省不少返工。

2. 核心技术方案与数据库设计

2.1 SSM整合的底层逻辑：三个框架各管一段

很多人学SSM的时候最大的困惑是：Spring、SpringMVC、MyBatis这三个框架到底是怎么协作的？我用一句话概括：Spring是总调度，SpringMVC管请求分发，MyBatis管数据库读写。打个比方，Spring就像公司总经理，SpringMVC是前台接待，把来访的请求分发给各个部门，MyBatis是档案管理员，专门负责从数据库仓库取数据、存数据。

具体到项目代码里，SpringMVC负责接收浏览器发来的HTTP请求，通过DispatcherServlet把请求路由到对应的Controller方法；Controller调用Service层处理业务逻辑；Service层通过MyBatis的Mapper接口与数据库交互。而Spring在这中间做的事情是"粘合"——它管理Controller、Service、Mapper这些对象的创建和依赖关系，同时负责管理数据库连接池和事务。

这套整合方案里有一个关键概念：容器。Spring容器里注册了Service对象，SpringMVC的容器里注册了Controller对象，MyBatis的Mapper则通过动态代理机制生成实现类注册进Spring容器。初次接触的人容易搞混的地方在于：为什么有的配置放在Spring的applicationContext.xml里，有的放在SpringMVC的spring-mvc.xml里？我当时的理解是：Spring容器管业务层和持久层，SpringMVC容器管控制层和视图层。父子容器的关系搞清楚之后，配置文件的边界自然就清晰了。

2.2 数据库表设计实战：从需求到建表语句

这个项目的核心表有六张左右，我把设计思路逐一拆开讲。

用户表（user）：字段包含user_id（主键）、username、password、phone、email、create_time。密码存储我强烈建议不要用明文，哪怕课程设计也要养成好习惯。可以用MD5加盐的方式，或者用Spring自带的加密工具。我见过很多学生项目把密码明文怼在数据库里，答辩的时候老师一问密码安全问题就卡壳，没必要。

商品表（product）：核心字段包括product_id、category_id（关联分类表）、name、description、price、original_price、stock、unit、image_url、sales_count、status。status字段很关键，用于上下架控制，0表示下架、1表示上架。做后台商品管理的时候，直接update这个字段就能实现上下架，不用物理删除数据。

分类表（category）：我建议做自关联结构，category_id、parent_id、name三个字段就够了。这样以后想扩展多级分类，代码层面几乎不用动。

购物车表（cart）：cart_id、user_id、product_id、quantity、create_time。这里要注意的唯一约束问题：同一个用户加同一个商品，不应该产生两条购物车记录，而是合并数量。可以在代码里先查再插，也可以直接给(user_id, product_id)加联合唯一索引，然后走insert ... on duplicate key update，后者在高并发场景下更可靠。

订单表（order）：order_id（主键）、order_no（订单编号）、user_id、total_price、status、receiver_name、receiver_phone、receiver_address、create_time、pay_time。order_no一定要用时间戳加随机数的组合生成，避免并发下单的时候出现重复编号，我见过用自增id当订单号的项目，被答辩老师追问得下不来台。

订单明细表（order_item）：item_id、order_id、product_id、product_name（冗余字段，防止商品改名或删除后历史订单无法追溯）、price、quantity、subtotal。这里有个设计经验：商品名称一定要冗余到订单明细里，因为商品表的数据会变，而订单是历史事实，不该跟着变。

六张表的关系也不复杂：用户可以下多个订单，一个订单对应多个明细；购物车表和用户、商品都关联。如果时间充裕，还可以加一张轮播图表或者公告表，让首页更丰满，但这六张表已经能支撑整个业务流程跑通了。

2.3 分层架构：为什么Controller不能直接写SQL

做SSM项目最忌讳的是把所有代码堆在Controller里，一个方法写几百行，SQL用字符串拼接，业务逻辑和表现层全搅在一起。这种代码当时跑通没问题，后面一加需求就崩溃。

这个项目我采用的是标准的四层结构：Controller层（表现层）、Service层（业务层）、Mapper层（数据访问层）、domain/entity层（实体层）。Controller只做参数接收和视图转发，不处理业务；Service层写具体业务逻辑，比如下单时检查库存、计算总价、生成订单号、扣减库存要在一个事务里完成；Mapper层只做简单的数据读写。

Service层还有一个关键设计：面向接口编程。先写接口，再写实现类，Controller只管调用接口。这么做的好处是以后想换实现、加缓存、做事务增强都方便。我在项目里对订单模块和购物车模块都做了接口类的设计，代码可读性高很多。

3. 项目工程搭建与SSM整合实操

3.1 Maven依赖管理：从零搭建工程骨架

项目是标准的Maven工程，groupId我用的是个人域名的反写，artifactId是produce，包装成war部署到Tomcat。刚入门的人容易在pom.xml这块卡住，不知道要加哪些依赖。我列一份最小可用集合：spring-core、spring-context、spring-webmvc、spring-jdbc、mybatis、mybatis-spring整合包、mysql-connector-java、druid连接池、junit（测试用）、jackson（做JSON响应用）、jstl和taglibs（JSP页面用）。以上这些都是SSM项目的标配。

有一个容易踩的坑是版本兼容问题。我最初随便找了一个mybatis版本和mybatis-spring版本配在一起，启动的时候一直报错，查了半天发现是mybatis-spring版本和mybatis版本不兼容。后来统一用了一个成熟组合：mybatis 3.5.x配mybatis-spring 1.3.x，或者直接抄某开源项目的版本号组合，就稳了。版本这一块别追求新，稳定最重要。

3.2 配置文件三件套：Spring、SpringMVC、MyBatis各司其职

我建了三个核心配置文件：applicationContext.xml（Spring主配置）、spring-mvc.xml（SpringMVC配置）、mybatis-config.xml（MyBatis配置）。

applicationContext.xml里面主要配置了数据源、SqlSessionFactory、Mapper扫描、Service层扫描、事务管理器。数据源我用的是Druid连接池，配置了初始连接数、最大连接数、连接等待时间这些参数。SqlSessionFactoryBean的configLocation指向mybatis-config.xml，mapperLocations指向classpath:mapper/*.xml，这样MyBatis就知道去哪找SQL映射文件。

spring-mvc.xml里配置了组件扫描只扫Controller包，开启注解驱动（ mvc:annotation-driven/ ），配置视图解析器InternalResourceViewResolver，设了prefix是/WEB-INF/views/，suffix是.jsp，同时配置静态资源映射，把js、css、images这些目录放行。

mybatis-config.xml里主要是开启驼峰命名映射（mapUnderscoreToCamelCase设为true），这样数据库的user_id字段就能自动映射到Java实体的userId属性，省得写一大堆resultMap。还有日志功能，我用的是logback，方便调试SQL。

这三个配置文件的协作关系，我建议新人在理解之后再复制粘贴，不然出错的时候完全没法排查。整合的本质就是：Spring通过配置去创建各个组件的实例，且把它们的依赖关系通过IoC注入串联起来。

3.3 前端页面与静态资源组织

这个项目的前端用的是JSP + JSTL + CSS/JS。页面文件放在WEB-INF/views目录下，按模块分子目录：user、product、cart、order、admin。所有用户可以直接访问的页面通过Controller转发过去，WEB-INF目录下的页面浏览器是直接访问不到的，这种设计本身也是一种安全控制。

静态资源（CSS、JS、图片、富文本编辑器等）放在webapp/static目录下，通过spring-mvc.xml里的<mvc:resources mapping="/static/**" location="/static/"/>放行。前端页面我用了简单的CSS样式，没有引入前端框架。如果你想让界面更好看，可以引入Bootstrap或者Layui，Layui对后端开发者特别友好，表格、分页、弹窗组件直接调用封装好的方法就行，省了很多写JS的时间。

4. 核心功能模块实现详解

4.1 会员注册登录与会话管理

注册登录是所有电商系统的入口，也是答辩时老师必看的功能。注册的逻辑比较简单，表单提交到Controller，Service层先校验用户名是否重复，再用MD5加盐的方式处理密码，最后插入数据库。这里有个细节：JSP表单提交的时候要设置accept-charset="UTF-8"，否则后端接收中文用户名很容易乱码。

登录之后我用Session保存用户信息，key是user，value是User对象。拦截器配置是在spring-mvc.xml里注册一个HandlerInterceptor，配置拦截路径是/order/、/cart/、/user/**这些需要登录才能访问的路径，放行路径是登录、注册、商品列表、商品详情。拦截器里从Session取用户，取不到就重定向到登录页。这么做比在每个Controller里判断用户是否登录要优雅得多。

4.2 商品展示与购物车的存储策略

商品列表页我做了分类导航加列表展示。左侧是分类树，从数据库查出所有分类，在Service层按照父子关系组装成树形结构，然后渲染到页面上。商品列表支持按分类筛选、按销量排序、按价格排序。价格排序我用的是SQL层面order by，销量排序也一样，不用在Java内存里排序，效率高很多。

商品详情页包括商品图片、名称、价格、库存、销量和加入购物车按钮。库存信息要做个判断：如果库存为0，按钮置灰并提示缺货。

购物车这块有个经典的方案选择题：存Session还是存数据库？这个项目两套都做了。未登录状态下把购物车数据存在Session里，登录状态下存数据库。实现逻辑是：用户点击加入购物车时判断登录状态，未登录就存在Session的Map结构里，登录状态就调用CartService写入数据库。结算的时候优先读数据库购物车，Session里的购物车在下单前合并进来。这套混合方案虽然代码量多一点，但用户体验和数据结构都兼顾了，我自己做电商项目也一直沿用这个思路。

4.3 订单生成与事务控制的艺术

下单流程是整套系统技术含量最高的部分，也是面试和答辩的时候最容易被深挖的环节。我简单地描述一下这个流程：用户确认购物车里的商品，填写收货地址、姓名、电话，点击提交订单后，后端做以下几件事：

第一步，从购物车里查出用户勾选的商品明细，校验每个商品的库存是否充足；第二步，计算订单总价；第三步，生成订单号和订单记录，状态设为待付款；第四步，写入订单明细表；第五步，扣减商品库存；第六步，清空购物车记录。这六步操作必须放在同一个事务里，任何一步失败，整个订单流程都回滚，不允许出现"订单生成了但库存没扣"或者"扣了库存但订单没了"的情况。

事务配置在applicationContext.xml里，通过Spring的DataSourceTransactionManager管理，事务管理方式用的是注解@Transactional，在OrderServiceImpl的createOrder方法上标注，配合rollbackFor = Exception.class。这里要注意一个细节：@Transactional只对通过Spring代理调用的方法中抛出的RuntimeException默认回滚，如果方法内部catch住了异常而不抛出，事务是不会回滚的。我第一次写的时候就在Service方法里catch了SQLException，打印了一下日志就算完了，结果数据该回滚的没回滚，排查了好久才发现是这个原因。所以事务方法里要么不写try-catch，要么catch之后手动设置TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。

订单状态流转我也用了状态机的方式管理。定义了订单状态的常量：待付款、待发货、已发货、已完成、已取消。用户取消订单是待付款状态下可以操作，超时订单没有自动取消的逻辑（课程设计不需要定时任务），后台管理员可以修改订单状态。每次状态变更之前先校验当前状态是不是可以流转的状态。这套状态流转逻辑维护起来清晰、不容易出错。

4.4 后台管理：商品与订单的一体化管理

后台功能我放在了/admin路径下，同样通过拦截器做权限控制。管理员登录时校验账号的角色字段，我用的方案是在用户表加了一个role字段，区分ADMIN和USER两种角色。虽然这个项目没有做RBAC权限模型，但对于课程设计来说够用了。

后台的商品管理支持分页查询、添加商品、编辑商品、上下架操作。图片这块，本地存储即可，上传到服务器的某个目录，然后数据库存图片的URL路径。需要注意的一点是：上传图片的时候要限制文件类型和大小。我写了一个简单的FileUploadUtil工具，用Apache Commons FileUpload解析上传请求，限制图片后缀只能是jpg、png、gif，大小不能超过2MB，然后生成UUID作为文件名存入upload目录。

订单管理主要功能是：查询所有订单、按订单号或用户查询、查看订单明细、修改订单状态（发货、完成）。后台首页我还放了一个简单的数据统计看板，查询总用户数、总商品数、今日订单数、累计销售额，这些用简单的聚合SQL就能查出来。做这些统计不是为了炫技，而是让项目在演示的时候有"完整感"，演示的时候老师看到数据面板会比看到纯列表页的印象分高不少。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

我整理了一份这个项目实战中最容易踩的坑，基本覆盖了从搭建到运行的绝大多数问题，直接给结论和解决方案。

5.2 我踩过的几个典型错误复盘

第一个坑是MyBatis的resultType和resultMap混用。一开始写SQL的时候，我图省事把多表查询的结果映射到Map上，发现返回的数据里字段名对不上。后来我给订单明细查询写了一个专门的VO类，OrderItemVO，用resultMap做了映射，代码清晰了很多。我的经验是：单表查询用resultType省事，多表联查或者字段名跟实体不一致的时候，老老实实写resultMap，别偷懒。

第二个坑是Tomcat的部署热更新问题。修改Java代码之后，有时候Tomcat没有自动重新加载，页面还是执行的老代码。排查这个问题的时候我先clean、rebuild项目，不行就重启Tomcat，最后发现是IDEA的Tomcat集成配置里没有勾选"Deploy applications on server startup"相关的自动更新选项。配置好之后开发效率提升不少。

第三个坑是Druid连接池配置了防火墙filter，导致本地连接被拦截。这个问题的现象是开发环境连不上MySQL，检查防火墙规则之后发现是allow的IP配置不对。排查思路：出现数据库连接问题时，先甩开连接池框架，直接用JDBC连接测试，如果JDBC能通，问题大概率出在连接池的配置上。这个排查顺序帮我在后面的项目里省了很多时间。

5.3 项目写完后还能怎么扩展

如果你做完这个基础版之后还有余力，我建议按下面的优先级做一些扩展，能把项目从"课程设计"提升到"接近企业级应用"的水平。

第一优先级：引入Spring Security或者简单的Shiro做登录认证和权限控制，替换掉我用的Session+拦截器方案。这个改动对代码的侵入性不大，但安全性和可扩展性提升很多。

第二优先级：给商品模块加一个搜索功能。最简单的方案是用MySQL的LIKE模糊查询，但如果商品数量多起来，就得引入Elasticsearch或者用MySQL全文索引。哪怕只是做一个简单的搜索框，整个系统的可用性都能上一个台阶。

第三优先级：做一个基于Redis的购物车存储。Redis的hash结构非常适合做购物车，用户id做key，商品id做field，购买数量做value。用Redis的好处是性能好、生命周期可控、天然支持分布式环境。

第四优先级：把支付流程接上支付宝沙箱环境。沙箱支付的接入流程跟真实支付几乎一致，申请一个沙箱账号、配置密钥、回调验签，一套流程走下来，对支付的理解会深很多。而且答辩的时候展示支付宝的支付页面，效果非常加分。

根据我个人的经验，这种SSM商城项目最怕的不是代码难写，而是一个人闷头写、写完了没人看。做项目的过程中，每完成一个模块就自己动手测试一遍业务流程，把异常情况比如库存不足、重复提交订单、并发扣库存这些场景测一测，你会对这个系统的理解深很多。

最后一个建议：无论你把这个项目用在什么场景，记得把数据库设计的文档、关键接口说明、部署步骤整理成一个README或者项目说明文档。答辩的时候老师翻到你的说明文档，印象分会高不少；后面自己回头改代码，也能少花很多时间回忆当初的思路。这套系统的价值不在于它有多先进，而在于它把一个完整业务闭环用最经典的Java技术栈从头到尾实现了一遍——你把这个闭环吃透了，后面学什么框架都不慌。