企业官网建设流程全解析

简介：这份JSP手机销售网设计说明书是一份面向计算机专业学生和JSP初学者的课程设计/毕业设计参考范文，以手机在线销售平台为案例，完整展示基于MVC模式、JSP与MySQL的Web系统设计流程。资源包内共1个docx文档，约789KB，内容按项目背景、需求分析、概要设计、详细设计、实现和总结组织，包含mobileclassify、mobileform、order、cart、user等数据表的字段说明与E-R图，并附有注册登录、商品浏览、购物车、查询、订单处理等模块的设计逻辑和程序截图。通过学习可快速了解设计说明书的标准结构、数据库建模思路和功能模块划分方法，适合用来撰写或完善自己的课程设计报告。截至目前已有466人学习浏览这份资源，对需要规范模板和范文参考的同学具有较高实用价值。

1. JSP手机销售网设计说明书到底在讲什么：先看懂这页纸，再谈怎么写代码

拿到“JSP手机销售网设计说明书”这个标题的读者，多半是计算机专业的课设学生或刚入行的 Java Web 开发。这里有一层容易误解的地方：它名义上是“说明书”，实际上指向一个完整的 JSP + Servlet + JDBC 手机商城项目。你需要交付的不是讲解文档，而是从数据库建表、商品管理、购物车、订单结算到部署运行的全套可运行代码。这个项目麻雀虽小，却把 Java Web 的核心链路全走了一遍：请求怎么在 Servlet 与 JSP 之间流转、登录状态靠什么维持、购物车与订单的事务边界在哪里、分页查询的边界条件怎么处理。适合正在做课设、准备答辩，或想通过一个最小闭环把 JSP 全链路跑通的人。本文按“分层设计 → 建表 → 商品页 → 购物车与订单 → 踩坑 → 进阶优化”的顺序推进，每章都有可直接抄的代码和参数。

2. 从说明书到可运行代码：JSP手机销售网的分层结构与五张核心表

2.1 为什么这个项目用 JSP + Servlet + JDBC 而不是 Spring Boot

“设计说明书”这个命名已经暗示了它的教学属性。用 JSP + Servlet + JDBC 不是因为它适合生产环境，而是因为这套组合能逼着你把 Java Web 的底层机制亲手写一遍：Servlet 接收 HTTP 请求并调用业务逻辑，JSP 把数据渲染成 HTML，JDBC 与 MySQL 通信。没有框架替你封装，于是每一步——从 request 作用域里取值到手动关闭数据库连接——都得自己处理，处理完也就把原理吃透了。

如果你问我实际工作里还会不会用 JSP 做新项目，答案基本是否定的。但这套东西的学习价值在于：理解了 JSP 的 与 ${} 的区别，再去看 Thymeleaf 或 Vue 的模板语法，会发现本质都是“模板里嵌数据”；理解了手动管理 Connection 的痛苦，再去看连接池和 MyBatis，就明白它们解决的是什么问题。所以这个项目的正确打开方式不是对着说明书抄，而是带着“这个步骤交给框架会怎么封装”的问题去写。

2.2 建表 SQL 与字段设计：五张表撑起一个手机商城

手机销售网比普通博客系统多两张关键表：购物车表和订单明细表。最小可运行的表结构如下：

CREATE DATABASE phone_sale DEFAULT CHARSET utf8mb4; CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) UNIQUE NOT NULL, password VARCHAR(50) NOT NULL, phone VARCHAR(20), address VARCHAR(200), reg_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL ); CREATE TABLE product ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT, name VARCHAR(100) NOT NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, pic VARCHAR(200), description TEXT, KEY idx_category (category_id) ); CREATE TABLE cart_item ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, product_id INT NOT NULL, quantity INT NOT NULL DEFAULT 1, KEY idx_user (user_id) ); CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, product_id INT NOT NULL, price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL, KEY idx_order (order_id) );

这里有两个表结构设计的关键点值得展开。第一，order_item 里的 price 字段必须单独保存一份下单时的单价快照，不能通过 JOIN product 表去联查。因为商品调价之后,历史订单金额会跟着变，这在任何电商系统里都是不允许的。第二，cart_item 表建议加上 UNIQUE(user_id, product_id) 联合唯一约束。没有这个约束，同一件商品可能被插入多行，加购逻辑就得分两步：先查询是否已存在，存在则 UPDATE，不存在才 INSERT。加了约束后，可以用一条 INSERT ... ON DUPLICATE KEY UPDATE 搞定，并发下不会产生重复数据。

3. 把商品列表与详情页跑起来：JSP页面与Servlet控制层的分工配合

3.1 商品列表页的 JSP 写法与 request 作用域取值

