企业官网建设流程全解析

做这类“jsp网上公路车销售系统”，十个人里有八个是课程设计或者毕业设计，剩下两个是想给车店做个内部展示下单的小工具。这个项目标题听起来不复杂，但它真正有意思的地方在于公路车这个品类和普通数码商品完全不同，车架尺码、套件等级、刹车形式、轮组规格这些维度一多，数据库和筛选逻辑就比一般电商系统麻烦不少。这篇我按自己实际整理过的思路，完整拆一遍这套系统的需求、表结构、核心模块和容易踩的坑，从零到能跑通整个流程，应该能帮你省很多试错时间。

1. 项目概述与需求拆解

1.1 这个系统到底要解决什么问题

先想清楚，公路车线上销售系统不是简单的“商品列表+购物车+下单”。公路自行车属于高客单价、参数密集型商品，用户买车前要反复比较车架材质、尺码兼容性、套件等级和预算区间。一辆整车往往有四五种尺码，每种尺码的库存还不一样，颜色版本也可能不同。如果系统只做一张普通商品表，后续在筛选、库存和订单环节都会很痛苦。

所以我在整理需求时，会把核心问题拆成四个：商品信息结构化展示、按公路车特有参数筛选、用户购物车与订单流转、后台商品与订单维护。这四件事对应前台和后台两套界面，前台给普通用户看，后台给运营人员用。用户角色我直接做成两种，未登录游客可以浏览、加入购物车，但下单前必须登录，管理员单独走后台入口。

还有一个容易被忽略的点：这种系统大多数场景是教学项目，但也有人拿去给线下车店做展示工具。两种场景需求不同，课程设计重点看功能完整度和代码结构，车店场景还要考虑图片能不能传、库存会不会对不上、订单状态能不能改。我后文给出的方案尽量兼顾两边，核心功能都齐全但不堆砌。

1.2 为什么选JSP而不是前后端分离

很多人纠结要不要用Vue加Spring Boot做前后端分离，我的观点很直接：如果项目标的是“jsp网上公路车销售系统”，那就老老实实按JSP的路线做。原因不是JSP先进，而是它和这个场景的匹配度最高。JSP服务端渲染对小型系统来说非常自然，页面跳转、Session状态、表单提交都不需要额外写接口文档，调试的时候直接看页面报错也方便。

JSP适合这个场景还有一个现实理由：部署简单。打一个war包扔进Tomcat就能跑，不像前后端分离还要配Nginx、处理跨域、管理Node构建流程。对课程设计和新手练手来说，技术栈每多一层，出问题的概率就翻一倍。

当然JSP的缺点也明显，页面和后端逻辑耦合重，前端改动容易碰到Java代码，代码一多JSP文件会变得很乱。所以我后文强调分层和JSTL/EL表达式，尽量把Java逻辑从页面里挪走。

1.3 适合谁来参考这套方案

如果你正在写“jsp网上公路车销售系统”这个题目，这篇的参考价值最大。除此之外，做一般的小型电商系统、二手交易平台、配件销售系统的人也能借鉴大部分设计。因为公路车特有的SKU拆解思路本身就是很好的学习案例，理解了它，再做服饰鞋帽类的多规格商品也就顺了。

如果你的基础是刚学完JavaWeb基础知识，Servlet和JSP勉强能写，但没完整做过一个系统，那这篇尤其适合。我讲解的顺序基本就是一个可落地的开发顺序：先分析需求，再设计表，再写核心流程，再补细节，最后考虑部署和扩展。你不需要一次看完，按章节推进就行。

如果你已经会了JSP还想知道这套系统怎么升级成商用方案，我最后有一节专门讲扩展方向，你会看到从课程项目到真实运营之间的差距到底在哪里。

2. 技术选型与架构设计

2.1 技术栈组合怎么定

我推荐的组合是一套非常经典、文档多、报错好查的阵容：

这里要特别说一句为什么不直接用MyBatis或者Hibernate。如果你已经会那些框架，当然可以用，但很多课程设计明确要求JSP和JDBC原生操作，用框架反而容易被质疑核心代码不是自己写的。退一步讲，JDBC写清楚之后，再去看MyBatis的Mapper，其实就是把重复代码模板化了，底子不会白打。

