企业官网建设流程全解析

写这个标题的项目，对我来说太熟悉了。光是看“基于Web的电子产品销售系统设计与实现(文档+源码)_kaic”这行字，就能猜到这大概率是一个高校计算机专业的课程设计，或者是本科毕业设计。这个后缀“_kaic”一般是作者标识，说明这是一份被很多人反复下载、复用的经典题目。

这类项目之所以经久不衰，是因为它踩中了Web开发教学的所有关键点：前端页面、后端逻辑、数据库设计、会话管理、分层架构，一个不少，但又不会难到让本科生无从下手。今天我就来专门拆解一下这个项目，从需求分析到数据库设计，从核心模块实现到最后的文档撰写和部署答辩，把每一步的“为什么”和“怎么做”都讲透。无论你是正在做这个题目的学生，还是想拿它当练手项目积累经验的初学者，这篇都能给你省下大量翻资料和踩坑的时间。

1. 项目整体设计与思路拆解

1.1 从标题里能读出哪些关键信息

一个规范的课程设计标题，信息量远比看上去大。把“基于Web的电子产品销售系统设计与实现”拆开看，能明确这样几条硬性要求：

• “基于Web”限定了系统架构。它不是一个单机版桌面程序，也不是纯移动App，而是通过浏览器访问的B/S架构应用。简单说，用户在浏览器里输入网址，就能看到商品、下单、结算。
• “电子产品”限定了业务范围。系统需要围绕“电子产品”这个品类做功能设计，意味着商品信息要包含品牌、型号、参数（比如内存、存储、屏幕尺寸、电池容量等），甚至要有一些基础的筛选条件。
• “销售系统”限定了核心业务流程。购买、加入购物车、订单管理、库存管理这几个电商基本盘必须覆盖，逻辑上要说得通。
• “设计与实现”限定了交付形式。不只要做出能跑的代码，还要有一整套设计文档，包括需求分析、数据库设计、系统架构图和核心功能说明。这也是很多同学会忽视的部分。

配套的“文档+源码”也印证了这一点。课程设计或毕设的评估者通常会同时看重写出来的论文和跑起来的系统，两者缺一都会影响成绩。

1.2 核心业务流程图与模块划分

在动笔写任何代码之前，先把业务流程理清楚。电子产品销售系统的完整业务闭环大概是这样的：

用户注册登录后，浏览商品列表，可以查看商品详情，将心仪的商品加入购物车，在购物车中调整数量、删除商品，然后提交订单完成结算。管理员登录后台后，可以管理商品分类、发布或下架商品、修改库存数量、查看并处理用户订单。

根据这个流程，系统按角色划分为两大端，四个核心模块：

• 用户端：注册登录、商品浏览、购物车、订单管理
• 管理端：商品管理、分类管理、订单处理、用户管理

1.3 为什么推荐JSP+Servlet而不是Spring Boot

这是一个很多同学会纠结的问题。课程设计阶段，到底用传统的Java Web三层架构（JSP + Servlet + JDBC），还是用Spring Boot这种更现代的框架？

我的建议是：除非指导老师明确要求用Spring Boot，否则优先选择经典的JSP + Servlet + MVC模式，理由是：

第一，课程设计的评分核心是“设计思路清晰、基础原理扎实”。使用Servlet能直观地展示HTTP请求的处理流程，使用JSP能展示服务端渲染页面的过程。相比Spring Boot在底层帮你封装好一切，传统方式反而更容易在答辩时讲清楚“一个请求从浏览器到数据库再返回浏览器，中间经历了什么”。

第二，传统方式的代码量可控，调试难度低。一个Servlet 处理一个模块，代码结构一目了然，出了问题定位很快。Spring Boot 虽然配置少，但一旦报错涉及自动配置、依赖冲突，对没有经验的初学者来说排查起来非常痛苦。

第三，环境要求低。只需要JDK + Tomcat + MySQL，不需要Maven的复杂依赖管理。在没有外网的情况下也能顺利开发运行。