分层的思想落到代码上，一句话概括就是：JSP 里不写 Java 业务逻辑，只负责从 request 或 session 中取数据并渲染。商品列表页的核心是后端的 ProductListServlet 和前端 JSP 页面。先看 Servlet：

@WebServlet("/product/list") public class ProductListServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setCharacterEncoding("UTF-8"); resp.setContentType("text/html;charset=UTF-8"); int pageNow = 1; String pageStr = req.getParameter("page"); if (pageStr != null && !"".equals(pageStr)) { pageNow = Integer.parseInt(pageStr); } ProductDao dao = new ProductDao(); int totalCount = dao.getCount(); int pageSize = 8; int pageCount = (totalCount + pageSize - 1) / pageSize; List<Product> list = dao.findByPage(pageNow, pageSize); req.setAttribute("list", list); req.setAttribute("pageNow", pageNow); req.setAttribute("pageCount", pageCount); req.getRequestDispatcher("/product_list.jsp").forward(req, resp); } }

这段代码里有几个关键点容易被新手忽略。setAttribute 是把数据放进 request 对象的属性里，属性的生命周期只到本次请求结束。所以这里必须用 forward 而不是 sendRedirect——forward 是服务器内部转发，浏览器地址栏不变，request 里的属性在 JSP 中还能读到；sendRedirect 是让浏览器重新发起一次请求，request 对象已经换了，setAttribute 的数据全部丢失。列表页这类取数渲染的场景必须用 forward。

对应 JSP 页面这样取值：

<c:forEach items="${list}" var="p"> <div class="phone-item"> <a href="${pageContext.request.contextPath}/product/detail?id=${p.id}"> <img src="${pageContext.request.contextPath}/upload/${p.pic}" width="160" /> </a> <p>${p.name}</p> <p class="price">￥${p.price}</p> </div> </c:forEach> <div class="page-bar"> 第 <b>${pageNow}</b> / ${pageCount} 页 <c:if test="${pageNow > 1}"> <a href="${pageContext.request.contextPath}/product/list?page=${pageNow-1}">上一页</a> </c:if> <c:if test="${pageNow < pageCount}"> <a href="${pageContext.request.contextPath}/product/list?page=${pageNow+1}">下一页</a> </c:if> </div>

注意图片路径的写法。${pageContext.request.contextPath} 是 EL 表达式，运行时自动展开为项目部署路径，比如 /phone_sale。这样写的目的是避免相对路径带来的 404——如果页面是通过 forward 转发的，地址栏停在 /product/list，页面里的相对路径基准就变成了 /product/，而图片实际放在上传目录下，于是图片全部无法显示。这是 JSP 项目里最常见的翻车点之一。

3.2 分页查询的三个参数与翻页边界

分页的坑不在 SQL，而在翻页边界的控制。SQL 只需要一句 LIMIT：

// ProductDao 中 public List<Product> findByPage(int pageNow, int pageSize) { String sql = "SELECT * FROM product ORDER BY id LIMIT ?, ?"; // ps.setInt(1, (pageNow - 1) * pageSize); // ps.setInt(2, pageSize); }

pageNow 从 1 开始，偏移量就是 (pageNow - 1) * pageSize。这个公式花不了两分钟就记住，但真正的问题在 JSP 的边界条件上：首页时上一页链接没有意义，末页时下一页链接没有意义。有的写法直接把 pageNow-1 无条件拼进链接，在第一页点了上一页，page 参数变成 0，偏移量变成负数，MySQL 不报错但返回空集合，用户看到空白页。这种 bug 不致命，但答辩时被老师点出来，场面会比较难看。

我建议在 Servlet 里同时对 page 参数做健壮性处理：捕获 NumberFormatException，遇到非法输入直接回退到 1。这个习惯是从生产环境学来的，用户可能会手改 URL 里的参数，你不能假定传进来的都是合法数字。

4. 购物车与订单流程：Session 状态管理和事务边界才是项目的灵魂

4.1 购物车的数据结构选择：Map 还是 List

购物车的存储有两条路子：存在 Session 里，或落到数据库的 cart_item 表。课设阶段通常用 Session 里的 Map，原因是不需要每次加购都访问数据库，响应更快，代码也更直观。但要注意，Session 存在服务器内存里，用户关掉浏览器或 session 超时，购物车就没了。如果说明书要求“购物车持久化”，那就必须落表。有一个折中方案：session 里维护购物车，用户点击“去结算”时一次性把 session 购物车数据写入订单相关表，写入成功后清空 session 购物车。这个方案既简单又满足“订单有据可查”的要求。

Session 版购物车的典型实现，是把商品 ID 与数量的映射放进 session：