数据库连接池我建议必须用，不然每次操作数据库都手动Connection、PreparedStatement、close三件套，代码里全是样板代码，而且并发稍微高一点连接就报错。Druid配置起来不算复杂，后面章节会给实际配置思路。

2.2 三层架构如何落地

这套系统我把包结构分成entity、dao、service、servlet、filter、util六块。entity放实体类，和表字段一一对应；dao只做增删改查，不写业务判断；service处理具体业务，比如下单时要同时扣库存、生成订单、清购物车；servlet负责接收请求、调用service、跳转页面；filter处理编码和登录拦截；util放分页工具、文件上传工具、字符串处理工具。

请求流程基本是：浏览器提交请求，Servlet接收参数，调用Service，Service内部调多个DAO方法，DAO操作数据库，结果一层层返回，Servlet把数据放进request或session，最后转发到JSP渲染页面。只要严格按这个方向依赖，出现问题时很好定位是SQL问题还是业务逻辑问题，不会在JSP页面里翻半天Java片段。

这里有一个我特别喜欢强调的细节：JSP页面里尽量不要出现<% ... %>脚本片段。很多同学图省事直接在页面里写while(rs.next())，短时间确实快，但后面改需求时页面和逻辑搅在一起，尤其是商品筛选条件一变，JSP里改SQL，想想都头大。规范做法是通过EL表达式和JSTL的<c:forEach>循环输出数据，页面上只保留展示逻辑。

2.3 项目目录与模块划分

我习惯在Eclipse或IDEA里按下面这种结构组织：

src/main/java ├── com.shop.entity │ ├── User.java │ ├── Product.java │ ├── CartItem.java │ └── Order.java ├── com.shop.dao │ ├── UserDao.java │ ├── ProductDao.java │ └── OrderDao.java ├── com.shop.service │ ├── ProductService.java │ ├── CartService.java │ └── OrderService.java ├── com.shop.servlet │ ├── ProductServlet.java │ ├── CartServlet.java │ └── OrderServlet.java ├── com.shop.filter │ ├── EncodingFilter.java │ └── LoginFilter.java └── com.shop.util ├── DBUtil.java ├── PageBean.java └── UploadUtil.java src/main/webapp ├── index.jsp ├── productList.jsp ├── productDetail.jsp ├── cart.jsp ├── order.jsp └── admin ├── adminLogin.jsp ├── productManage.jsp └── orderManage.jsp

这种结构的好处是，前台页面和后台管理页面物理隔离，admin目录下的页面专门给管理员用，配合Filter做目录级拦截。实体类命名和表名保持一致，DAO方法名尽量统一成findById、findList、add、update、delete，看代码的人不需要费劲猜。

3. 数据库设计：公路车SKU的特殊性

3.1 公路车商品表应该怎么建

公路车不是一双鞋，一双鞋可能只有颜色和尺码两个维度，公路车整车至少要区分品牌、系列、年份、车架材质、尺码、套件等级、刹车形式、轮组规格和重量。如果按标准电商玩法拆SPU和SKU，对JSP小项目来说过于复杂。实用的折中方案是：整车用单表存公共属性，具体可售版本通过尺码、颜色和库存组合来体现。

下面这个商品表结构是我在实际整理中觉得性价比很高的方案：