不过，如果你是自学并且时间充裕，用Spring Boot做也未尝不可，只是要在文档中补充说明框架的选型理由。技术本身没有高下之分，能自圆其说、能跑通，就是好方案。

2. 数据库设计：电商系统的地基

2.1 核心表结构设计

数据库设计是整个系统中最重要的环节。很多同学代码写完了，数据库却只有一张用户表、一张商品表，这种设计在答辩时很容易被问住。一个合格的电子销售系统，至少需要以下几张表：

用户表（user）字段包括：用户ID、用户名、密码（MD5加密存储）、手机号、邮箱、注册时间、用户角色（区分普通用户和管理员）、账号状态（是否禁用）。

商品分类表（category）字段包括：分类ID、分类名称、父分类ID（用于多级分类），比如“手机数码”下挂“手机”、“平板电脑”、“耳机音箱”。如果不想做多级分类，至少也要有单级分类，否则商品体系没有维度。

商品表（product）字段包括：商品ID、分类ID、商品名称、商品描述、品牌、型号、价格、库存数量、图片路径、上架状态、创建时间。电子产品通常有规格参数，建议增加一个参数描述字段，用JSON格式或纯文本保存关键配置，如“8GB+256GB 曜石黑”。

购物车表（cart）字段包括：购物车ID、用户ID、商品ID、数量、加入时间。这里要注意，很多初学者会把购物车设计成“只存当前选中商品”，刷新页面就没了，这是不对的。购物车应该持久化到数据库，这样用户退出再登录后，购物车数据还在。

订单表（order）字段包括：订单ID、订单编号（唯一，用于展示和查询）、用户ID、订单总金额、收货人姓名、收货地址、联系电话、订单状态（待付款、已付款、已发货、已完成、已取消）、下单时间、支付时间。

订单明细表（order_item）字段包括：明细ID、订单ID、商品ID、商品名称（快照）、商品价格（快照）、购买数量、小计金额。

这里有一个非常重要的设计原则：订单明细中必须保存商品名称和价格的快照，而不是直接关联商品表去查询。因为电商业务中，商品价格和名称随时可能变动。用户在3月1日下单时商品是100元，商家在3月2日改成了120元，用户的订单记录中应该保留100元这个历史信息。如果直接关联商品表，订单数据就会跟着被污染。

2.2 表关系与外键设计

表之间关系如下：

• 用户表与购物车表：一对多。一个用户可以有多个购物车记录，每条记录对应一种商品。
• 用户表与订单表：一对多。一个用户可以有多个订单。
• 订单表与订单明细表：一对多。一个订单包含多条明细。
• 商品分类表与商品表：一对多。一个分类下有多个商品。
• 商品表与订单明细表：通过订单明细中的商品ID建立逻辑关联。

关于外键约束，课程设计要求用InnoDB引擎，且明确定义外键关系。但这里有一个经验之谈：外键逻辑上要有，物理上不一定要加。

我在多个项目中踩过这个坑。加了物理外键，删除商品或分类时会不断触发外键约束报错，尤其在管理端“删除一个商品分类时，该分类下还有商品”的场景下，处理起来非常繁琐。建议的作法是：表结构中不声明FOREIGN KEY，但在设计文档的E-R图中明确画出关系，在业务代码中通过逻辑判断来保证数据一致性。这样既能满足教学要求，又避免了实际开发中物理外键带来的麻烦。

数据库建表脚本示例（简化版）：

CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, phone VARCHAR(20), role TINYINT DEFAULT 0 COMMENT '0-普通用户 1-管理员', status TINYINT DEFAULT 1 COMMENT '0-禁用 1-正常', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, parent_id INT DEFAULT 0 ); CREATE TABLE product ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL, name VARCHAR(100) NOT NULL, brand VARCHAR(50), model VARCHAR(50), price DECIMAL(10,2) NOT NULL, stock INT DEFAULT 0, image VARCHAR(255), description TEXT, status TINYINT DEFAULT 1 COMMENT '0-下架 1-上架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE cart ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, product_id INT NOT NULL, quantity INT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id INT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, receiver_name VARCHAR(50) NOT NULL, receiver_phone VARCHAR(20) NOT NULL, receiver_address VARCHAR(255) NOT NULL, status TINYINT DEFAULT 0 COMMENT '0-待付款 1-已付款 2-已发货 3-已完成 4-已取消', 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, product_name VARCHAR(100) NOT NULL, product_price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL, subtotal DECIMAL(10,2) NOT NULL );

2.3 数据初始化与测试数据

一个很常见的现象是，系统开发完了，演示给老师或同学看时，页面上却只有三四个测试商品，看起来特别寒酸。

建议在数据库中预置一批真实的电子产品数据，比如苹果iPhone 15 Pro、华为Mate 60 Pro、小米14、索尼WH-1000XM5耳机、佳能微单相机、联想拯救者笔记本等，每个商品带上真实的参数描述、合理的价格和库存。分类数据也尽量完整，手机数码、电脑办公、智能设备、影音娱乐，每类下至少放3至5个商品。

有了充实的测试数据，系统演示效果会好很多，也方便截图放进设计文档。还有一个额外好处：分页效果、搜索效果、分类筛选这些功能，只有在数据量足够时才能完整展示，数据太少会让人以为是功能没做。

3. 核心模块实现与关键技术细节

3.1 用户注册登录与会话管理

用户模块是整个系统的入口，实现要点集中在密码加密和会话跟踪。

MD5加密虽然是老技术，但在课程设计中使用非常普遍。注意在加密时拼接一个固定盐值，例如MD5(password + "salt2024")，避免直接加密明文密码。这样即使数据库泄露，密码也不会立刻被还原成明文。

会话管理用Session即可。用户登录成功后，将用户ID和用户名存入Session，之后每个页面通过判断Session中是否存在用户信息，来决定页面是显示“登录/注册”还是显示“欢迎你，xxx / 退出登录”。管理员登录后，同样在Session中标记管理员角色，并在管理员页面的请求入口过滤鉴权。

这里有一个很容易被忽视的细节：用户发起退出登录时，除了跳转回登录页，必须调用session.invalidate()销毁会话，否则别人在同一个浏览器上刷新页面，还会看到上一个用户的信息。这个在答辩演示时非常容易翻车。

注册登录的JSP页面表单要做服务端校验。前端JS校验只能防误操作，防不了恶意请求。服务端至少要检查用户名是否已存在、密码长度是否合格、两次输入的密码是否一致。

3.2 商品列表、搜索与分页

商品列表页是用户看到的第一个核心页面，实现上最容易出问题的是分页。

分页设计要考虑三个参数：当前页码page、每页条数pageSize、总记录数totalCount。总记录数通过SELECT COUNT(*) FROM product WHERE 条件得到，总页数totalPages = (totalCount + pageSize - 1) / pageSize。当前页的数据用LIMIT子句查询：

SELECT * FROM product WHERE status = 1 ORDER BY create_time DESC LIMIT #{offset}, #{pageSize}

其中offset = (page - 1) * pageSize。这是MySQL分页的经典写法，需要理解为什么要用(totalCount + pageSize - 1) / pageSize来向上取整，而不是简单的totalCount / pageSize。比如总共10条数据、每页3条，10/3等于3.33，总页数应该是4页，向上取整才能得到正确结果。

搜索功能同样要支持分页。搜索条件通过表单GET方式提交，URL形如product_list.jsp?keyword=手机&categoryId=2&page=1。后端根据条件动态拼接SQL中的WHERE子句。这里要注意SQL注入防护，使用PreparedStatement的占位符，不要直接用字符串拼接SQL。

