Java电子商城毕设完整方案：SSM架构与数据库设计全解析

简介这是一份围绕Java电子商城系统的完整软件设计大作业资源面向高校软件工程、计算机相关专业学生也适合需要参考项目文档开展课程设计或毕业设计的开发者。压缩包共214个文件、约4.8MB除64个JSP页面与31个Java源码及对应class文件外还包含7个Word设计文档、SQL Server数据库文件mdf与ldf、jar依赖库、Struts标签库与XML配置以及前端图片、CSS、JS等素材目录结构清晰便于按模块检索和对照学习。项目基于MyEclipseSqlServer环境开发从需求分析、概要设计、详细设计到使用说明书一路贯穿完整文档链条业务代码覆盖商品管理、会员管理、订单管理、公告管理、后台管理等核心模块可直观呈现电子商城从数据库建设到页面展示、从前台交互到后台维护的实现全貌。已有991人浏览学习对于正在撰写同类软件设计文档或需要完整项目范本的读者有直接参考价值。1. Java电子商城项目方案从需求文档到源码数据库的完整闭环交付不少同学拿到“Java软件设计电子商城”这个毕设题目时第一反应是上网找一套源码跑起来看个界面就觉得完事了。但真正交作业的时候才发现导师要的是从需求分析、概要设计、详细设计到数据库说明、用户手册这一整套交付物少了哪份文档都要返工。更麻烦的是网上很多源码和文档是两拨人各自做的代码跑得通文档却对不上答辩时一追问就穿帮。这套方案解决的就是这个痛点它把源代码、数据库脚本、需求分析文档、概要设计文档、详细设计文档和说明书整合成一个完整项目让代码里的每一个功能都能在文档里找到对应描述文档里的每一个设计点也都能在代码里落地。适合两类人一是Java方向做毕设或课设的学生想拿一套结构完整的项目做二次改造二是需要在短时间内交付一套可演示、可验收的商城系统的从业者把它作为工程底子直接改业务。2. 需求分析先划清用户角色与功能边界再写用例文档需求分析是整个项目的起点也是最容易被跳过的环节。很多同学拿到题目直接建表写代码做到一半才发现漏了订单状态流转、漏了库存扣减逻辑回头改数据库改到怀疑人生。正确的做法是先花两天时间把用户角色、功能模块、业务流程和非功能需求梳理清楚再动代码。这一章的产出直接决定后面的概要设计和详细设计能不能写下去。2.1 三种用户角色与权限边界电子商城的用户角色通常可以分成三类游客、注册用户、管理员。权限边界要划清楚这决定了后台管理功能需要做哪些权限校验也决定了前端页面哪些入口需要隐藏。游客只能浏览商品列表、查看商品详情、通过商品名称做模糊搜索。一旦游客点击“加入购物车”或“去结算”系统要跳转到登录页而不是弹一个“请先登录”的提示了事——这里要做的是页面重定向配合拦截器后面详细设计会具体说。注册用户拥有游客的全部权限另外加购物车、修改购物车商品数量、提交订单、模拟支付、查看自己的订单列表和订单详情。注意“查看自己的订单”这个约束很关键用户只能看到自己的订单不能通过改URL参数看到别人的订单这属于越权访问漏洞需求分析阶段就要写明。管理员负责后台商品分类管理增删改查、商品管理上下架、库存调整、价格修改、订单管理查看所有订单、发货、关闭异常订单、用户管理禁用/启用账号。这里建议把管理员权限再拆一层超级管理员和普通运营管理员普通管理员不能删除用户、不能修改商品价格。虽然课设阶段可以不做这么细但需求文档里写清楚“预留权限分级设计”答辩时是加分项。2.2 前台与后台的功能模块清单功能清单可以用一张表格列出来表格一方面方便导师快速看全貌另一方面你自己对照着检查有没有遗漏。前台按用户操作路径拆注册与登录模块、商品展示模块分类列表、商品列表、商品详情、搜索、购物车模块加购、改数量、删除、勾选结算、订单模块提交订单、订单列表、订单详情、取消订单、模拟支付模块、个人中心模块收货地址、密码修改。后台按管理对象拆管理员登录、商品分类管理、商品管理、库存管理、订单管理、用户管理、数据统计看板。一个容易被忽略的模块是“数据统计看板”。很多同学的商城后台只有增删改查导师问“你的系统有没有数据可视化的部分”就答不上来。实际上在后台加一个简单的首页统计页展示今日订单数、今日销售额、商品总数、用户总数用一张柱状图展示最近七天的订单量代码量不大但功能完整性上明显高一个档次。2.3 用例模型与下单核心流程需求分析文档里一定要有用例图或者用例描述。不用画得很复杂三个参与者分别画几个用例就行。游客用例浏览商品、搜索商品、注册账号。注册用户用例登录、浏览、搜索、加购物车、修改购物车、提交订单、模拟支付、查看订单。管理员用例后台登录、商品管理、分类管理、订单管理、用户管理。场景描述部分要写核心业务流程最关键是下单流程。用户从购物车勾选商品点击结算系统需要依次做这些事校验用户登录态、查询购物车勾选商品、校验商品是否上架、校验库存是否充足、计算订单总金额、生成订单主表记录、生成订单明细记录、扣减商品库存、清空已结算的购物车项、跳转到支付页面。用户模拟支付成功后订单状态从“待付款”变成“待发货”。这段流程写清楚后面详细设计的Service层代码就是按这个步骤一行一行写出来的文档和代码能对得上。2.4 非功能需求性能、安全与可用性非功能需求是很多人不会写、但评审老师一定会问的部分。建议按性能、安全、可用性三条线写。性能方面这是模拟项目不需要吹高并发写明“系统按百人以下的小型商城规模设计普通列表页响应时间控制在2秒以内下单操作响应时间控制在1秒以内”就够。安全方面要写密码不能明文存储使用MD5加盐或BCrypt加密后台所有操作需要管理员登录态校验数据库使用预编译语句防止SQL注入用户订单查询必须带当前用户ID过滤。可用性方面写前端页面基于一套统一模板导航栏和底部信息全局一致表单提交要有前端校验和后端校验双重校验比如注册时手机号格式、密码长度。这些内容多数靠代码里能做出来写进文档不算空话。2.5 需求分析文档的成稿结构要是之前没见过规范的需求分析文档长什么样直接按这个章节结构套第一章引言写项目背景、编写目的、术语定义第二章可行性分析写技术可行性、经济可行性、操作可行性第三章用例模型画用例图并逐条描述用例第四章功能需求分前台、后台逐模块写功能描述和操作流程第五章非功能需求写性能、安全、可用性第六章运行环境写JDK版本、Tomcat版本、MySQL版本、浏览器兼容性。这套结构和代码里的包结构对应起来答辩的时候导师问你“需求分析你是怎么做的”你就按这个结构讲一遍回答非常完整。3. 总体架构与概要设计三层结构加四个核心模块的职责划分需求分析定了“做什么”概要设计要解决“怎么做”的问题。这一章重点是技术选型和架构分层以及模块之间的接口关系。很多同学的项目一崩到底没有模块边界所有逻辑写在JSP页面里或者Servlet里后面想加个功能都要动几十处代码。这一章看完你应该能理解三层架构为什么是这种结构也知道概要设计文档需要覆盖哪些内容。3.1 技术选型SSM加MySQL的经典组合技术栈选型要兼顾“技术主流”和“答辩好讲”通常采用Spring SpringMVC MyBatis简称SSM的组合数据库用MySQL 5.7或8.0部署容器用Tomcat 8或9构建工具用Maven前端页面用JSP加JSTL标签库配合BootStrap或Layui做后台界面。这套组合的优点是资料多、案例多、导师熟悉遇到问题搜一下就有解决方案。Spring负责对象管理和声明式事务SpringMVC负责请求路由和参数绑定MyBatis负责SQL操作。比Spring Boot多了一些配置工作量但正因为有这些配置详细设计文档能写出更多内容答辩时“你怎么理解IOC和AOP”这类问题也有得讲。有个容易踩坑的地方是Maven坐标版本不匹配。经验做法是统一使用一组经过验证的版本组合Spring 4.3.x、MyBatis 3.4.x、MyBatis-Spring 1.3.x、MySQL驱动5.1.x或8.0.x对应MySQL版本。如果MySQL是5.7驱动用5.1.47最省事如果用8.0.x驱动连接URL里必须加serverTimezoneAsia/Shanghai和useSSLfalse否则启动就报时区错误。这个细节写进概要设计文档的运行环境说明里能避免后面部署排查一大半问题。3.2 三层架构的职责边界整个系统按经典三层结构拆分表现层、业务层、持久层。表现层由JSP页面、CSS、JavaScript和SpringMVC的Controller组成职责是接收用户请求、调用业务层接口、把结果渲染到页面。这里的关键是Controller只做参数接收和结果转发不写业务逻辑。业务层由Service接口和实现类组成负责处理业务规则比如下单时先查库存再扣库存、订单状态流转的合法性校验、购物车加购时判断重复商品。持久层由MyBatis的Mapper接口和XML映射文件组成负责SQL操作一个方法对应一条SQL语句。三层之间通过接口调用Service只依赖Mapper接口不依赖具体实现这样换数据库或者改SQL不影响上层业务。分层之后每个模块的代码落在哪个包就很清晰了。控制层controller包、业务层service包、数据访问层mapper/dao包、实体类entity/pojo包、工具类util包、拦截器interceptor包。答辩时导师问“你项目的包结构怎么设计的”直接用这套结构回答层次感一目了然。3.3 四个核心模块的职责划分从概要设计角度整个商城可以拆成四个核心模块加两个辅助模块。用户模块负责注册、登录、个人信息维护包括密码加密、登录态写入Session、注册时用户名唯一性校验。商品模块负责商品分类查询、商品列表分页查询、商品详情查询、搜索、库存管理。购物车模块负责加入购物车、修改数量、删除、勾选结算、清空已结算项。订单模块最复杂负责订单创建、订单状态流转、模拟支付、订单列表查询、订单详情查询、取消订单。两个辅助模块是后台管理模块复用商品模块和订单模块的Service接口通过不同Controller暴露后台管理接口统计看板模块通过联合查询实现订单数和销售额统计。模块之间的依赖关系应该是单向的订单模块依赖商品模块的库存接口购物车模块依赖用户模块的登录态后台管理模块复用前台的Service接口。某宝上很多项目把订单库存逻辑写在Controller里模块边界就乱了这也是建议自己重写一遍Service层的原因。3.4 下单流程的时序级设计概要设计文档里要有一段下单流程的时序描述不用画复杂的时序图用步骤文字写清楚调用顺序。用户请求打到OrderController#createOrderController调用OrderService#createOrder(userId, addressId, cartItemIds)OrderService先通过CartMapper查询购物车选中项再遍历商品ID调用ProductMapper查询商品和库存。如果库存不足直接抛业务异常事务回滚如果库存充足先生成Order主记录状态为待付款再批量生成OrderItem明细然后调用ProductMapper扣减库存最后删除购物车选中项。整个方法加Transactional注解任何一个环节异常前面的数据库操作全部回滚避免出现订单生成了但库存没扣减的脏数据。这里有一个很多人会忽略的点库存判断和库存扣减必须在同一个事务里完成而且要直接操作product.stock stock - #{quantity}不要先查出stock再在Java里减一因为这样在并发场景下会有超卖风险。虽然课设不需要真正扛并发但设计文档里写明“使用原子更新语句保证库存不超卖”这个专业度是能拉开差距的。4. 数据库与详细设计核心表结构、建表SQL与说明文档的写法数据库设计是这套方案里含金量最高的部分因为导师拿到文档先翻数据库设计拿到代码先看建表SQL。很多同学的表设计随意字段类型不讲究外键关系也不建订单表里金额用double存——这些在答辩阶段都会被追问。这一章把核心表结构、建表SQL、索引与约束设计一次说清数据库设计文档照着改就能用。4.1 ER模型与实体关系概览先梳理实体关系数据库设计文档里会画ER图这里用文字描述清楚关系即可。系统涉及的实体有管理员、用户、商品分类、商品、购物车项、订单、订单明细。关系是一个用户对应多个订单一对多一个订单对应多个订单明细一对多一个商品分类对应多个商品一对多一个商品可以出现在多个订单明细中一个订单明细只对应一个商品购物车项从属于用户保存商品ID和购买数量用户提交订单后对应的购物车项被删除。购物车不单独建“购物车表再关联商品表”的复杂结构直接把商品快照放进购物车表字段设计成product_id、product_name、product_price、quantity。这样购物车列表页不需要联表查询后端代码也更简单。订单明细表更要注意必须保存商品名称、商品图片、下单时价格的快照因为订单生成后商品可能改价或下架订单历史数据不能被波及。4.2 核心表清单整个项目建七张表就够分别是管理员表、用户表、商品分类表、商品表、购物车表、订单主表、订单明细表。每张表的用途先在文档里列清楚然后逐表给字段说明表格。管理员表admin保存后台登录账号字段包括id、username、password、role角色、create_time。用户表user保存前台注册用户字段包括id、username、password、salt盐值、nickname、phone、email、status账号状态、create_time。商品分类表category字段包括id、name、parent_id父分类ID支持二级分类、sort排序号。商品表product字段包括id、category_id、name、subtitle副标题、main_image主图、detail详情富文本、price价格、stock库存、status上架/下架、create_time、update_time。购物车表cart字段包括id、user_id、product_id、product_name、product_price、quantity、checked是否勾选、create_time。订单主表orders注意订单表名别用order那个词在SQL里容易引起关键字冲突。字段包括id、order_no订单号、user_id、total_price、payment_type、status订单状态、receiver_name收货人、receiver_phone、receiver_address、create_time、pay_time、deliver_time、close_time。订单明细表order_item字段包括id、order_id、product_id、product_name、product_image、current_unit_price下单时单价、quantity、total_price。4.3 建表SQL核心实现用户表建表语句是整套数据库的基础注意几个关键设计用户名唯一索引、密码字段存加密后的哈希值不存明文、create_time用DATETIME类型默认当前时间。参考SQL如下CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(32) NOT NULL COMMENT 用户名, password VARCHAR(64) NOT NULL COMMENT 密码(MD5加盐), salt VARCHAR(16) NOT NULL COMMENT 盐值, nickname VARCHAR(32) DEFAULT NULL COMMENT 昵称, phone VARCHAR(20) DEFAULT NULL COMMENT 手机号, email VARCHAR(64) DEFAULT NULL COMMENT 邮箱, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态:1正常,0禁用, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT前台用户表;这里密码字段长度64是因为MD5加盐后的结果是32位十六进制字符再加上盐值拼接后做二次加密64位足够。用户名加唯一索引注册接口插入时如果报重复键异常就可以捕获后返回“用户名已存在”。表注释和字段注释必须写全导师看数据库文档时第一眼就是看注释是否完整。商品表在建表时要注意金额和库存的字段类型选择。金额用DECIMAL(10,2)不能用FLOAT或DOUBLE因为二进制浮点数在计算总价时会出现0.10.2不等于0.3的问题用DECIMAL能保证金额精确。库存用INT并加UNSIGNED约束保证非负。商品表SQL如下CREATE TABLE product ( id INT NOT NULL AUTO_INCREMENT COMMENT 商品ID, category_id INT NOT NULL COMMENT 分类ID, name VARCHAR(128) NOT NULL COMMENT 商品名称, subtitle VARCHAR(256) DEFAULT NULL COMMENT 商品副标题, main_image VARCHAR(256) DEFAULT NULL COMMENT 商品主图路径, detail TEXT COMMENT 商品详情, price DECIMAL(10,2) NOT NULL COMMENT 商品价格, stock INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 库存数量, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态:1上架,0下架, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), KEY idx_category_id (category_id), CONSTRAINT fk_product_category FOREIGN KEY (category_id) REFERENCES category (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;ON UPDATE CURRENT_TIMESTAMP 这个写法在MySQL 5.7及以上可以直接用修改商品信息时更新字段自动刷新不需要业务代码里手动更新。外层外键用逻辑外键还是物理外键我一般建议建物理外键课设阶段数据量小不会影响性能且能体现数据库设计的规范性导师问“你的数据一致性怎么保证”时可以直接指外键约束。订单主表和订单明细表是一对多关系要特别注意索引设计。两个表的SQL放一起看CREATE TABLE orders ( id INT NOT NULL AUTO_INCREMENT COMMENT 订单ID, order_no VARCHAR(32) NOT NULL COMMENT 订单编号, user_id INT NOT NULL COMMENT 用户ID, total_price DECIMAL(10,2) NOT NULL COMMENT 订单总金额, payment_type TINYINT NOT NULL DEFAULT 1 COMMENT 支付方式:1微信,2支付宝, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态:0待付款,1待发货,2待收货,3已完成,4已取消,5已关闭, receiver_name VARCHAR(32) NOT NULL COMMENT 收货人, receiver_phone VARCHAR(20) NOT NULL COMMENT 收货手机号, receiver_address VARCHAR(128) NOT NULL COMMENT 收货地址, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 下单时间, pay_time DATETIME DEFAULT NULL COMMENT 支付时间, deliver_time DATETIME DEFAULT NULL COMMENT 发货时间, close_time DATETIME DEFAULT NULL COMMENT 关闭时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表; CREATE TABLE order_item ( id INT NOT NULL AUTO_INCREMENT COMMENT 明细ID, order_id INT NOT NULL COMMENT 订单ID, product_id INT NOT NULL COMMENT 商品ID, product_name VARCHAR(128) NOT NULL COMMENT 商品名称快照, product_image VARCHAR(256) DEFAULT NULL COMMENT 商品图片快照, current_unit_price DECIMAL(10,2) NOT NULL COMMENT 下单时单价, quantity INT NOT NULL COMMENT 购买数量, total_price DECIMAL(10,2) NOT NULL COMMENT 小计金额, PRIMARY KEY (id), KEY idx_order_id (order_id), CONSTRAINT fk_order_item_order FOREIGN KEY (order_id) REFERENCES orders (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细表;订单主表要建联合索引查订单列表经常用WHERE user_id ? ORDER BY create_time DESC这里建了idx_user_id后查询走索引数据量大时性能差别明显。订单明细表的order_id外键关联订单主表删订单时如果明细存在会被外键约束拦下来这实际上是个很好的保护机制。订单号建议用时间戳加随机数生成格式类似yyyyMMddHHmmss加四位随机数比如202506131433221234长度32字符以内唯一索引保证不重复。4.4 索引、外键与存储引擎的约束设计数据库这块有几个习惯是从实际项目中沉淀下来的。第一所有表统一InnoDB不出现MyISAM。InnoDB支持事务、外键、行级锁对订单这种强一致性的业务是必须的用MyISAM在事务回滚时会留下脏数据。第二字符集统一utf8mb4不要用utf8。utf8mb4是utf8的超集能存表情符号MySQL 8.0默认就是utf8mb4如果建表用了utf8后期存用户昵称带emoji会直接报错。第三金额字段统一DECIMAL(10,2)订单总额、单价、小计都是这个类型Java端用BigDecimal接收不要用double。第四逻辑删除和数据状态用TINYINT存也许有人习惯用bit或char但TINYINT有更好的扩展性比如用户状态可以扩展成1正常、0禁用、-1删除三种状态。4.5 详细设计文档怎么落地详细设计文档要能指导编码包含类图描述、关键方法签名和接口逻辑、页面展示逻辑三层内容。类图用文字描述Controller层列出每个类的请求路径和方法名Service层列出接口方法签名Mapper层列出SQL功能描述。比如OrderController的完整描述是POST /order/create创建订单GET /order/list分页查询当前用户订单GET /order/detail/{orderNo}查询订单详情POST /order/cancel/{orderNo}取消待付款订单。每个方法写清楚参数来源、返回值类型、异常情况。详细设计里还要写清楚界面跳转逻辑。登录页是login.jsp注册页是register.jsp首页是index.jsp商品列表页是product/list.jsp商品详情页是product/detail.jsp购物车页是cart/list.jsp结算页是order/confirm.jsp支付结果页是order/pay.jsp订单列表页是order/list.jsp后台商品管理页是admin/product/list.jsp。页面路径对应关系写清楚后后面开发不用想就知道新功能页面放哪。5. 常见问题与部署排查六个最容易翻车的点现在把最容易让你在部署阶段翻车的六个问题提前列出来。这些问题不是在写文档时能遇到的而是在导入项目、运行代码时几乎一定会踩一遍。每一条都按现象、原因、解决三步拆开参考前先对照自己的项目看看有没有中招。5.1 数据库中文乱码现象页面商品名称、用户昵称显示成问号或者后台插入中文直接报错。原因字符集不一致。你在MySQL命令行里建库时用了latin1默认字符集或者连接URL没指定characterEncodingJava这边按UTF-8发送中文数据库按latin1存储一进一出全乱了。解决建库时显式指定字符集CREATE DATABASE shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;。连接URL里加参数jdbc:mysql://localhost:3306/shop?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai。这两处都改掉后重启Tomcat再测。血泪经验不要只在Java代码里设置编码数据库端和连接串不统一怎么设置Java都没用。5.2 JDK或Tomcat版本不匹配导致项目启动失败现象Tomcat启动时报UnsupportedClassVersionError或者Spring容器初始化时报ClassNotFound。原因项目用JDK 1.8编译本机装了JDK 11或更高版本Tomcat可能也不兼容新版JDK或者反过来代码里用了高版本JDK特性部署环境用的JDK 1.7直接崩。解决在IDE里把项目编译级别统一设为1.8本机装JDK 1.8的64位版本。Tomcat用8.5或9.0版本这两者是对JDK 1.8兼容性最好的组合。检查方式是在命令行执行java -version和mvn -version确认两个输出的Java版本一致。5.3 登录状态Session丢失现象登录成功后跳转首页正常但点进购物车或者订单页又被拦截器弹回登录页。原因拦截器拦截路径配置错了把静态资源或公开页面也拦了或者Session存储有问题登录成功后没有把用户对象放入Session拦截器检查不到用户就重定向。解决登录接口里写入Sessionsession.setAttribute(loginUser, user)。拦截器校验逻辑定义为没有loginUser且请求的路径不是/user/login*开头的重定向到登录页。放行列表必须包含登录、注册、首页、商品列表、商品详情、静态资源/static/**。在拦截器preHandle方法里加一段日志调试每次拦截打印请求URI你就知道卡在哪个路径上。5.4 商品图片上传后访问404现象后台商品管理上传图片提示成功但商品列表页图片裂开浏览器地址栏直接访问图片路径也返回404。原因图片保存到了本地磁盘目录但Tomcat的工作目录和图片保存目录不一致。商品详情页显示的图片URL是相对路径比如/upload/xxx.jpg但Tomcat默认没有把/upload映射到磁盘目录。解决最简单的方案是给Tomcat配置虚拟目录在server.xml的Host节点下加Context映射Context docBaseD:/shop/upload path/upload /这样请求/upload会直接读取磁盘目录。如果没有修改Tomcat配置权限就把图片保存路径放到项目部署目录下的upload文件夹里用request.getServletContext().getRealPath(/upload)拼绝对路径虽然重启后可能清掉文件但课设演示够用。5.5 订单金额计算误差现象购物车三件商品价格分别是19.9、39.9、59.9购物车显示总价119.7下单后订单总金额变成119.70000000000001或者尾数少了0.01。原因Java代码里用double或float计算金额二进制浮点数无法精确表示十进制小数累加产生误差。解决数据库金额用DECIMALJava实体类金额字段用BigDecimal计算总价时用BigDecimal.add()不要用运算符。前端价格展示用String.format(%.2f, price)格式化。库存和数量的加减用int不要转成double运算。5.6 Maven依赖冲突或下载极慢现象导入项目后mvn compile报依赖缺失或者一直卡在下载依赖的步骤等十分钟还没动静。原因本地Maven仓库没有对应jar包中央仓库访问慢或者不同传递依赖引入了同一个jar包的多个版本。解决配置阿里云Maven镜像修改settings.xml的mirror节点。依赖冲突用mvn dependency:tree查看依赖树找到重复的spring包后在pom里用exclusion排除旧版本。如果是Spring版本冲突导致Bean创建失败优先检查spring-core、spring-context、spring-webmvc是不是同一个版本号。6. 验收与答辩功能自查清单与演示脚本到了最后一步代码能跑、文档写完还差一个环节自己按验收标准走一遍再准备答辩话术。很多项目其实是“做完”但没“验收”演示到一半点出一个没处理好的异常整个答辩就很被动。先把验收清单列出来再给你一套演示脚本思路。6.1 验收自查清单验收的核心是“从用户注册到后台发货”这条链路全部能走通下面这张表覆盖了大部分导师会演示的功能点。验收点操作步骤预期结果用户注册进入注册页输入用户名密码注册成功跳转登录页重复用户名提示已存在登录与拦截未登录访问购物车页面自动跳转登录页并携带回跳地址商品浏览首页点击分类搜索关键字列表分页展示搜索能命中名称匹配商品购物车加购商品详情页点击加入购物车购物车页面数量1同一商品不重复生成记录下单流程购物车勾选商品后点结算填写收货地址生成待付款订单库存扣减模拟支付在订单详情页点击支付订单状态变为待发货页面上显示支付成功文案后台订单处理管理员在后台查看订单并发货订单状态变为待收货前台用户可见状态变化用户权限隔离用户A访问用户B的订单详情URL返回无权访问提示或跳转500页面6.2 答辩演示脚本一条链路走完演示不要零散地“点这个、点那个”按一条完整商业链路走现场注册一个账号登录搜索一个商品加入购物车修改数量勾选结算填写收货地址提交订单模拟支付然后切换到管理员账号在后台订单列表看到这笔新订单点击发货再切回用户账号看到订单状态变成待收货。整条链路走完评审基本能看出系统的完成度。演示时注意两个细节提前准备测试数据MySQL里预置10到20个商品、5到6个分类一个管理员的账号和一个普通用户的账号不要现场注册浪费时间浏览器建议用Chrome数据库连接提前测试不要出现演示中途连接超时的尴尬。6.3 高频提问与应答准备答辩问来问去就那么几类提前准备能答得很从容。导师问你的系统有哪些模块按需求分析的角色和功能模块回应。导师问订单状态怎么设计翻到订单表枚举和Service层的状态流转逻辑。导师问数据库有哪些表、为什么这么设计从ER关系到表字段职责逐一讲。导师问你用到了哪些框架、为什么选SSM重点讲Spring的IOC和AOP、MyBatis的SQL解耦。导师问有没有考虑安全性讲密码加盐、SQL预编译、Session拦截、越权校验。这些问题不用背照着文档结构讲就行前提是前面五章的内容你真的读懂了。当年我做模拟项目X的时候第一次演示就因为没走验收清单翻车了——注册页没做表单校验现场信手输了个非法手机号后端直接报500。从那以后我每次跑项目都强制自己走一遍完整验收链路从用户注册到后台发货中间每个环节要截图记录再把截图整理进用户手册。这个习惯帮我挡住了好几次演示事故希望帮到你。本文还有配套的精品资源点击获取