企业官网建设流程全解析

每年临近毕业季，总能看到一拨一拨同学抱着“电商管理系统”这类题目来找我，后面十有八九还跟着两个词：Spring Boot、Vue。看到这个组合，我第一反应是：稳了。不是说这套技术能包打天下，而是对一个既要写代码、又要写论文、还得能答辩的毕设来说，Spring Boot + Vue 确实是同类题目里面最不容易踩坑的一条路线。你要做的电商管理系统，不是淘宝那种高并发、强治理、营销玩法满天飞的平台，而是一个能把商品、订单、用户、购物车这些核心链路理清楚，能演示、能讲明白、能写进论文的项目。这篇内容就围绕它，把技术选型、数据库设计、后端/前端实现、论文写作和部署演示几条线一次性讲透。

1. 项目整体设计与技术选型

1.1 先搞清楚电商管理系统到底要管什么

“电商管理系统”这个题目听起来很大，但毕设不是大厂重构，核心是边界清晰。我见过不少同学一上来就规划秒杀、优惠券、积分、推荐系统，最后把自己写进泥潭里。毕设级别的系统，建议把范围锁定在下面几条核心业务链路上。

实际开发时不一定要五个全部做完，但你至少要保证“用户 - 商品 - 购物车 - 订单”这条链路是完整的。链路断了，论文的需求分析写不圆，演示也会底气不足。我建议先做这条主线，再把营销、统计这类功能作为可选项补充，不要一开始就铺大摊子。

1.2 技术选型：为什么一定是 Spring Boot + Vue

有人问：能不能用 SSM 或者 JSP？能，但没必要。Spring Boot 最核心的价值是自动装配，它把传统 SSH/SSM 里繁琐的 XML 配置变成了约定和经验，内嵌 Tomcat，一个 java -jar 就能跑起来。对毕设来说，这意味着你不需要花大量时间在“环境把项目跑起来”这种环节上，而是把精力留给业务逻辑和论文。

Vue 则解决了前后端分离中的交互效率问题。电商管理系统有大量表单、表格、弹窗、状态切换，用 Vue 的响应式数据和组件化开发，写起来比原生 DOM 操作舒服太多。现在 Vue 3 + Vite + Element Plus 已经是主流，Vue 2 资料虽多但已经进入维护期，新项目直接用 Vue 3 即可。

配套技术栈推荐：Spring Boot 2.7.18、MySQL 8、MyBatis（分页用 PageHelper）、Redis（可选，做 Token 控制和缓存）、JJWT、Vue 3、Vue Router、Pinia、Axios、Element Plus。这套组合成熟度高，网上资料齐全，遇到问题也容易查到解决方案。

1.3 项目整体架构与请求流转过程

整体采用前后端分离架构。前端工程和后端工程独立部署，前端负责页面渲染和用户交互，后端只提供 JSON 接口。本地开发时，前端通过 Vite 代理把 /api 开头的请求转发到后端 8080；生产环境可以用 Nginx 托管前端静态资源并反向代理到后端地址。

一次完整请求的流转大致是这样的：浏览器输入地址得到 Vue 页面，用户点击按钮后，Axios 携带 Token 发送请求，Nginx 或 Vite 把请求转发到 Spring Boot；请求先进入后端拦截器或过滤器做 Token 校验，然后到 Controller，再到 Service 层处理业务逻辑，Mapper 层访问 MySQL 完成数据读写，最后结果封装成统一结构返回前端。理解这个链路对你写论文里的架构图特别有帮助，只要把每一层对应的代码位置标出来，答辩老师基本挑不出毛病。

2. 核心业务与数据库设计

2.1 数据表怎么设计才算既好用又好讲

数据库设计是论文里的重头戏，也是后期开发的根基。我见过不少项目功能写得不错，但表结构一塌糊涂，订单金额用 double，下单状态靠一个字符串随便填，最后统计报表全是脏数据。电商管理系统的核心表可以这样规划。

用户表 sys_user：主键 id、用户名 username、密码 password、昵称 nickname、手机号 phone、角色 role、状态 status、创建时间 create_time、更新时间 update_time。密码字段建议用 BCrypt 加密，论文里也好解释安全设计。

商品表 goods_info：id、分类 category_id、商品名称 goods_name、价格 price、库存 stock、图片 pic_url、商品描述 description、状态 status（上架/下架）、create_time、update_time。价格字段必须用 decimal(10,2)，float 和 double 在金额计算中会出现精度丢失，这是论文里可以强调的细节。