CREATE TABLE product ( id INT PRIMARY KEY AUTO_INCREMENT, brand VARCHAR(50) NOT NULL COMMENT '品牌', series VARCHAR(100) NOT NULL COMMENT '系列名称', model_year YEAR DEFAULT NULL COMMENT '年份款', frame_material VARCHAR(30) COMMENT '车架材质：碳纤维/铝合金', groupset VARCHAR(50) COMMENT '套件等级，如Shimano 105', brake_type VARCHAR(20) COMMENT '刹车类型：碟刹/圈刹', wheelset VARCHAR(50) COMMENT '轮组规格', weight DECIMAL(6,2) COMMENT '整备质量，单位kg', price DECIMAL(10,2) NOT NULL COMMENT '到手价', sizes VARCHAR(100) COMMENT '可选尺码，如XS,S,M,L,XL', stock INT NOT NULL DEFAULT 0 COMMENT '总库存', status TINYINT DEFAULT 1 COMMENT '1上架 0下架', main_image VARCHAR(255) COMMENT '主图路径', detail_images TEXT COMMENT '详情图路径，JSON数组或逗号分隔', description TEXT COMMENT '图文描述', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

把sizes做成字符串，比如“XS,S,M,L,XL”，在商品详情页展示时直接拆分渲染成尺码按钮。这样做牺牲了精确到每个尺码的库存管理，但换来了极大的开发简便。如果你做的题目明确要求每个尺码单独库存，那就需要加一个子表product_sku存尺码、颜色、价格、库存，订单项再关联sku_id。这个我在下面会说怎么扩展。

3.2 用户、购物车、订单表如何关联

用户表没什么特殊，核心字段是用户名、密码、手机号、邮箱、收货地址、创建时间。要注意密码一定不能明文存，用MD5加盐或者SHA-256做摘要，登录时把用户输入加盐后再比对。

购物车表我建议只存关键关联信息：

CREATE TABLE cart_item ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, product_id INT NOT NULL, size VARCHAR(10) COMMENT '选择的尺码', quantity INT NOT NULL DEFAULT 1, add_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_product_size (user_id, product_id, size) );

这里加唯一键非常关键，否则用户重复点击加入购物车会生成多条相同记录，合并逻辑很难写。加了这个唯一键后，插入时用ON DUPLICATE KEY UPDATE quantity = quantity + 1，一行SQL就完成“存在则累加，不存在则新增”的效果。

订单表结构上要有订单主表和订单项表。主表记录订单编号、用户ID、总金额、收货人、电话、地址、状态、下单时间。订单项表记录每一个商品的ID、名称、快照价格、数量、尺码。快照价格这件事很多人忽略，真实运营中商品会改价，订单一旦生成就不能随着商品价格变动，所以订单项里必须冗余一份下单时的商品名和价格。

订单状态字段我用TINYINT表示，0待支付、1已支付待发货、2已发货、3已完成、4已取消。这个状态流转在后端管理模块里用下拉框修改，每次修改最好记录操作日志，不然用户说“我订单怎么状态不对”时你完全无据可查。

3.3 库存扣减和防超卖怎么处理

这个规模的项目用不着Redis分布式锁，但基本的数据库事务和行锁还是要有的。下单时先执行UPDATE product SET stock = stock - ? WHERE id = ? AND stock >= ?，如果受影响行数为0，说明库存不够，直接提示用户。这条SQL是原子操作，天然避免两个用户同时下单时库存变成负数的问题。

然后订单主表和订单项表在同一个事务里写入，Service层方法上开启事务，DAO层不要每个方法独立提交。我见过不少项目DAO里写conn.commit()，业务层根本控制不了事务边界，下单时扣库存成功了、订单生成失败，库存就莫名其妙少了。正确做法是Service层从连接池拿一个连接，设置autoCommit=false，把所有操作执行完统一commit，任何一步抛异常就rollback。

商品列表页显示的总库存和每个尺码可用数量，如果想做得细致，可以在SKU子表维护。课程设计通常不用做到这个粒度，但面试时能说出来你的库存扣减为什么要用条件更新，会比背概念强很多。

4. 核心功能模块与关键逻辑

4.1 商品展示和筛选检索怎么做

前台首页推荐位放热门整车，列表页是全站商品核心入口。公路车用户最关心的筛选条件是预算区间、变速套件等级、车架材质、刹车类型、尺码。所以列表页左侧筛选项就按这五类给，每个条件对应URL参数，比如priceRange=10000-20000&groupset=105&frame=carbon。

Service层接收这些参数后动态拼SQL，注意参数校验，不能直接把用户输入的字符串拼进SQL。我推荐用StringBuilder拼接WHERE 1=1，每有一个条件就AND一段，参数值全部用PreparedStatement占位符设置。分页我封装了一个PageBean，记录当前页码、每页条数、总记录数、总页数、数据列表，列表页底部渲染上一页下一页和页码数字。

