企业官网建设流程全解析

把“基于JavaWeb(SSM+Vue)的网上药店系统设计与实现”这类项目做好，其实是很多同学从“会写几个接口”迈向“能独立交付一个完整系统”的必经一课。表面上看起来是药品信息加订单的常规管理，真正动手后你会碰到权限拦截、购物车状态、库存扣减、订单状态流转、后台统计、文件上传这些前后端联动问题，几乎把JavaWeb开发里最常见的业务场景都过了一遍。这篇文章不打算罗列功能清单，而是把这个项目从设计、编码到论文和演示视频的系统性思路拆开讲，希望对正在做毕设、求职项目或者想补全工程能力的人有参考价值。

1. 项目到底解决什么问题，为什么选SSM+Vue

1.1 网上药店系统的真实业务场景

网上药店系统不是简单的“药品展示网页”。药品这种商品有几个特殊点：价格波动不频繁但分类复杂，用户需要按症状、用途、品牌、处方类型筛选；订单生成后会有待支付、已支付、已发货、已完成、已取消等多种状态；管理端需要管理药品上下架、库存预警、处理用户订单，可能还要处理处方图片上传。这些需求叠加在一起，就决定了系统必须有一个清晰的角色边界和状态边界。

从用户的视角来看，核心流程是注册登录、浏览药品、关键词搜索、加入购物车、提交订单、模拟支付、查看订单状态。从管理员的视角来看，核心流程是药品分类维护、药品信息CRUD、库存调整、订单发货。两个视角的权限完全不同，所以系统建模的第一件事不是写接口，而是把角色、菜单、操作点全部列清楚，再落到数据库表和路由上。

1.2 为什么是这个技术组合

SSM指Spring、SpringMVC、MyBatis，前端用Vue，这组合在今天看不是最新的，但在很多课程和毕业设计里依然能打。选择它的理由很实在：

• Spring负责对象管理、事务控制，尤其是服务层处理订单这种多表写入时，事务直接从框架层解决，不用自己写手动提交回滚。
• SpringMVC把请求路由、参数绑定、异常处理统一起来，REST接口写起来干净。
• MyBatis动态SQL非常适合药品列表这种多条件组合查询，关键词、分类、价格区间、上下架状态可以自由拼接。
• Vue用组件化方式组织页面，配合Element UI做后台管理界面，比传统模板引擎写出来的交互层清晰很多，构建后只是静态资源，后端不关心前端模板逻辑。

这个组合最大的好处是学习成本适中。市面上能找到大量SSM整合资料，答疑社区成熟；同时它保留了从JSP/Servlet时代过渡到SpringBoot时代的关键概念，理解了SSM再去看微服务或者SpringBoot并不突兀。如果直接用SpringBoot，固然开发更快，但很多事务、拦截器、配置管理的底层逻辑反而会隐藏起来，答辩时容易被问住。

1.3 项目交付物之间的关系

标题里包含了论文和搭建视频，这也符合很多高校的毕业设计交付要求。代码是“做什么”，论文是“为什么这么做”，视频则承担“怎么跑起来”的沟通作用。我见过不少人把三者割裂开，代码写完了才去补论文，视频录制时系统起不来直接翻车。正确的顺序应该是：先定需求范围和验收标准，再做数据库设计，然后代码实现，同时记录关键截图和运行过程，论文素材自然就积累了。这个顺序后面几个部分会细说。

2. 系统设计：角色划分、功能模块与数据库建模

2.1 角色与权限模型

网上药店系统的角色可以分为三类：游客、普通用户、系统管理员。游客只能看药品和搜索，普通用户在前者基础上能加购物车、下订单、管理收货信息和查看个人订单，管理员进入后台维护药品、处理订单和查看统计报表。