分类筛选的实现可以在商品列表页左侧提供一个分类树，点击某个分类后，URL携带categoryId参数，后端按分类查询。多级分类如果做了父子关系，查询子分类时可以先将该分类及其子分类ID收集成List，再用IN查询，而不是简单等值匹配。

3.3 购物车与订单状态机设计

购物车的实现要点是“加入购物车”时要检查商品是否已存在于该用户的购物车中。如果已存在，则将该条记录的数量加1；如果不存在，才新插入一条记录。这个逻辑用一句话概括就是“有则加数量，无则新增记录”。

订单模块是整个系统的核心，这里有一套比较完整的状态流转逻辑：

• 状态0（待付款）：用户提交订单后生成。此时库存可以先预留，也可以在下单时直接扣减。为了演示方便，我建议在下单时直接扣减库存，同时增加“库存不足则无法下单”的判断。
• 状态1（已付款）：用户点击“模拟支付”后将订单状态从0改为1。
• 状态2（已发货）：管理员在后台确认发货，更新物流信息（可选）。
• 状态3（已完成）：用户确认收货。
• 状态4（已取消）：用户支付前取消订单，或管理员关闭异常订单。

订单状态的每次变更，都要在代码中判断当前状态是否允许变更。例如，状态为“已完成”的订单不能被再改成“已付款”，状态为“已发货”的订单不能直接被取消。建议将状态变更封装成统一的Service方法，不直接在Servlet中散落大量脏逻辑。

下单过程的完整事务逻辑大致如下（伪代码）：

// 1. 查询购物车，校验商品是否存在且库存充足 // 2. 计算订单总金额 // 3. 插入订单表，获取订单ID // 4. 循环插入订单明细表，同时扣减商品库存 // 5. 清空该用户的购物车 // 6. 以上任何一步失败，整体回滚

在JDBC中控制事务的做法是：获取连接后setAutoCommit(false)，try块中执行完所有SQL后commit()，catch块中rollback()。很多同学在订单功能上最大的问题就是没有加事务，导致订单表有记录、明细表为空，或者库存扣了但订单没生成，数据乱七八糟。这个问题在答辩时几乎是必被问的，一定要提前处理好。

4. 前端页面设计与交互细节

4.1 页面整体布局

对于课程设计项目，前端不要求酷炫，但要求整洁、统一、功能完整。推荐用一个统一布局模板，包含顶部导航栏、左侧分类栏、右侧内容区域。

顶部导航栏放系统名称、搜索框、购物车入口、用户登录信息。左侧按商品分类展示树形菜单。右侧是主要内容区，根据用户点击动态展示商品列表、商品详情、购物车或订单页面。

页面样式不需要引入Bootstrap这种重型框架，使用少量自定义CSS就足够。关键是各页面风格一致、对齐规范、按钮和表单元素大小统一。字体建议统一设为14px左右，商品卡片对齐，价格字段用醒目的红色或加粗。

4.2 商品详情页的展示逻辑

商品详情页通常放置在product_detail.jsp，通过URL参数id定位商品，例如product_detail.jsp?id=3。后端根据ID查询商品基本信息，展示商品大图、名称、品牌型号、价格、库存、规格参数和描述文字。

页面下方是“加入购物车”和“立即购买”按钮。“立即购买”本质上就是“加入购物车后直接跳转到订单确认页”，课程项目中不必单独为“立即购买”建一套逻辑，复用一个流程即可。

商品图片建议使用相对路径存储在项目的uploads目录下，不要用外链图片。外链地址经常失效，答辩时万一图片加载不出来，整个演示效果会大打折扣。如果没有合适的商品图片，可以在图片上用纯色背景加上商品名称文字，效果也比“图片无法显示”的图标好得多。

4.3 购物车与结算页的交互设计

购物车页除了展示用户加入的商品列表，还要支持修改数量、删除商品、全选/取消全选，以及自动计算已选商品的总金额。这一块的金额计算建议用JavaScript在前端实时算出，减少无谓的请求；提交订单时，后端再根据数据库中的价格重新计算一次，防止人为篡改。