商品详情页要展示主图、价格、可选尺码、套件和车架信息。尺码选择这里有个交互细节：用户选尺码时，如果这个尺码库存为0，前端按钮置灰，不能点击。这个判断通过页面渲染时查询SKU或解析sizes字符串来完成，虽然不复杂，但很影响使用体验。

4.2 用户登录和购物车会话处理

登录模块我采用Session保存登录用户，登录成功把User对象放进Session，Filter拦截需要登录的URL。注册时的用户名唯一性检查在DAO层先查一次，再插入，同时捕获数据库唯一索引异常兜底，防止并发注册导致重复数据。

购物车这里有个老生常谈的问题：游客能不能加购物车？我的方案是游客也可以加，但数据存Session，登录后把Session里的临时条目合并到数据库购物车。合并逻辑不复杂，遍历临时条目，尝试插入数据库购物车表，唯一键冲突就把数量累加。这个合并动作放在登录成功后的Service里统一处理。

真正写代码时容易出错的地方是Session作用域里的Cart对象被直接当作数据库表结构用。我的建议是：游客购物车也使用和cart_item几乎一致的结构，只是保存在Session的List里，登录后转成实体对象逐条入库，这样就不需要维护两套字段逻辑。

4.3 订单结算流程和刷新防重

下单流程我拆成五步：用户从购物车选中商品点击结算，进入确认订单页填写收货人和地址，提交订单后后端校验库存和金额，生成订单号和订单项，最后清空购物车跳转到支付页面。因为是教学系统，支付环节一般用模拟支付按钮，点击后把订单状态改成待发货。

订单编号我推荐用时间戳加用户ID加随机数，格式类似202506071530120001，长度足够且不容易猜测。不要用数据库自增ID直接当订单号，既不好看也容易被人遍历。

这里有一个极容易踩的坑：订单提交页直接POST到Servlet，Servlet处理成功后如果转向是forward，用户刷新页面会再次提交。解决办法是redirect到订单详情页，也就是Post/Redirect/Get模式。再进一步，为了防止双击按钮产生两条订单，前端提交时把按钮置为禁用，后端也可以用一个临时token做幂等控制，第一次提交后token失效。

4.4 后台管理模块怎么设计

后台我做了五个子功能：管理员登录、商品管理、订单管理、用户管理、基础数据统计。商品管理包含新增、编辑、上架下架、修改库存、上传图片。新增商品页面字段较多，前端用Bootstrap的表格布局分组展示“车架”“套件”“轮组”“价格库存”，保存时一次表单提交到后台，后端逐字段校验。

订单管理对所有订单分页展示，管理员可以按状态筛选，点击详情能看到收货信息和订单项明细，发货操作要填写物流单号并更新状态。用户管理不需要太复杂，能查看用户列表、禁用异常账号即可。

基础统计我建议做一个最简单的销售额统计页面，按天分组查询已支付订单的总金额：

SELECT DATE(create_time) AS day, SUM(total_amount) FROM orders WHERE status IN (1, 2, 3) GROUP BY DATE(create_time) ORDER BY day DESC LIMIT 30;

这个统计虽然简陋，但作为课程设计亮点完全够用，而且能让后台首页不空荡荡，演示效果也好。

5. 实操要点与踩坑记录

5.1 JSP页面复用和EL表达式怎么配合

做后台管理页面你会发现，左侧菜单、顶部导航在每个页面都要重复，如果复制粘贴，改一个菜单名称就要改十几个文件。正确做法是用<%@ include file="common/header.jsp" %>静态包含或者JSTL的<c:import>。静态包含在编译时展开，性能和调试都更直接，我建议用静态包含。

列表页输出数据用JSTL：

<c:forEach items="${productList}" var="p"> <div class="product-card"> <img src="${p.mainImage}" alt="${p.series}" /> <h3>${p.brand} ${p.series}</h3> <p>${p.groupset} / ${p.frameMaterial}</p> <p class="price">￥${p.price}</p> <a href="productDetail?id=${p.id}">查看详情</a> </div> </c:forEach>