// 加入购物车的 Servlet 片段 HttpSession session = req.getSession(); Map<Integer, Integer> cart = (Map<Integer, Integer>) session.getAttribute("cart"); if (cart == null) { cart = new HashMap<Integer, Integer>(); } int productId = Integer.parseInt(req.getParameter("productId")); int quantity = 1; if (cart.containsKey(productId)) { quantity = cart.get(productId) + 1; } cart.put(productId, quantity); session.setAttribute("cart", cart); resp.sendRedirect("cart.jsp");

用 Map 比 List 的明显优势在于：同一种商品加购自动合并数量,不需要遍历 List 去查是否已存在。这个细节在购物车页面的展示中也会省事——直接遍历 Map 的 keySet，逐个查出商品信息即可。另外注意购物车页面用 sendRedirect 跳转，避免用户刷新页面时重复提交加购请求。

4.2 提交订单到扣减库存：事务边界与超卖防护

订单流程是这个项目里唯一真正需要开事务的地方，也是说明书最看重的业务逻辑。一次下单至少完成三件事：插入 orders 主表记录、插入 order_item 明细、扣减 product.stock。这三步必须打包成一个原子操作，否则会出现订单创建成功但库存没扣、或库存扣了但订单失败的中间状态。代码大概长这样：

Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); String sqlOrder = "INSERT INTO orders(user_id, total_amount) VALUES(?, ?)"; PreparedStatement psOrder = conn.prepareStatement(sqlOrder, Statement.RETURN_GENERATED_KEYS); psOrder.setInt(1, userId); psOrder.setBigDecimal(2, totalAmount); psOrder.executeUpdate(); ResultSet keys = psOrder.getGeneratedKeys(); int orderId = 0; if (keys.next()) orderId = keys.getInt(1); for (Product p : cartProducts) { String sqlItem = "INSERT INTO order_item(order_id, product_id, price, quantity) VALUES(?, ?, ?, ?)"; PreparedStatement psItem = conn.prepareStatement(sqlItem); psItem.setInt(1, orderId); psItem.setInt(2, p.getId()); psItem.setBigDecimal(3, p.getPrice()); psItem.setInt(4, p.getQuantity()); psItem.executeUpdate(); String sqlStock = "UPDATE product SET stock = stock - ? WHERE id = ? AND stock >= ?"; PreparedStatement psStock = conn.prepareStatement(sqlStock); psStock.setInt(1, p.getQuantity()); psStock.setInt(2, p.getId()); psStock.setInt(3, p.getQuantity()); int affected = psStock.executeUpdate(); if (affected == 0) { throw new RuntimeException("库存不足: " + p.getName()); } } conn.commit(); session.removeAttribute("cart"); } catch (Exception e) { conn.rollback(); throw e; } finally { DBUtil.close(conn); }

注意扣库存的 SQL 里加了 AND stock >= ? 条件，用受影响行数判断库存是否充足。这是防超卖最简单的做法。如果先 SELECT 查库存再判断再 UPDATE，两个用户同时下单时可能都通过判断，库存被扣成负数。别小看这条 WHERE 条件，它就是行级锁的简化版——数据库在更新时对命中行加锁，stock >= ? 条件不满足时 UPDATE 影响行数为 0，事务回滚。

另一个容易被忽略的细节：session.removeAttribute("cart") 要放在 conn.commit() 之后。如果先清了购物车，然后事务回滚，用户选好的商品就全没了，还得重新挑，体验很糟。事务边界不只是数据库层面的 commit/rollback，还包括清理会话状态的时机。

5. 避坑：JSP手机销售网写得通却跑不顺的五个常见问题

5.1 页面中文全是问号，数据库存储乱码

现象：浏览器页面显示一排问号或方块，数据库里存进去的中文也是乱码，控制台打印出来的日志中文变成 銆 之类。

原因：三个位置必须统一编码。第一，JSP 页面头部要设置 pageEncoding="UTF-8"；第二，接收请求参数之前必须调用 req.setCharacterEncoding("UTF-8")，否则 Tomcat 用默认 ISO-8859-1 解码；第三，JDBC 连接串要带 characterEncoding=utf8。三个设置缺任何一个，都可能出现乱码。

解决：写一个全局过滤器统一处理，而不是在每个 Servlet 里重复设置。每次请求都经过 filter，设置一次就不用再管：

@WebFilter("/*") public class EncodingFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { req.setCharacterEncoding("UTF-8"); resp.setContentType("text/html;charset=UTF-8"); chain.doFilter(req, resp); } }

5.2 图片能直接访问，但列表页图片 404

现象：单独在浏览器输入 image 的完整 URL 能打开，但在商品列表页里图片位置是裂开的。

原因：JSP 页面里用了相对路径写图片地址。如果页面通过 forward 转发，浏览器地址栏保持 /product/list，页面里的相对路径就以 /product/ 为基准，而图片实际放在 /upload/ 目录下，拼接后变成 /product/upload/xxx.jpg，服务器里根本没这个路径。