权限模型不需要做得太重，基于拦截器加用户类型即可。比较稳妥的做法是后端定义两个接口前缀：/user/**和/admin/**，登录成功后把用户角色写进token，每次请求带过来。拦截器负责校验token存在并且角色匹配，不匹配直接返回401。前端再用路由守卫处理页面跳转，例如没有登录不能进购物车页面，非管理员不能访问后台路由。前后端双重校验才是完整的权限控制，只靠前端隐藏按钮是没有安全可言的。

2.2 功能模块拆解

很多人在功能设计阶段容易漏掉一个细节：普通用户和管理员对“订单”的视角完全不同。用户看到的是自己提交的订单，管理员看到的是全部订单；用户的动作是支付和取消，管理员的动作是发货和完成。所以订单列表接口必须按角色区分查询条件，不能做成一个通用接口然后前端自己过滤，否则就是数据越权事故。

2.3 数据库表设计与核心字段

数据库是这个项目的命脉，表设计直接决定后面写代码是舒服还是难受。下面给出一个经过验证的核心表集合，字段名可以按自己习惯调整，但思路是一致的。

用户表：id、username、password、phone、role、status、create_time。

药品表：id、name、category_id、description、price、stock、cover_image、is_prescription、status、sales_count、create_time。这里的is_prescription是很多新手会漏掉的字段，网上药店通常需要区分处方药和非处方药。如果项目要求上传处方单，还需要预留一个处方图片字段或者单独的表。

购物车表：id、user_id、drug_id、quantity、checked、create_time。购物车是一个独立实体，不要在用户表里塞一个“购物车内容”的字符串字段，后续修改数量、结算勾选都要逐行操作。

订单表：id、order_no、user_id、total_amount、status、pay_time、deliver_time、finish_time、consignee_info、create_time。这里order_no用唯一业务流水号，尽量不用自增主键，方便用户查询和日志追踪。

订单项表：id、order_id、drug_id、drug_name、price、quantity、subtotal。把药品名称、价格快照写进订单项非常关键，因为药品价格可能会调整，如果订单总金额直接引用药品表的当前价格，历史订单就会跟着变，这在财务上是不可接受的。

表与表的关系要画清楚：用户对订单是一对多，订单对订单项是一对多，药品对订单项是多对一。为了查询方便，订单表里冗余了consignee_info，这是一种“读时友好”的设计，虽然有一定冗余，但业务上合理。

2.4 状态字段的设计经验

状态字段建议用int类型而不是字符串，然后在代码里建常量类统一管理。例如订单状态定义为：0待支付、1已支付、2已发货、3已完成、4已取消。定义常量类的好处是避免字符串散落在代码里。更严格一点可以做成状态机，限制只有合法状态转换才能执行，比如待支付才能取消或支付，已支付才能发货。答辩时把状态机逻辑讲清楚，项目档次会明显提高。

3. 后端核心实现：鉴权、检索、购物车与订单事务

3.1 登录与JWT鉴权

登录流程说简单也简单，说复杂也复杂。简单实现是前端传用户名密码，后端比对数据库，成功就返回一个token。复杂在于密码不能明文存储，token要能验证身份，拦截器要排除登录注册等公开接口。

我建议使用JWT做登录令牌，原因很简单：无状态、方便前后端分离部署。生成token时把用户id和角色放进去，设置合理过期时间。后端拦截器里解析token，从request.getHeader("Authorization")中取出token字符串。需要注意token前缀“Bearer ”的处理，否则很容易出现奇怪的解析报错。

伪代码示意：

String token = request.getHeader("Authorization"); String jwt = token.replace("Bearer ", ""); Claims claims = JwtUtil.parseToken(jwt); Integer userId = claims.get("userId", Integer.class); request.setAttribute("userId", userId);

登录接口本身还需要处理验证码、连续输错锁定、密码加密等问题。密码使用BCrypt加密，不要用MD5。MD5虽然快，但彩虹表查询几乎是公开资源，BCrypt自带随机盐，安全性可靠很多。

3.2 药品多条件检索与分页

药品列表页面往往是用户体验的重头戏。用户可能同时选择分类为“感冒用药”、关键词输入“胶囊”、价格区间20到50元，还要求只看有货。这个需求在后端不能用固定SQL写死，必须用MyBatis动态SQL。

<select id="pageList" resultType="com.example.entity.Drug"> select * from drug <where> <if test="keyword != null and keyword != ''"> and (name like concat('%', #{keyword}, '%') or description like concat('%', #{keyword}, '%')) </if> <if test="categoryId != null"> and category_id = #{categoryId} </if> <if test="minPrice != null"> and price &gt;= #{minPrice} </if> <if test="maxPrice != null"> and price &lt;= #{maxPrice} </if> <if test="onlyInStock"> and stock &gt; 0 </if> and status = 1 </where> order by id desc </select>

这里有个安全细节：like查询一定要用concat而不是直接字符串拼接，否则会产生SQL注入。#{}是预编译参数占位符，${}才是直接拼接，动态SQL里只应该用#{}。分页用PageHelper插件非常顺手，但要注意它是通过拦截器在SQL后面拼接limit实现的，所以插件版本和数据库方言要匹配，MySQL和Oracle写法不同。

3.3 购物车与订单提交的事务一致性

购物车模块很容易出现“看起来能用，但多人并发下单库存错乱”的隐患。先看一下正常流程：用户从购物车勾选药品，提交订单时后端要读取购物车信息、计算总价、扣减库存、生成订单、生成订单项、清空购物车。这一串操作跨多张表，必须在一个数据库事务里完成，否则一旦中间异常，就会出现订单创建了但库存没扣，或者库存扣了但购物车没清空的情况。

在Spring里，只要在Service方法上加@Transactional就能管理事务。但事务不是万能的，它解决的是“整体成功或整体失败”，解决不了“库存超卖”。假设药品库存只剩1件，两个用户同时下单，各自读到库存为1，都通过了库存校验，然后都执行扣减，最后库存可能变成-1。要解决这个问题，要么在扣减库存时加乐观锁控制版本号，要么直接用数据库的原子更新：

update drug set stock = stock - 1 where id = #{drugId} and stock >= 1

这种写法把“检查库存再扣减”压缩成一条原子SQL，天然避免并发脏读。业务上不是所有场景都要这么高的并发要求，但订单库存属于核心链路，值得认真处理。

订单提交接口的完整动作可以这样设计：

1. 从请求中取出选中的购物车id列表。
2. 查询购物车并关联药品表，校验药品还在上架状态。
3. 计算总金额，生成唯一订单号。
4. 逐条扣减库存，此时必须使用带条件的update语句。
5. 批量插入订单项，插入主订单。
6. 删除对应的购物车记录。

第4步如果失败应该抛出异常，让整个事务回滚。这里还有一个小坑：如果购物车里同一药品有多条记录，需要合并数量后再扣减库存，避免重复扣减。

3.4 模拟支付与订单状态流转

网上药店项目的支付不会接真实支付渠道，一般做成模拟支付。最常见的实现是点击“立即支付”按钮后，前端调用后端支付接口，后端校验订单属于当前用户、订单状态为待支付，直接把订单状态改为已支付，并记录支付时间。

虽然只是改一个状态，但也要有意识地做接口幂等。也就是说，如果网络抖动导致支付请求重复提交，后端不能让订单状态从“已支付”再变一次“已支付”，或者重复扣减什么。可以用“状态条件更新”来解决：

int rows = orderMapper.updateStatus( orderNo, oldStatus, newStatus, userId ); if (rows == 0) { throw new BusinessException("订单状态异常，请刷新后再试"); }

状态流转必须从前端到后端统一约束。前端可以根据状态显示不同按钮，但后端必须再次校验，因为接口是可以直接被外部调用的。这个思路在答辩时可以重点强调，面试官最看重边界场景考虑。

4. Vue前端设计：组件化、请求封装与权限控制

4.1 前端工程化的基础结构

如果用Vue2 + Element UI，推荐基于Vue CLI创建项目；如果用Vue3，可以选Vite。两种方案都不复杂，重点是目录结构要清晰。我习惯把项目分成api、router、store、views、components几个目录。

api目录单独存放后端接口调用，每个模块一个文件，比如drug.js、order.js。这样做的好处是页面组件里不直接写axios，将来后端接口调整时只需要改一个文件，维护成本低。请求封装里还应该统一处理token注入和错误提示。

import axios from 'axios' import router from '@/router' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code !== 0) { // 这里可以统一处理业务错误码 return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } return Promise.reject(error) } )

这段代码里最实用的一点是统一401处理。用户token过期后任何接口都会返回401，如果不统一拦截，每个页面都要自己写跳转，会非常痛苦。

4.2 页面组件拆分

门户端核心页面有：首页药品列表、药品分类筛选、药品详情、购物车、确认订单、订单列表、登录注册。后台管理端有药品管理表格、分类管理、订单管理、统计看板。

写前端页面时一个常见误区是把所有逻辑堆在页面里。更好的做法是把可复用的业务逻辑抽成组件或mixin，例如药品卡片、数量选择器、分页条。

药品列表和后台管理表格如果都用Element UI的el-table，可以少写很多CSS。但要注意表格的列渲染不要过度嵌套，多级循环会让Vue diff成本变高，页面明显卡顿。比如药品标签数组渲染，尽量用函数计算一次性返回结果，而不是在模板里写复杂表达式。

4.3 路由守卫与动态菜单

权限控制前端部分主要依托路由守卫和菜单渲染。在router/index.js里配置路由时给页面添加meta字段，比如requiresAuth: true、role: 'admin'。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') return } const role = localStorage.getItem('role') if (to.meta.role && to.meta.role !== role) { next('/403') return } next() })

也就是说，前端路由守卫保证页面入口安全，后端拦截器保证接口数据安全，两者配合才是完整的权限方案。如果只做前端守卫，用户可以通过直接调用接口操作管理端数据；如果只做后端拦截，用户会看到按钮后点击跳转才发现没权限，体验很差。

5. 毕业论文写作：从需求分析到测试用例

5.1 论文结构框架

许多同学代码写得不错，但论文被导师打回，原因通常是逻辑混乱、缺少数据支撑。网上药店系统的论文一般参考下列结构：

• 摘要：说清楚系统背景、技术路线、完成的功能模块以及设计目标。
• 第一章 绪论：编写项目背景与意义、国内外研究现状、主要工作。
• 第二章 相关技术介绍：说明Java、Spring、SpringMVC、MyBatis、Vue、MySQL，不要只贴简介，要说明为什么选这些技术。
• 第三章 需求分析：画总体需求、功能需求、非功能需求、可行性分析。
• 第四章 系统设计：架构设计、功能模块设计、数据库设计、接口设计。
• 第五章 系统实现：核心功能页面截图、代码逻辑说明、实现效果。
• 第六章 系统测试：测试环境、测试用例、测试结果、结论。
• 第七章 总结与展望：总结工作，指出不足。

这里最容易被忽略的是“非功能需求”。很多人的论文只写功能需求，性能、安全性、可维护性一个字不提。网上药店系统至少有密码加密存储、权限校验、库存一致性这些非功能点，写进去不仅能凑字数，还能体现工程素养。

5.2 测试用例如何设计

测试部分不要造假，但也不需要把每一个按钮都抄一遍。建议按业务模块抽取“关键路径测试用例”。

测试用例表要放在论文里，同时保留原始截图。善良提醒一点：如果你在论文里写“系统经过测试稳定运行”，测试数据至少要用真实、可复现的步骤生成，不要凭空想象。

5.3 答辩常见追问应对

答辩老师通常不会从头看代码，而是抓着关键概念问。最常问的几个问题我列一下，并把回答思路放在括号里：

• 为什么用SSM而不用Spring Boot？（SSM更清楚地展示Spring Ioc、AOP、事务的底层机制，适合学习阶段掌握原理，同时方便分层维护。）
• 购物车和订单的数据一致性怎么保证？（事务+原子更新库存，讲清楚回滚场景。）
• 权限控制怎么实现的？（后端拦截器校验token角色，前端路由守卫控制页面访问。）
• 如果用户重复点击提交订单怎么办？（前端按钮置灰，后端通过幂等校验或状态机约束。）
• MySQL索引如何设计？（订单号唯一索引、用户id索引、药品分类索引，避免在模糊查询列上滥用索引。）

这五个问题答好了，答辩基本不会冷场。

6. 环境搭建、常见问题与避坑指南

6.1 后端环境配置细节

SSM项目最让人头疼的是配置文件。spring-mvc.xml、spring-mybatis.xml、web.xml三个文件相互关联，一个namespace写错就能卡半天。我建议第一步先跑一个最简单的“查询数据库当前时间”接口，确认Spring到MyBatis的链路通了，再往上加业务模块，这样排错范围会小很多。

Maven依赖冲突是个高频问题。比较典型的坑包括：fastjson版本过低导致JSON序列化报错、jackson和fastjson同时存在导致转换异常、javax.servlet-api的scope没有设置成provided导致部署冲突。建议把依赖版本统一用properties管理，尤其是Spring相关jar包必须版本一致，否则会出现NoSuchMethodError。

6.2 跨域问题的正确处理

前后端分离项目在本地开发时必然遇到跨域。最简单的方式是在后端写一个CORS过滤器，允许指定来源。开发环境也可以使用Vue的代理转发，把/api开头的请求转发到http://localhost:8080。注意代理配置只对开发服务器有效，打包成静态资源部署到Nginx后，跨域问题通常由Nginx转发解决。

如果发现前端请求能到后端但浏览器拦截了，检查响应头里是否包含Access-Control-Allow-Origin以及是否允许携带凭证。使用自定义token头时还要设置Access-Control-Allow-Headers包含Authorization，这是个常见遗漏点。

6.3 订单重复提交与超时问题

在实际运行中，用户可能会快速点击“提交订单”按钮很多次。即便前端按钮设置了loading，后端依然要做防重处理。这里推荐一个简单方案：在生成订单号时，结合用户id加时间戳加随机数生成，然后在订单表给order_no加唯一索引。如果同一用户同一毫秒重复提交，数据库会因唯一索引冲突拒绝第二条写入，事务回滚，从根源上防止重复订单。

另外还要处理“订单超时未支付”的场景。答辩项目一般不引入消息队列，简单实现可以是在订单查询时判断create_time距当前时间超过比如15分钟且状态为待支付，就显示“已过期”，或者通过定时任务把超时订单改成已取消。网上药店系统如果连支付超时都不处理，业务闭环就不完整，答辩时容易被追问。

6.4 数据库编码与初始化数据

部署到服务器后经常出现中文乱码，根源大多是MySQL连接参数没有设置characterEncoding=utf8，或者数据库本身编码不是utf8mb4。建议在连接URL里明确加上：

jdbc:mysql://localhost:3306/pharmacy?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

使用serverTimezone参数是因为新版MySQL驱动默认使用UTC，插入时间会和本地时间差8小时，这个坑也非常常见。初始化药品数据不要太少，至少准备几十条带真实分类的药品数据，方便演示搜索和分页效果。

7. 配套指导视频的录制思路与演示节奏

现在很多项目交付时包含指导搭建视频，视频不是录屏流水账，而是演示系统怎么从零跑起来。录制前建议先写一个脚本，按三步来：第一步是环境准备，Java、Maven、MySQL、Node都装好，版本号确认一致；第二步是导入数据库脚本、启动后端、启动前端；第三步是走一遍核心业务逻辑，包括注册登录、搜索药品、下单支付、后台发货。

录制过程中不要急，把关键配置圈出来截图注释。每做一个动作就口头说明，例如“这里导入的是数据库初始化脚本，里面包含药品分类和测试药品数据”。视频不需要长篇大论，控制在20到30分钟即可。注意操作时不要把本机IP、密码、个人信息录进去，统一用localhost，数据库密码用简单测试密码并提醒读者在真实环境替换。

我见过有的同学把几分钟就能走通的流程录成一个多小时，中间全是卡壳、试错、调试，这样的视频虽然真实，但观感太差。正确的做法是先把系统完整跑通一遍，再开录制工具，录制时只操作必要步骤。卡壳片段剪掉，保留能展示核心效果的部分就够了。

8. 复盘：把这个项目真正吃到自己的肚子里

最后说说我的实际体会。网上药店系统最好的学习方式不是“熟练背诵代码”，而是盯着几个关键问题反复问自己：如果不给购物车表，交易流程会变成什么样？如果不做事务，库存会出现什么数据？如果不用JWT，认证信息放在哪里？这些问题想明白了，你可以在任何类似的管理系统里迁移这套能力。

我做这类项目时习惯先画一张“异常清单”，列出用户可能做哪些异常操作，比如未登录直接访问购物车、重复提交订单、购买数量超过库存、管理端删除正在被订单引用的药品。每一类异常都在代码里给出明确提示或拦截。这张清单带来的好处是写论文时的功能分析、异常测试和答辩素材全都齐了。

如果你刚拿到这个题目，不用急着写代码。花两天时间把角色、表结构、状态流转画清楚，再花一周做后端，三天做前端，剩下时间写论文和录视频，节奏会稳很多。项目本身不复杂，但它是一块很好的磨刀石，把事务、权限、状态、打包部署这些工程概念真正落到代码里，比看多少教程都管用。