提交订单时，需要填写或确认收货人信息（姓名、电话、地址）。这一步页面可以预先从用户表中读取用户的默认电话和地址，允许用户在本次下单时修改，但不要直接改用户的注册信息。订单表保存的是本次下单时的收货信息快照。

5. 设计文档的撰写方法与答辩准备

5.1 文档整体结构与写作节奏

和代码同样重要的是文档。很多同学代码写得不错，但文档随便从网上下载拼凑，结果查重不过关，或者和代码完全对不上，被老师一眼看穿。正确的方法是把文档和代码当作同一个项目的两个侧面，让文档真正描述你实现的系统。

一份完整的课程设计文档通常包含这样几个章节：

1. 绪论：项目背景、研究意义、国内外研究现状（简单写即可）。
2. 需求分析：功能需求（用户端和管理端的功能列表）、非功能需求（性能、安全性、易用性）。
3. 系统设计：架构设计（B/S三层架构）、功能模块划分、数据库设计（E-R图、表结构）、界面设计（页面草图或截图）。
4. 系统实现：分模块描述核心功能的实现逻辑，配合关键代码片段和页面截图。
5. 系统测试：测试用例表，包括功能测试和异常测试的结果。
6. 总结：遇到的问题、解决过程、不足与展望。

写系统实现这一章时，切忌把全部源码直接粘贴进去。每节选一段最核心的代码即可，其他部分用文字描述实现思路。代码必须保证能和你提交的源码对应上，答辩时老师可能会指着文档里的某段代码问这是做什么的。

5.2 逢讲必问的几个问题要提前准备

根据我带过的学生反馈，答辩时最高频的问题大致有这些，提前准备能稳很多：

问一：你这个系统用了几张表，各表之间是什么关系？ 答：围绕用户、分类、商品、购物车、订单、订单明细六张表展开，画一下E-R图，讲清楚一对多关系。

问二：订单表为什么要和订单明细表分开？不能把多个商品直接存在一个订单表的字段里吗？ 答：数据库第一范式要求字段不可再分。订单和订单明细分开，可以支持一个订单包含多个商品，且每个商品的名称、价格快照都可以独立存储和查询。

问三：商品库存是怎样扣减的？并发的时候会不会超卖？ 答：课程设计可以回答“使用事务保证扣库存和生成订单的原子性”。如果被追问高并发，可以补充说明“生产环境中会使用乐观锁或Redis分布式锁，本系统因定位教学场景，使用数据库事务已足够”。

问四：密码是明文保存的吗？ 答：不是，使用了MD5加盐加密。进一步追问MD5是否安全时，可以回答“MD5安全性有限，生产系统推荐使用BCrypt等自适应哈希算法，课程设计中采用MD5加盐是出于教学和演示目的”。

问五：你遇到的最大难点是什么？ 答：这是开放题，一定要准备一个真实点。比如“加入购物车时判断商品已存在并累加数量的逻辑最初没有封装好，导致重复插入多条记录，后面通过创建唯一联合索引并在代码中做先查询后更新解决了”。这种回答比“我好像没遇到什么难点”强一百倍。

5.3 折叠式源代码与关键表结构在Word中的排版技巧

写文档时有个细节：Word中插入长代码会撑乱页面，建议使用等宽字体配合灰色底纹，字号调小到五号甚至小五号，插入表格时使用三线表样式。E-R图和流程图用Visio或draw.io绘制，导出的图片要清晰，放进文档时注意缩放，不能大得撑满整页也不能小到看不清文字。

数据库的每个字段都要在文档中建立“数据字典”表格，标注字段名、数据类型、是否主键、是否为空、默认值、备注说明。这属于看起来工作量不大、但老师非常看重的部分，也会影响文档的评分等级。

6. 开发环境搭建与部署运行

6.1 必要工具清单与版本搭配