订单表 orders：id、订单号 order_no、用户 user_id、订单总金额 total_amount、订单状态 status、收货人 receiver_name、联系电话 receiver_phone、收货地址 receiver_address、支付时间 pay_time、create_time、update_time。订单号不要用自增 id，建议用时间戳加随机数生成，例如 20250607123000123，线上排查方便，论文里也可以展开讲主键设计策略。

订单明细表 order_item：id、订单 order_id、商品 goods_id、商品名称 goods_name、单价 price、数量 quantity。这里的商品名称和单价需要冗余一份，因为订单生成后商品可能会改名或改价，订单里必须保留购买时的快照，否则历史订单对不上账。

购物车表 cart_item：id、用户 user_id、商品 goods_id、数量 quantity、勾选状态 checked、create_time、update_time。购物车不适合用临时存储，落表之后用户换设备也能看到，论文里能体现数据一致性思考。

地址表 shipping_address：id、用户 user_id、收货人、电话、省市区、详细地址、是否默认。地址和用户是多个地址对应一个用户，建表时不要做成一对一。

贴一段简化但可以直接用的建表 SQL 作为参考。

CREATE TABLE goods_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, category_id BIGINT NOT NULL, goods_name VARCHAR(100) NOT NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, pic_url VARCHAR(255), description TEXT, status TINYINT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_category (category_id) );

2.2 统一返回结构和接口规范

前后端分离项目里，接口返回格式必须统一。我习惯定义一个 Result，包含 code、message、data 三个字段。code 为 200 表示成功，401 表示未登录或 Token 过期，500 表示服务器异常。前端 Http 状态码和后端业务状态码不要混在一起，很多同学直接把 HTTP 500 当业务错误处理，结果是后端一报错前端就卡死，排查半天。

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.code = 200; r.message = "操作成功"; r.data = data; return r; } public static <T> Result<T> error(Integer code, String message) { Result<T> r = new Result<>(); r.code = code; r.message = message; return r; } }

接口路径建议统一以 /api 开头。用户模块：POST /api/user/register、POST /api/user/login、GET /api/user/info；商品模块：GET /api/goods/page 获取分页列表、POST /api/goods 新增、PUT /api/goods 修改、DELETE /api/goods/{id}；购物车模块：POST /api/cart/add、PUT /api/cart/{id}、DELETE /api/cart/{id}；订单模块：POST /api/order/create、GET /api/order/page、GET /api/order/{orderNo}。

分页接口统一使用 pageNum、pageSize 作为参数，keyword 作为可选搜索关键词，categoryId 作为可选过滤条件。返回结构建议是 data 里放 total、list、pageNum、pageSize，前端拿到后直接填充分页组件，不需要二次转换。

2.3 前端页面与后端接口的对应关系

开发管理后台时，页面和接口的对应关系越清晰，前后端并行开发的效率越高。可以先把对应表整理出来，这样论文里画功能结构图、写接口设计表都方便。

做这份映射表时建议动手画一下页面原型，不用很精细，纸笔或任意画图工具都行。页面确定后，接口字段就不会糊，后端开发时很清楚要返回哪些字段。

3. 后端关键实现与原理

3.1 Spring Boot 自动装配与项目初始化要弄清楚

Spring Boot 最常被问到的问题就是：为什么你不用配置 XML 就能启动一个 Web 项目？答案在 @SpringBootApplication 注解，它内部组合了 @EnableAutoConfiguration，Spring Boot 启动时会扫描 META-INF 下的自动配置类，根据 classpath 上有没有对应的依赖 Jar 来决定要不要创建对应 Bean。

以数据库为例：pom.xml 里有 mysql-connector-j、spring-boot-starter-jdbc 和 mybatis 相关依赖，自动配置类就会创建数据源和 SqlSessionFactory；你引入 spring-boot-starter-data-redis，RedisTemplate 就会自动装载。不过自动装配不等于不要配置文件，数据源地址、账号、密码还是要你在 application.yml 里写清楚。

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/shop_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true

这一段配置里，map-underscore-to-camel-case 特别重要。数据库字段是 create_time，Java 属性是 createTime，不开启这个配置，查询结果就映射不上。创建项目建议直接在 start.spring.io 上选择 Spring Boot 2.7.18、Java 8 或 11，依赖选 Web、MySQL、MyBatis、Redis，然后手动加 PageHelper 和 JWT 的依赖。为什么推荐 2.7.18？因为 3.x 版本把 javax 改成 jakarta，很多网上的参考代码放到 3.x 会直接报包不存在，对毕设来说没必要在这上面折腾。

3.2 JWT 用户认证与拦截器：不写 Session 的思路

