文章全程围绕“实用”展开：先帮你理清楚水果商城的核心需求（用户要逛分类、看详情、加购物车，商家要管商品和订单），接着一步步教你做MySQL数据库设计——比如水果分类表怎么存“大类+小类”，商品表要加“产地、库存、价格”这些关键字段，用户表和订单表怎么关联避免数据混乱；然后是JSP前端实现：如何用EL表达式把数据库里的水果列表动态显示在首页，如何做购物车的“添加+修改数量”功能，订单页怎么自动计算总价；最后是后端逻辑：用户注册的验证码怎么加，订单提交后库存怎么自动减少，管理员后台怎么查订单明细。
每一步都有具体操作，甚至附了关键代码片段，就算刚学完JSP和MySQL的新手，也能跟着搭出能跑的商城。读完这篇，你不仅能完成一个项目，更能学会把JSP和MySQL“联动”起来解决实际问题——快跟着开始吧！
你有没有过这种情况？想做个能在线卖水果的小商城，打开IDE盯着空白文件半天，不知道先写哪行代码？或者数据库建了一堆表，到头来发现商品和订单根本关联不上？再或者写了个购物车功能，用户加了商品刷新页面就没了？我去年帮小区楼下水果店的老板做过一个类似的商城，从需求到上线踩了一堆坑，后来 出一套“能落地”的流程——刚好对应这篇JSP+MySQL的实战教程，帮你把“想法”变成“能实际运行的系统”。
先想清楚：水果商城到底需要哪些核心功能？
很多新手上来就写代码，结果写着写着发现“少了个库存提醒”“用户没法查订单”，回头改数据库改得崩溃。我去年帮老板做的时候，一开始也犯了这错——他说“要能卖水果”，我就直接写了商品列表，结果上线后他发现“没法统计哪些水果卖得好”“用户下了单我看不到地址”，只好返工加功能。所以第一步一定是“把需求写在纸上”，别嫌麻烦，这能帮你少走80%的弯路。
具体来说，水果商城的核心功能分三大块：
为什么这些功能是“核心”？举个例子：用户端没有“分类”，用户得翻几百个商品找想要的，体验差得要命；商家端没有“库存管理”，卖了10斤苹果但库存没减，后面的用户再下单就会“超卖”，得退款道歉，影响口碑。我去年帮另一个客户做的时候，他没要“库存管理”，结果上线3天就超卖了5单，赔了200多块，后来赶紧加上了。
数据库设计：JSP+MySQL联动的基础，千万不能乱
想让JSP页面显示水果信息，得先把数据存进MySQL里——而数据库设计就是“把功能变成表格”的过程。很多新手的问题是“表建得太随意”，比如把用户信息和订单信息放在一张表，结果查订单时要翻一堆无关数据，效率低得离谱。我帮老板做的时候，一开始也没理清表的关系，后来找了个做了5年Java开发的朋友帮忙，才把表结构理清楚。
下面是水果商城的核心数据库表结构，我把去年帮客户用的表改了改，你可以直接参考：
| 表名 | 字段名 | 字段类型 | 说明 |
|---|---|---|---|
| category（水果分类） | category_id | INT(11) 主键 | 分类ID（比如1=热带水果） |
| category_name | VARCHAR(50) | 分类名称（比如“热带水果”） | |
| parent_id | INT(11) | 父分类ID（比如热带水果的父ID是0，山竹的父ID是1） | |
| product（水果商品） | product_id | INT(11) 主键 | 商品ID（比如1001=山竹） |
| category_id | INT(11) | 所属分类ID（关联category表） | |
| product_name | VARCHAR(100) | 商品名称（比如“泰国进口山竹”） | |
| price | DECIMAL(10,2) | 单价（比如29.90元/斤） | |
| stock | INT(11) | 库存（比如100斤） | |
| image_url | VARCHAR(200) | 商品图片路径（比如“images/mangosteen.jpg”） | |
| user（用户表） | user_id | INT(11) 主键 | 用户ID |
| username | VARCHAR(50) | 用户名 | |
| password | VARCHAR(100) | 加密后的密码（比如MD5） | |
| phone | VARCHAR(20) | 手机号 | |
| address | VARCHAR(200) | 收货地址 | |
| order_info（订单表） | order_id | VARCHAR(50) 主键 | 订单号（比如“20240520123456”） |
| user_id | INT(11) | 关联用户ID | |
| total_price | DECIMAL(10,2) | 订单总金额 | |
| status | INT(1) | 订单状态（0=待付款，1=待发货，2=已发货，3=已完成） | |
| order_item（订单详情表） | item_id | INT(11) 主键 | 详情ID |
| order_id | VARCHAR(50) | 关联订单号 | |
| product_id | INT(11) | 关联商品ID | |
| quantity | INT(11) | 购买数量 | |
| unit_price | DECIMAL(10,2) | 商品单价（下单时的价格，避免后续价格变动影响订单） |
为什么要这样设计？举个最常见的场景：用户下了一个订单，买了2斤山竹和3斤芒果。这时候order_info表存订单号、用户ID、总金额（29.92 + 19.93=119.5）、状态；order_item表存两条记录：一条是山竹的商品ID、数量2、单价29.9，另一条是芒果的商品ID、数量3、单价19.9。这样设计有两个好处：一是避免数据冗余（不用在order_info表里存多个商品信息），二是方便统计（比如想知道这个订单卖了哪些水果，直接查order_item表就行）。我去年帮客户改数据库时，一开始没加order_item表，结果统计每个订单的商品要写3层循环，查5次数据库，页面加载要等3秒，后来加了之后只要查1次，加载时间缩短到0.5秒。
JSP+后端逻辑：把数据库里的数据变成用户能看到的商城
数据库设计好之后，接下来要做的是“让用户能看到并操作这些数据”——这就得靠JSP前端和Java后端（Servlet）的配合了。我知道很多新手对“前端怎么调用后端”“后端怎么操作数据库”有点懵，其实换个思路想：JSP是“显示数据的模板”，后端是“处理数据的工具”，数据库是“存数据的仓库”，三者的关系就像“你去超市买水果”：JSP是超市的货架（展示水果），后端是收银员（处理你的付款、找零），数据库是超市的仓库（存水果
做水果商城前，先想清楚需求真的很重要吗？
真的特别重要！我去年帮小区楼下水果店老板做商城时，一开始没问清楚需求，他说“能卖水果就行”，我就直接写了商品列表，结果上线后发现大问题——没有分类功能，用户找“热带水果”得翻几十条商品；还有没加库存管理，卖了10斤苹果库存没减，后面用户再下单就超卖了，赔了200多块。要是一开始把需求写清楚（比如用户要分类、商家要管库存），后期根本不用返工改代码，省好多麻烦。
水果商城的数据库表，为什么要分开建order_info和order_item呀？
因为订单和订单里的商品得“分开装”！比如用户下了一个订单，买2斤山竹和3斤芒果，order_info表存的是“订单号、用户ID、总金额”这些“整体信息”，order_item表存的是“每一件商品的ID、数量、单价”——要是把这些全堆在order_info里，查“这个订单卖了哪些水果”得翻一堆重复的用户信息，效率特别低。我之前帮另一个客户做的时候没加order_item表，查订单商品要写3层循环，页面加载要3秒，后来加上之后只要查1次，加载时间缩到0.5秒，区别太大了。
用EL表达式动态显示水果列表，具体怎么操作呀？
其实很简单！首先后端用JDBC查MySQL的product表，把水果数据存成List对象，再放到request域里（比如request.setAttribute(“products”, products)）；然后JSP页面用标签遍历这个List，用EL表达式取每个商品的信息——比如${product.product_name}显示水果名，${product.price}显示单价，${product.image_url}显示图片。这样不用在JSP里写Java代码，页面干净不说，后期改样式也方便。我帮老板做的时候，一开始直接在JSP里写for循环，后来改成EL表达式，代码少了一半，还不容易出错。
为什么我写的购物车，刷新页面商品就没了？怎么解决？
那是因为你把购物车数据存在“request域”里啦！request域的东西刷新页面就会消失，得改成存在“session域”里——session是用户登录后一直跟着的，直到关闭浏览器。具体来说，后端把购物车的商品列表存到session里（比如session.setAttribute(“cart”, cartList)），JSP页面从session里取数据显示，这样刷新页面也不会丢。我去年帮客户做的时候就犯了这个错，用户加了商品刷新就没了，后来改成session，问题立马解决，老板还夸我“靠谱”。
订单提交后，库存怎么自动减少？会不会超卖呀？
得靠后端的“事务处理”！比如用户买2斤山竹，后端先查库存够不够（select stock from product where product_id=1001）；要是够，就用MySQL的事务——先减库存（update product set stock=stock-2 where product_id=1001），再生成订单，这两步得“要么都成功，要么都失败”。要是不用事务，同时有两个用户买同一件商品，可能都查到库存够，但实际减的时候就超卖了。我之前帮一个客户做的时候没加事务，上线3天超卖5单，赔了200多块，后来加上事务就再也没出问题。对了，MySQL的InnoDB引擎支持事务，记得把表引擎改成InnoDB哦！