一个能顺畅跑起来的开发环境，建议使用以下组合：

• JDK 8：最稳妥，兼容性好，Tomcat 8/9支持完美。不要用JDK 17以上的版本跑老代码，模块访问限制会带来莫名其妙的报错。
• Tomcat 8.5：部署简单，Eclipse和IDEA都有现成的服务器插件。
• MySQL 5.7：经典版本，初始化脚本不会有兼容性问题。
• Eclipse IDE for Enterprise Java and Web Developers 或 IntelliJ IDEA（社区版也可以用）：推荐IDEA，自带Tomcat集成，调试功能更直观，但需要手动配置Artifact部署。

6.2 在IDEA中创建Web项目的完整步骤

如果你用的是IDEA 2024版本，创建传统的Web项目（非Maven）时与老版本有一些差异，这里给出一个可靠的流程：

第一步，新建Project。选择“Empty Project”或“Java Enterprise”都可以。选择Java Enterprise时，会有Web Application的模板，勾选后自动生成web/WEB-INF/web.xml，结构更完整。

第二步，配置Tomcat。进入Run菜单 -> Edit Configurations -> 左上角“+” -> Tomcat Server -> Local。选择本地的Tomcat安装目录。注意在Deployment选项卡中，点击“+”添加Artifact，选择war exploded，Application context可以设置为/electronic_mall或直接设为/（方便访问）。这一步经常有人漏掉，导致启动Tomcat后报404，务必检查。

第三步，添加依赖。在Project Structure中，给模块添加Tomcat提供的Servlet API依赖，以及MySQL JDBC驱动JAR包。JDBC驱动推荐使用mysql-connector-java-5.1.49版本，兼容JDK 8和MySQL 5.7，不会出现认证插件问题。

第四步，配置数据库连接。在项目下新建一个db.properties配置文件，集中管理数据库的连接参数：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/electronic_mall?useUnicode=true&characterEncoding=utf8&useSSL=false jdbc.username=root jdbc.password=123456

然后封装一个DBUtil工具类，使用静态代码块加载驱动，对外提供getConnection()方法。所有DAO层都通过这个工具类获取连接，统一管理，避免在每个类中重复写连接代码。

6.3 部署到Tomcat后的验证流程

启动项目后，按顺序验证下面的流程。这也是我在每次演示前的必查清单：

1. 访问项目首页，能否正常打开商城。首页加载无报错、无CSS丢失。
2. 注册一个新用户（使用未被占用的用户名），注册成功后自动跳转登录页，用刚注册的账号登录。
3. 浏览商品列表，点击某一商品查看详情，加入购物车，在购物车页面把数量改为2，点击“结算”。
4. 填写收货信息并提交订单，确认订单金额正确，库存数量较之前减少2。
5. 管理员账号登录后台，查看刚才创建的订单，处理发货。
6. 退出登录，再重新登录，确认购物车和订单数据仍然存在。

整个过程走通，项目才算真正“实现”了。如果中途报错，先看控制台日志，重点排查数据库连接和SQL语句的问题。

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

7.1 数据库连接和中文乱码问题

数据库连接不上是最常见的问题，占据所有课程设计报错的大约一半。通常报错Type: java.sql.SQLException。排查顺序是：确认MySQL服务是否启动；确认用户名密码是否正确；确认URL中的数据库名是否存在；确认Tomcat的lib目录下有MySQL驱动JAR包。

中文乱码的根源是编码不一致。解决办法是：数据库建库时指定DEFAULT CHARSET=utf8mb4；JDBC URL追加useUnicode=true&characterEncoding=utf8；JSP页面顶部pageEncoding设置为utf-8；Servlet中使用request.setCharacterEncoding("utf-8")放在任何读取参数之前。

还有一个容易被忽略的坑：MySQL中的utf8mb4和普通utf8的差异。如果需要在前端展示emoji或特殊表情，建议使用utf8mb4，但课程设计一般用不上，统一用utf8即可。