电商管理系统需要控制某些接口只有登录用户能访问。传统做法是 Session，但前后端分离后 Session 的跨域和集群问题比较麻烦，JWT 是更轻的替代方案。

JWT 由 Header、Payload、Signature 三部分组成。用户登录成功后，后端用密钥生成一个 Token，有效期我一般设置 7 天，Token 里放 userId、username、role。前端把 Token 存在 localStorage，每次请求时放到请求头 Authorization 里。后端写一个 LoginInterceptor，继承 HandlerInterceptor，在 preHandle 里判断请求头是否带 Token，解析失败或过期直接返回 401。

关键点有两个。第一，JWT 本身无法主动失效，用户修改密码或后台封号后旧 Token 依然有效，如果论文里想把安全问题讲深一点，可以引入 Redis 做黑名单或把 token 版本存到 Redis，比较简单的做法是登录生成 Token 时把 tokenKey 存进 Redis，注销时删除它。第二，拦截器注册时要放行登录注册接口和预检请求。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token == null || !JwtUtil.verify(token)) { response.setStatus(401); return false; } Long userId = JwtUtil.getUserId(token); UserContext.set(userId); return true; } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }

配置拦截器时用 WebMvcConfigurer：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/user/login", "/api/user/register", "/api/goods/page"); } }

用 ThreadLocal 保存当前用户，Service 层就能随时拿到用户 id，不需要写死在接口参数里。每次请求结束要记得 clear，防止线程池复用导致串数据。

3.3 MyBatis 分页插件：商品列表到底怎么分页

商品列表必然分页。手写 limit 不难，但每次都要数一下 total，很烦。PageHelper 是 MyBatis 最常用的分页插件，它的核心原理是拦截器。调用 PageHelper.startPage(pageNum, pageSize) 后，它会从 ThreadLocal 取出分页参数，在当前线程执行的下一句 SQL 上自动拼接 limit 和 count 查询。

注意限制：startPage 后面必须紧跟第一条执行的 Mapper 方法，中间不能有别的 SQL 或逻辑，否则分页参数会污染到其它查询。我自己踩过这个坑，在 startPage 和 mapper 方法之间写了一个查询分类的语句，结果商品列表没分页，下一句反而被带上了 limit，数据全乱了。

具体的代码写法：

public PageResult<GoodsVO> pageGoods(int pageNum, int pageSize, String keyword, Long categoryId) { PageHelper.startPage(pageNum, pageSize); List<GoodsVO> list = goodsMapper.selectGoodsList(keyword, categoryId); PageInfo<GoodsVO> pageInfo = new PageInfo<>(list); PageResult<GoodsVO> result = new PageResult<>(); result.setTotal(pageInfo.getTotal()); result.setList(pageInfo.getList()); result.setPageNum(pageInfo.getPageNum()); result.setPageSize(pageInfo.getPageSize()); return result; }

PageHelper 的分页查询原理在论文里适合作为“关键技术”来写，因为你能把 ThreadLocal、动态代理、SQL 改写这些概念串起来，远比单纯写“我用了 PageHelper”有价值。如果不想用 PageHelper，也可以用 MyBatis-Plus 的分页插件，但 PageHelper 更轻量，已有的 Mapper XML 不用大改。

3.4 文件上传和 XSS 全局过滤器：安全细节不能省

商品图片和 PDF 说明书是上传功能最常见的场景。后端接收 MultipartFile，保存到本地磁盘或 MinIO，给前端返回 URL。注意文件类型校验不能只看前端后缀，也要在后端校验文件内容，尤其是 PDF 文件，不能只检查 Content-Type，更稳妥是用文件头字节判断，PDF 的 magic number 是 25 50 44 46。

文件上传的路径安全同样容易被低估。上传文件名一定不要直接用用户原始文件名保存，建议用 UUID 或时间戳重命名；原始文件名里可能带路径信息，保存时拼接磁盘路径，一旦出现 ../ 就可能写错目录。参考做法：文件名 = UUID + 原扩展名，保存目录按日期分目录，这样既避免重复，也便于后续维护。

XSS 攻击在后台管理系统中很容易出现。管理员在商品描述、公告内容里嵌入脚本，一旦展示给用户就有可能被浏览器执行。常见做法是写一个全局过滤器，包装请求对象，对 getParameter、getHeader、getInputStream 的内容做转义。

public class XssFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; chain.doFilter(new XssHttpServletRequestWrapper(req), response); } }

XssHttpServletRequestWrapper 继承 HttpServletRequestWrapper，重写 getParameter、getParameterValues、getHeader 等方法，把