EL表达式取值靠实体类的getter方法，所以实体类属性名和表字段映射一定要规范。这里常见的坑是数据库字段用下划线命名frame_material，实体类属性用驼峰frameMaterial，JDBC的ResultSet取数时要注意rs.getString("frame_material")，不能直接用属性名取。

5.2 图片上传和访问路径处理

公路车销售系统图片肯定少不了一堆整车图和细节图。图片上传如果用Servlet 3.0的Part接口，代码相对简单，配置一个@MultipartConfig注解就能接收multipart/form-data请求。但要注意上传文件的保存位置，不能直接保存到项目部署目录下，因为Tomcat重启或重新部署war时会清空原来的上传文件。

稳妥做法是把图片保存到服务器上一个固定目录，比如/data/shop-upload，然后在Tomcat配置虚拟目录映射，让/upload/**访问到那个磁盘目录。如果你不需要改Tomcat配置，也可以用项目外目录加读取流的方式，但页面显示<img>标签需要额外Servlet转发文件流，比较麻烦。最省事的还是配置server.xml的Context：

<Context docBase="/data/shop-upload" path="/upload" />

配置好后，数据库里只存相对路径/upload/products/20250601_xxx.jpg，页面直接用相对路径就能访问，部署迁移时也只要把上传目录整个拷走。

5.3 登录拦截和未登录请求怎么处理

登录拦截我用一个Filter统一处理，拦截路径是/user/*、/order/*、/admin/*。Filter里判断Session有没有登录用户，没有就sendRedirect到登录页。这里有一个细节：重定向要携带returnUrl参数，用户登录成功后跳回原页面，否则用户每次都要重新找刚才的商品。

Ajax请求的登录失效处理和普通页面跳转不一样。如果前端用jQuery的$.post提交加购操作，后端直接重定向到登录页，前端收到的会是302后的登录页HTML，解析JSON就报错。所以我让后端检查请求头里有没有X-Requested-With: XMLHttpRequest，如果是Ajax就返回一个JSON对象{code: 401, msg: "请先登录"}，前端根据code跳转登录页，体验会好很多。

5.4 中文乱码和日期金额格式

中文乱码是新手的重灾区。我习惯在第一个Filter里统一设置：

request.setCharacterEncoding("UTF-8"); response.setCharacterEncoding("UTF-8"); response.setContentType("text/html; charset=UTF-8");

并且数据库连接URL一定带characterEncoding=utf8，Tomcat的Connector如果发现GET请求参数中文乱码，检查是否设置了URIEncoding="UTF-8"。

日期显示方面，DATETIME从数据库取出来是Timestamp对象，JSP页面直接输出会是一长串带小数秒的格式。处理办法是在实体类里用SimpleDateFormat转成字符串，或者在SQL里用DATE_FORMAT格式化。金额展示也建议先在Service层用BigDecimal计算，转成两位小数的字符串后再放进页面，避免浮点运算误差和多余小数位。

5.5 常见异常速查表

6. 测试、部署与运营细节

6.1 本地联调的正确顺序

开发完不要急着一口气测试全部功能，我建议按照“基础环境-主流程-异常流程”的顺序来。先确认Tomcat能启动、数据库脚本能跑通、首页能打开；再走用户注册登录、浏览商品、搜索筛选、加入购物车的常规路径；最后测试边界场景，比如库存为0的商品能否下单、未登录直接访问订单页是否会被拦截、重复提交订单会不会产生两条记录。

测试数据不能太假。我会往商品表里插五六条不同价位的公路车数据，价格覆盖5000到50000区间，套件等级覆盖入门到顶级，尺码覆盖XS到XL。这样演示筛选功能时才有效果，空表跑筛选查不出任何差异。

我在本地联调时还会刻意测试一下Tomcat重启后Session里的登录态丢没丢、上传的图片还在不在。Session丢失是正常的，重启后重新登录即可，但上传图片如果因为部署目录重建而丢失，那就要检查图片路径是否真的存在磁盘目录了。

6.2 war包部署和基础安全配置

项目在IDEA里用Maven执行clean package，生成war包后放到Tomcat的webapps目录，启动后自动解压部署。如果数据库从MySQL Workbench迁移到服务器，注意版本差异，新版MySQL的驱动类和连接URL可能略有区别，驱动版本和MySQL版本要匹配。

部署到公网前，至少要做三件安全基础工作：改掉MySQL和Tomcat管理后台的默认密码、数据库连接用低权限账号而非root、关闭Tomcat默认的manager页面外部访问。如果条件允许，前端加上HTTPS，尤其是系统涉及用户登录和订单信息，明文传输密码确实不合适。

日志输出也别忽略。我在Service和DAO的关键入口用log4j或java.util.logging记录参数和异常堆栈，排查线上问题没有日志等于盲人摸象。项目不大，在本地测试时把所有SQL打印出来，看到实际执行语句比猜问题高效得多。

6.3 从演示系统到真实运营还差什么

课程设计做到这里已经完整，但从真实运营角度看，至少还缺支付、物流、营销、评价这些模块。支付不用自己实现，对接第三方支付网关的回调接口即可，关键学会处理回调时验签和订单状态更新的幂等。物流模块可以手动录入物流单号，再配合快递查询接口展示物流轨迹。

营销方面可以考虑优惠券、满减、限时折扣，公路车客单价高，用户决策周期长，优惠券对转化率帮助很大。评价模块对高单价商品尤其重要，老用户的骑行体验和尺码建议能帮助新用户做决策。

这些扩展如果全部用JSP硬写，后期维护会很吃力。真到了这一步，我更建议逐步把后端迁到Spring Boot，前端保留服务端渲染或者改Vue。但这里要提醒一句：迁移不是把JSP改成模板文件就完事，事务管理、依赖注入、拦截器配置方式全都不一样，需要评估收益再动手。

7. 经验总结与扩展方向

7.1 给新手的落地建议

如果你刚把这个题目拿到手，我建议别急着写代码，先花一个小时把用户故事写出来。比如“作为普通用户，我希望能按预算筛选公路车”，然后逐个用户故事对应页面和接口。我见过太多人一上来建了十几张表，写了一半发现购物车和订单对不上，推翻重来更浪费时间。

代码结构上一定要坚持分层，即使时间紧张也不要全部堆在Servlet和JSP里。我的经验是：优先把Service层写好，DAO层哪怕先用简单JDBC写好基础增删改查，页面往后再调。因为Service层承载核心业务逻辑，测试时可以直接写一个main方法调用Service，不依赖Web环境就能验证逻辑通不通。

版本管理从第一天就用起来。哪怕只有自己一个人开发，git commit的习惯也能让你随时回到可运行状态。很多同学最后答辩前把代码越改越乱，有个干净的历史记录能让心态稳很多。

7.2 哪些功能最值得做成亮点

想让这个项目在答辩或展示时更有竞争力，我推荐三个方向。第一是把商品筛选做得足够细，公路车的车架尺码、套件等级、刹车类型这些行业分类本身就是你系统的专业壁垒。第二是订单状态流转完整，从待支付到已发货再到已完成，每一步有明确的权限和操作动作。第三是后台数据统计做到能看趋势，哪怕只有近三十天的销售额列表，也远好过一潭死水。

如果学有余力，可以给系统加一个简单的订单Excel导出功能，后台管理员按时间范围导出订单明细，这个功能教务型项目里出现频率不高，但很能体现数据处理的落地能力。

我在实际整理这套系统时的体会是，类似“jsp网上公路车销售系统”这种题目，关键不是把JSP语法玩得多花哨，而是能不能把一个具体行业的商品特性、交易流程、后台管理完整串起来。公路车这个主题刚好介于垂直电商和工具系统之间，参数多、流程长、管理需求明确，特别适合练手。等你把购物车、订单、库存、权限这些东西都亲手写一遍，以后再面对复杂系统时会发现，很多地方其实都是这套逻辑的放大和变体。