7.2 页面404和500报错的定位技巧

404通常说明请求路径不对。检查web.xml中Servlet的url-pattern配置是否和表单提交的action路径一致，检查页面文件是否放在web目录下的正确位置，检查Tomcat部署的Application context是否与访问地址匹配。

500通常说明后端代码运行时出现了未捕获的异常。最有效的定位方法不是反复刷新页面，而是打开IDEA的控制台，找到Tomcat Localhost Log标签，那里有完整的异常堆栈。常见原因包括：空指针（查不到数据、参数没传）、SQL语法错误、ClassNotFoundException（缺驱动或缺JAR包）。把异常堆栈复制到搜索引擎搜一下，基本都能找到解决方案。

7.3 访问页面时CSS样式丢失

这是一个非常经典的问题，尤其在使用Servlet通过转发（forward）跳转JSP时经常出现。原因是使用相对路径时，如果请求URL是多层路径（如/product/detail），浏览器解析相对路径的基准会发生变化，导致CSS文件加载路径错误。

解决方案是页面中统一使用绝对路径，在JSP页面顶部通过<%=request.getContextPath()%>获取项目根路径后拼接资源路径，例如：

<link rel="stylesheet" href="<%=request.getContextPath()%>/css/style.css">

这样无论请求路径怎么变化，CSS和JS文件的定位始终以项目根路径为基准。虽然可以把响应重定向（sendRedirect）来解决部分问题，但根治方法就是使用绝对路径。

7.4 数据库时间字段显示错误的处理

如果服务器或电脑的时区设置不对，数据库中的时间会比正常时间早8小时或晚8小时。排查时先检查MySQL连接的URL是否有serverTimezone=Asia/Shanghai参数。没有添加的话补上即可。如果数据库表使用了TIMESTAMP类型，注意它受数据库时区影响，DATETIME类型则不受时区影响。

8. 我个人在反复做这类项目后的几个建议

这类“Web + 销售系统”的题目，在计算机类的课程设计和毕设中几乎是常青树。重复做多了，有几个体会非常深刻。

第一个建议是，代码一定要控制在“能讲明白”的复杂度内。不要为了炫技引入一堆设计模式、分布式概念，结果自己都讲不清楚为什么这么写。课程设计的本质是展示你把所学的基础知识综合运用的能力，把JSP、Servlet、Session、JDBC、事务这些基础点做扎实，比堆砌高大上的技术名词更有价值。

第二个建议是，留出至少两天专门做联调和自测。很多同学喜欢把代码全部写完再统一测试，结果问题集中爆发，各种报错交织在一起，根本不知道从何排查。更高效的方式是每写完一个模块就立刻测一个模块：用户模块完成后马上测注册登录；商品模块完成后马上测列表分页；购物车完成后马上测加购和数量变更。小步快跑，问题会分散且容易定位。

第三个建议是，在系统里预留一个容易演示的入口。比如在首页用管理员账号设置初始数据，演示时直接登录管理员后台，快速展示数据管理的完整操作。还可以在文档里做一个“系统操作说明”的附录，写明管理员账号密码和测试用户账号密码，方便老师或评审第一时间登录体验。

第四个建议关于“文档+源码”的完整性：提交前把所有文件打包成一个压缩包，命名规范一些，比如学号_姓名_电子产品销售系统.zip。包内分为源码、数据库脚本、设计文档、README四个文件夹。README里写清楚项目环境要求、数据库初始化步骤、启动方法。就我遇到的不少情况而言，光是一个清晰的目录结构，就能在提交材料时给负责接收的老师留下好印象。

这个项目做到最后，你会发现它其实是一个“麻雀虽小、五脏俱全”的完整电商系统。把它的每个模块吃透，再去做更复杂的分布式项目，很多数据库设计、状态流转、事务处理的思路都是相通的。希望这篇拆解能帮你少走弯路，顺利搞定这个项目。