解决：统一使用绝对路径。每处图片、链接、表单提交地址都加上 ${pageContext.request.contextPath} 前缀，它会在运行时自动展开为项目部署的上下文路径。经验是：JSP 页面里凡是写 src、href 和 form action 的地方，一律不要用相对路径，用 EL 拼绝对路径，这是 JSP 项目最基本的纪律。

5.3 用户连续按 F5，重复下单

现象：订单提交后在成功页按浏览器刷新，系统生成了两条一模一样的订单。

原因：刷新时浏览器重发了上一次的 POST 请求，下单 Servlet 被执行了两次。Post-Redirect-Get 模式可以根治这个问题：下单处理完成后用 sendRedirect 跳转到订单成功页，而不是直接 forward 到结果页。跳转后浏览器地址栏变成 GET 请求，刷新时只触发 GET，不会再次执行下单逻辑。这是防止表单重复提交最经典、也最省事的方案。

5.4 登录后访问页面，session 突然失效

现象：登录成功后页面能正常访问，但过一会或跳转几次后，session 里的用户信息就没了，被要求重新登录。

原因：Tomcat 默认 session 超时是 30 分钟，但更常见的坑是 session 被意外重建。比如某个 Servlet 调用了 req.getSession(true) 又在同一请求里访问 session 属性，在分布式场景下，session 可能被重新创建。排查办法很直接：在登录后的页面上打印 session.getId()，刷新后再对比，如果 ID 变了就是 session 被重建了。

解决：养成一个习惯——登录成功，把用户对象放入 session 后，后续页面直接用 session.getAttribute("user") 取，不要再调用 getSession() 去接收一个不存在的会话并写入。还需要检查 logout 的 Servlet，invalidate 之后不要再试图读取 session 中的用户信息，因为会话已经失效了。

5.5 Tomcat 启动报 ClassNotFoundException，代码却没问题

现象：编译通过，但启动时提示找不到某个 JDBC 或 JSON 相关的类。

原因：在 IDE 的 Build Path 里添加了 jar 包依赖，但没把 jar 物理复制到项目的 WEB-INF/lib 目录。Eclipse 的 Build Path 只是编译期依赖，部署时不会自动带上。Tomcat 运行时不看 Build Path，只看 WEB-INF/lib 和 WEB-INF/classes。

解决：检查 Tomcat 部署目录下的 WEB-INF/lib 文件夹，看缺少的 jar 是否在里面。放到那里再重启就正常了。用 Maven 管理依赖的 pom.xml 可以根治，但课设项目直接拷 lib 更方便，只需要注意依赖完整性和版本一致性。

6. 进阶：给JSP手机销售网补上三处改动，让答辩内容有深度

如果你不满足于“能跑通”，想在答辩时讲出一些超出说明书范围的设计思考，我推荐三处低成本高收益的改造。

第一处，把 JDBC 裸连接换成连接池。课设代码里典型写法是每次请求都 Class.forName 加载驱动、DriverManager.getConnection 创建连接、用完再手动关闭，对数据库的压力不小。换成 HikariCP 之后，DBUtil 里只需要改获取连接的逻辑，DAO 层不用动。核心配置包括 maximumPoolSize 设为 10、minimumIdle 设为 5、connectionTimeout 设为 30000，连接串里保留 characterEncoding=utf8。这一处改动就能引出“数据库连接是稀缺资源，频繁创建销毁开销大，连接池负责维持一批空闲连接复用”这个知识点。

第二处，给商品管理的敏感操作加一个简单的权限校验。很多课设项目的删除商品接口没有任何防护，任何人直接拼个 URL 带个 id 就能删数据库里的商品。在 Servlet 里加一个判断，从 session 取当前登录用户的角色，不是 admin 就返回 403，十几行代码的事。这个防线虽然初级，但至少说明你理解权限控制必须在服务端校验，而不是靠页面隐藏按钮来实现。

第三处，商品图片采用相对路径存储并统一由上传目录暴露，改进大图浏览体验。商品列表页点击图片后做一个简单的轮播或放大预览，实现不复杂，但能让你的项目视觉效果明显比别人好。同时也有实用价值：图片字段存的是文件名而不是二进制数据，页面通过上传目录拼接路径访问，项目迁移时只需打包整个 webapp 目录。

我自己做课设的最后一个习惯，是每改完一个功能就打一个 war 包，放到干净环境的 Tomcat 里跑一遍。因为很多 bug 只在部署环境里才能暴露——依赖缺失、上下文路径写错、数据库用户名密码对不上。这些坑一次就能记住一辈子。把这个项目从头到尾做通了，你收获的不只是完成一份设计说明书的素材，更是一套从建表和页面渲染到事务和部署的完整手感。希望帮到你。

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