企业官网建设流程全解析

最近收到不少私信，都在问同一个题目的毕设项目——基于 Spring Boot 的无人机销售系统。问的人多了，我干脆把这套东西从需求拆分到部署上线完整梳理一遍，包括源码里哪些地方值得在答辩时展开讲、哪些地方是老师最爱问的、以及我实际跑项目时踩过哪些坑。如果你正在做这个题目，或者打算把它改写成自己的毕设，这篇文章可以直接当操作手册用。

这个项目说白了就是一个垂直品类的电商系统，核心链路是"用户逛商城 → 加购物车 → 下单支付 → 后台发货 → 确认收货"，再加上管理端的商品、分类、订单、用户管理。麻雀虽小，但 Spring Boot、MyBatis Plus、权限控制、文件上传、接口联调这些毕设高频考点全占齐了，做起来体量适中，非常适合作为 Java 方向的毕业设计选题。

1. 项目需求分析与整体设计思路

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

先别急着写代码，我们把需求捋清楚。无人机销售系统的本质是"垂直电商平台"，它和普通电商系统的区别只在于售卖的商品品类是无人机，因此会额外关注商品参数（比如续航、图传距离、机身重量、避障能力这些）。但从系统架构上看，该有的模块一个都不能少：前台用户操作、后台管理操作、订单状态流转、登录鉴权、数据统计。

很多同学拿到这种题目，第一反应是"我要做一个多牛的系统"，结果堆了一堆花里胡哨的功能，最后数据库表设计混乱、业务逻辑散成一团，答辩时被老师问两句就卡壳。我的建议是：先画业务流程图，把"谁在用这个系统""每个角色能做什么""核心业务状态如何流转"三件事想清楚，再动手建表写接口。

1.2 角色划分与功能边界

这个系统里有两类角色，分别是普通用户（前台）和管理员（后台）。

普通用户侧的功能可以概括为：注册登录、浏览商品列表、按分类筛选或按关键词搜索、查看商品详情、把商品加入购物车、修改购物车数量、批量结算下单、填写收货地址、模拟支付、查看我的订单列表、查看订单详情、确认收货，以及个人信息的查看与修改。

管理员侧的功能则是：后台登录、商品分类管理（增删改查）、商品管理（发布新商品、上下架、编辑库存与价格、上传商品图片、维护商品参数）、订单管理（查看所有订单、发货、查看订单详情）、用户管理（查看注册用户列表、禁用/启用账号）、轮播图管理、公告管理，以及基础的销售数据统计（订单量、销售额等）。

这里要特别提醒一点：管理端和用户端的功能边界一定要清晰。很多源码最大的问题就是接口权限没有做区分，普通用户调管理接口也能成功，这在答辩演示的时候一旦被问到就会很尴尬。后面我会讲到如何用拦截器或注解做接口级别的权限控制。

1.3 技术选型背后的核心权衡

这个项目后端采用 Spring Boot 2.x 搭配 MyBatis Plus 和 MySQL 5.7/8.0，前端则根据你拿到的源码版本不同，可能是 Thymeleaf 服务端渲染，也可能是前后端分离的 Vue + Element UI。两种方案我都跑过，说下实际感受。

如果用的是 Thymeleaf 模板方案，开发起来最省事，不需要额外启动前端工程，部署的时候打一个 jar 包就行。适合对前端不太熟悉、想集中精力写后端 Java 代码的同学。缺点是页面交互体验相对朴素，某些异步刷新需要借助 jQuery 手动拼 HTML。

如果是 Vue + Element UI 的分离方案，界面更加现代，前后端通过 RESTful API 交互，在答辩时也更有"工程化"的说服力。但缺点是你需要额外掌握 Node 环境、Vue 打包和跨域配置，部署时也要注意把前端 dist 目录通过 Nginx 或 Spring Boot 静态资源映射跑起来。两种方案没有绝对优劣，看你的时间精力和平时积累。我的建议是：如果你对前端不熟，选 Thymeleaf 版本，省下的时间多去完善后端业务逻辑和文档；如果你希望页面好看一点，选前后端分离版本。

2. 数据库设计与业务模型拆解

2.1 核心数据表结构与设计依据

数据库是整个项目的根基，表结构设计得好，后面的代码写起来就顺畅。以我跑过的这套系统为例，核心表有八张左右：用户表、商品分类表、商品表、购物车表、收货地址表、订单表、订单明细表、轮播图表。下面这几种表的设计思路很关键。

用户表除了常规的用户名、密码、昵称、手机号、邮箱之外，还要有角色标识字段（比如role或type，用 0 和 1 区分普通用户和管理员）。密码必须加密存储，别用明文。我见过很多毕设源码里密码就是明文存数据库的，这是大忌，老师看到印象分会大打折扣。比较稳妥的方案是使用 MD5 加盐或 BCrypt 加密。

商品表是整个系统里字段最多的表，除了商品名称、价格（注意价格用 decimal 类型，不要用 float/double，否则会有精度问题）、库存、销量、上下架状态、主图、详情图之外，还要预留商品参数描述字段。无人机商品的参数属性，比如最大起飞重量、续航时间、图传距离、镜头像素、避障类型等，建议用一个独立的商品参数表或者 JSON 字段来存储。如果毕设想做得更完整，可以建一张商品参数表，用商品 id 关联，这样在详情页展示规格参数时非常清晰。

订单表建议拆成主表和明细表，主表存订单号、下单用户、订单总金额、收货地址快照、订单状态、支付方式、创建时间、支付时间、发货时间；明细表存订单关联的商品 id、商品名称快照、商品单价快照、购买数量、小计金额。这里有个平时大家容易忽略的细节：订单明细里一定要冗余商品的名称和价格快照。因为商品的价格和名称会变，如果订单只关联商品 id，回头查历史订单时显示的却是现在的最新价格，业务上就出问题了。

2.2 订单状态流转设计

订单模块是电商系统的核心，也是答辩时最容易深究的业务场景。常见的状态设计是使用一个整数状态字段或字符串状态字段来标记，比如：待付款、待发货、待收货、已完成、已取消。在代码里建议用常量或枚举类统一管理，而不是在业务逻辑里到处写魔法数字。

完整的订单流转逻辑是这样：用户提交订单后创建订单记录，状态为待付款；执行支付操作后状态更新为待发货；后台管理员发货后状态更新为待收货；用户点击确认收货后状态更新为已完成。如果下单后一定时间内未支付，可以设计一个定时任务或延迟检查逻辑，把超时订单自动置为已取消。如果库存不足则直接提示下单失败，或者锁库存成功后订单取消时回滚库存。

我在实际改这套源码时，发现一个非常常见的 bug：下单时没有扣减库存，或者取消订单时没有把库存加回来。这两个逻辑必须对应好，否则跑几次就会发现"商品明明还在卖但库存已经不准了"。如果你是二次开发，建议把库存变动做成一个公共方法，在订单创建、订单取消、订单超时关闭三个地方统一调用，避免多处写 SQL 导致数据错乱。

2.3 数据关联关系与查询性能细节

表之间的外键关系在 MyBatis Plus 这个层面不需要物理去建，但设计上要保证逻辑关联清晰。订单表和用户表关联，订单明细表和订单表关联，购物车表和用户表、商品表关联。在用 MyBatis Plus 做联表查询时，建议使用自定义 SQL 或者@TableName+@TableField注解映射，不要迷信全自动 CRUD，复杂的统计查询该写 SQL 就写 SQL。

这里有一个性能小细节：订单列表页和商品列表页一定要做分页。MyBatis Plus 自带Page分页插件，用法非常简单。我用PageHelper或 MP 内置分页都可以，但要注意分页插件的配置不要写错，否则会出现"查出来的数据全表扫描"或者"分页失效"的问题。实际演示时如果有几百条测试数据，不分页不一定会暴露问题，但代码审查时会显得不专业。

3. 登录鉴权与权限控制实现

3.1 会话保持与 Token 方案选择

权限控制这部分是 Spring Boot 电商系统里的重点。如果源码是前后端分离的，最常见的技术方案是使用 JWT（JSON Web Token）。用户登录成功后后端生成一个 token 返回给前端，前端之后每次请求都在请求头里带上这个 token，后端通过拦截器或过滤器解析 token 来识别当前登录用户。

如果源码是 Thymeleaf 服务端渲染模式，那么权限控制更多是依赖 Session。登录成功后将用户信息放入 Session，在需要权限校验的接口中获取 Session 中的用户，未登录则跳转到登录页或返回 JSON 提示。这个方案实现起来比较简单，但如果你打算在答辩时说"我的系统安全性很高"，建议还是升级成拦截器 + Token 的方案，显得有技术深度。

3.2 自定义拦截器实现登录校验

我用前后端分离的 Vue 版源码举个例子。项目里定义一个LoginInterceptor实现HandlerInterceptor接口，在preHandle方法里从请求头中获取 token。如果 token 为空，直接返回未登录的状态码或 JSON 内容；如果 token 解析成功，将用户信息存入ThreadLocal或 request 属性中，放行请求。关键是要把拦截器注册到 Spring MVC 的配置类里，并配置好放行路径。放行的路径通常包括：登录接口、注册接口、商品列表接口、商品详情接口、图片访问路径等。其余接口都需要登录后才能访问。

管理端的接口还需要额外校验角色。我的做法是在拦截器里不仅解析 token，还从 token 中取出用户角色字段，如果请求的路径是/admin/**且角色不是管理员，就返回 403 提示。虽然这套逻辑用@RequiresRoles之类的注解框架也能做，但毕设项目不推荐引入太多额外依赖，手写拦截器完全够用，而且答辩时可以讲得很清楚。

3.3 密码加密与安全细节

密码处理方面，我推荐使用 Spring Security 自带的BCryptPasswordEncoder，或者简单地用MD5 + 固定盐。无论如何不要明文存储用户密码。这一点我在前面提过，但这里单独拿出来说，因为它是很多毕设源码的通病，也是老师第一眼就可能挑出来的问题。

补充一个细节：前端提交登录密码时，可以先用 MD5 加密一次再传输，后端在已加密的字符串再加盐做二次加密存储。这样即使网络请求被拦截也不至于直接暴露明文密码。虽然毕设层面做到这个程度已经算优秀，但我还是会建议你把完整的加解密和校验链路写在论文的"系统安全设计"章节里，属于低投入高回报的加分项。

4. 核心业务模块的实现拆解

4.1 商品展示模块的关键细节

商品模块不太复杂，核心是商品列表、商品搜索和商品详情。商品列表接口建议支持多个查询条件组合：商品名称模糊查询、分类 id 精确匹配、上下架状态筛选、价格区间筛选、按销量或价格排序。MyBatis Plus 的LambdaQueryWrapper可以优雅地拼接这些动态条件。

商品图片上传是另一个值得讲的功能点。本地存储方案是：在application.yml里配置一个上传路径，比如D:/upload/（Windows 环境）或/home/upload/（Linux 环境），接收前端传来的 MultipartFile 后，用 UUID 拼接原文件后缀生成新的文件名，再保存到该路径。同时需要配置一个虚拟映射，让上传后的图片可以通过 URL 访问，比如/images/**映射到本地磁盘路径。如果不做这一步，刚上传的图片在页面里是无法显示的。

我在处理上传时踩过一个很典型的坑：本地开发没问题，但打包成 jar 后上传图片总是报路径找不到。原因是 jar 包内部的临时目录和代码里写的绝对路径不一致。解决方法是注入ResourceLoader来动态获取运行时项目路径，或者直接使用 Spring Boot 配置的静态资源路径。建议写代码时就考虑到 jar 部署场景，不要在方法里硬编码绝对路径。

4.2 购物车模块的实现思路

购物车常见的实现方式有两种。一种是纯前端方案，用户选中的商品存 localStorage，下单时才把购物车数据传到后端；另一种是后端方案，数据库中建购物车表，用户登录后购物车数据始终存在后端，换设备也能同步。毕设系统里，后端方案更符合题目要求，也更容易在答辩时展示数据库设计的合理性。

购物车表的核心字段包括：id、用户 id、商品 id、购买数量、加入时间。在查询购物车列表时，需要关联商品表查出当前最新价格和商品主图。在修改数量时要注意数量不能超过库存上限，数量和价格至少为 1 的商品才能进行结算。删除购物车条目时，要判断条目是否属于当前登录用户，防止串数据。

购物车里还有一个"选择结算"的功能。如果系统要做得精细一点，可以在购物车表里加一个checked字段标识是否选中。结算时只对选中的条目创建订单，然后批量删除已结算的购物车记录。但很多毕设源码直接简化成"全部结算"，也不算错，看你时间是否充裕。

4.3 订单生成与支付模拟

支付功能在毕设项目中通常不会对接真实的支付平台，一是申请商户号需要资质，二是涉及回调等流程太复杂。所以最常见的做法是"模拟支付"：用户点击"去支付"按钮，后端直接更新订单状态为待发货，同时在实际项目中可以记录一条支付流水，表示这笔订单已完成支付。在论文里要如实说明这是模拟支付，不影响系统整体逻辑。

订单生成时还有一个重要处理是事务。从购物车创建订单这个动作涉及多张表的写入，包括订单主表单条、订单明细多条、扣减商品库存、删除已购买商品的购物车记录。这些操作必须放在同一个事务里，任何一个步骤失败都要回滚，否则就会出现"订单创建了，库存却扣了两次"或"购物车清空了但订单没生成"的数据不一致。

我建议在 Service 层实现类上使用@Transactional(rollbackFor = Exception.class)注解，别漏了rollbackFor参数，否则遇到受检异常时事务可能不会回滚。为了验证事务是否生效，你可以故意在事务中间抛一个异常，看数据库里订单表有没有数据残留。这是答辩时可以当面演示给老师看的加分细节。

4.4 后台管理模块与数据统计

后台管理模块相对基础，基本都是围绕单张表的 CRUD 操作，但有几个点要强调。商品管理中的上下架操作本质是修改商品状态字段，切换后前台商品列表要实时反映。订单管理的核心操作是发货，发货时管理员可以选择填写物流单号。比较完整的系统还会提供订单筛选功能，按订单状态、下单时间段、用户手机号来筛选。

数据统计模块如果做得好，能极大提升项目的完整度和答辩效果。最简单的方式是在后台首页展示几个统计卡片：总用户数、商品总数、今日订单数、今日销售额。更进一步可以用 ECharts 柱状图展示近七天的销售趋势，或者统计分类商品的销量占比。数据来源使用 Group By 和聚合函数查询，分页不需要，但查询性能不必担心，数据量小完全够用。

5. 本地部署与运行实录

5.1 环境准备清单

在跑这个项目之前，先把环境装好，版本尽量保持一致。JDK 建议使用 1.8，Spring Boot 2.x 对 JDK 8 的支持最稳定。MySQL 使用 5.7 或 8.0 都可以，但要注意 8.0 的驱动配置和 5.7 略有区别，驱动类需要写com.mysql.cj.jdbc.Driver，URL 中最好加上serverTimezone=Asia/Shanghai和useUnicode=true&characterEncoding=utf-8，否则会报时区错误和中文乱码。

Maven 使用 3.6 或以上版本，IDEA 使用 2020 之后的版本都没问题。如果你是前后端分离的源码，还需要安装 Node.js 14+ 和 npm，用于前端依赖安装和打包。注意 Node 版本千万别装太新的（比如 20 以上的某些版本），部分老项目使用的依赖可能不兼容。

5.2 数据库初始化与配置项修改

拿到源码后第一步是找sql目录，里面通常是db_xxx.sql或者init.sql。用 Navicat 或命令行创建数据库后导入脚本。如果脚本里没有CREATE DATABASE语句，你需要先手动创建库，再选择该库执行 SQL。库名要和application.yml里配置的库名完全一致。

改配置时重点关注两个地方。一是数据库账号密码，确认username和password与本地环境一致。二是端口配置，默认是 8080，如果被占用可以改成 8081。如果你的源码是前后端分离的，还需要检查前端项目里request.js或api.js文件中的 baseURL，看它是请求/api还是直接请求http://localhost:8080，要保证和后端接口路径以及后端配置的上下文路径对得上。

5.3 前后端起项目的正确顺序

如果是分离版，顺序很重要。先在 IDEA 中启动后端，看到 Spring Boot 的启动日志，确认 Tomcat started on port 8080 之后再启动前端。前端进入项目目录，执行npm install安装依赖，这个过程可能需要几分钟，如果网络不好建议配置 npm 镜像源。安装完依赖后执行npm run serve启动开发模式，默认端口通常是 8081 或 5173。

前后端联调时最常见的错误是跨域。后端需要在配置类中加上跨域映射处理（CORS），或者前端通过 Vite / webpack 的 proxy 配置把请求转发到后端地址。我在实践中更喜欢用后端的 CORS 全局配置，一劳永逸。但要注意：如果定义了拦截器，跨域预检请求（OPTIONS）会被拦截器拦截掉，导致所有跨域请求都失败。解决方案是在拦截器里放行 OPTIONS 请求。

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

6.1 数据库连接启动失败解决思路

项目启动时报Access denied for user 'root'@'localhost'，基本就是数据库密码不对，检查application.yml中的密码。报Unknown database 'xxx'说明库名不匹配或数据库还没创建。报Public Key Retrieval is not allowed是 MySQL 8.0 的常见问题，在 JDBC URL 末尾追加allowPublicKeyRetrieval=true即可。

有一个比较隐蔽的坑是数据库驱动的版本。Spring Boot 2.4 以上版本默认引入的是 MySQL 8.x 驱动，如果你的数据库是 5.7，通常也能兼容，但有时会报 SSL 连接相关的警告。此时在 URL 上加useSSL=false就能消除。这些配置问题可以直接写进论文的"系统测试"章节，作为问题记录供参考。

6.2 前端页面 404 或接口 404 排查

接口 404 优先看后端控制台是否打印了异常信息，再看请求路径和后端 Controller 的 RequestMapping 是否完全匹配。一个很常见的坑是前端请求的是/api/user/login，后端 Controller 映射的是/user/login，而项目里又没有配置server.servlet.context-path=/api，导致路径对不上。检查方法是在浏览器调试面板里看 Network 请求的完整 URL，然后逐个比对。

前端页面 404 则可能是路由配置的问题。Vue 项目使用 history 路由时，刷新二级页面会直接 404，需要在部署环境中做 try_files 或 rewrite 配置。开发模式下因为 devtools 的 historyApiFallback 默认开启，通常不会触发这个问题，但打包部署后就特别明显。

6.3 图片上传成功但无法显示的处理办法

图片上传成功却显示不出来，九成是静态资源映射没配置好。Spring Boot 默认只把classpath:/static/作为静态资源目录，你上传到磁盘的图片并不在这个范围内。需要在配置类中重写addResourceHandlers方法，把/images/**映射到本地图片存储路径。

另一个容易踩的点是前端访问图片时用的是相对路径，比如<img src="/images/xxx.jpg">，但前端项目运行在 8081 端口，后端在 8080 端口，浏览器就会向 8081 端口请求图片，自然 404。解决办法是图片地址在后端接口返回时拼上完整的服务器地址，或者前端在请求图片时手动拼接后端域名前缀。

6.4 中文乱码的场景化解决方案

中文乱码通常出现在两个地方。一是后端读取前端传来的中文参数乱码，通常是因为编码不一致。Spring Boot 中在application.yml里配置server.servlet.encoding.force=true可以解决大部分 POST 和 GET 请求乱码。二是数据库存储乱码，需要确认数据库、表、字段的字符集是否都是 utf8mb4。导入 SQL 之后可以在数据库客户端里手动插一条中文数据，查询出来如果不乱码，基本就能排除数据库层面问题。

我之前遇到过一个比较特殊的乱码场景：单个接口返回中文正常，但某些接口返回的中文是问号。排查了很久才发现是接口中某段代码把字符串转成了 ISO-8859-1 编码。这种问题靠全局配置解决不了，需要定位代码中的转码逻辑。如果你也遇到类似的"个别接口乱码"，优先检查代码里有没有new String(bytes, "ISO-8859-1")这样的写法。

7. 二次开发建议与答辩准备技巧

7.1 如果想改造成自己的题目，从哪个模块入手

很多同学不想直接原封不动交源码，但也不知道从哪里下手改造。我的建议是不要改核心的订单与购物车流程，容易改出 bug，而是从商品属性层面入手。你手里的是无人机销售系统，如果改成其他垂直品类，比如数码配件、户外装备、宠物用品，核心电商逻辑完全不用动，只需要改商品表里的参数字段、页面上的文案、以及分类名称。改表的成本最低，工作量看起来又很大，答辩时能说清楚设计思路，是一个非常聪明的办法。

另一种改造思路是增加营销模块，比如优惠券、积分商城、限时秒杀。这些模块和现有系统是独立的，不会破坏原有业务逻辑。加一个优惠券模块，可以拆分成优惠券模板、用户领取记录、下单时选择可用优惠券并减免金额，涉及到的表和接口都不复杂，但写进论文里功能列表会丰富很多。

7.2 源码拿到手后先做的三件事

拿到源码第一步，不要着急启动，先花 15 分钟通读一遍README和目录结构，确定技术栈是模板渲染还是前后端分离、数据库脚本在哪、配置文件叫什么名字。第二步，检查pom.xml里的依赖是否正确，如果本地 Maven 仓库缺少某些依赖，IDEA 会自动下载，如果下载失败，检查镜像源配置。第三步，打开数据库设计文档或直接查看 SQL 脚本，快速了解表之间的关联关系，这能帮助你在修改功能时快速定位要改哪些地方。

7.3 答辩展示的节奏与核心话术

答辩时不要一上来就讲代码细节，而是先用两三分钟讲清楚业务流程：系统分前台和后台，前台用户注册登录后浏览商品、将商品加入购物车、下单模拟支付、确认收货；后台管理员管理商品分类、商品信息和订单发货。这个环节重点是展示你对业务的理解。

接下来演示核心功能，先演示用户端完整下单流程，再切换到后台演示发货流程，让老师看到两个角色之间的数据联动。此时可以顺便提一句"订单表通过状态字段维护订单生命周期，状态分别为待付款、待发货、待收货、已完成、已取消"，快速建立专业印象。

最后把项目亮点简单归纳：密码加密存储、拦截器统一鉴权、事务控制保证订单与库存的一致性、图片上传本地化存储。这几个点每一条都可以对应到项目的具体代码位置。老师如果深入追问，你心里要清楚每个亮点对应的关键类名。演示遇到问题不要慌，可以坦诚地说"这个场景我本地测试正常，可能是环境变量的问题"——大多数老师不会因此为难你，反而会觉得你有实际排错经验。

我个人在做这类毕设项目时有一个习惯：把每个核心模块的测试数据都准备好，包括一个完整的用户账号、一个管理员账号、几张带图片的商品数据、若干条不同状态的订单。这样无论演示当天的网络、环境出现什么意外，我都能在最短时间内把操作流程走完，把注意力集中在讲清楚设计思路上，而不是现场创建数据。这套"以演示流程为导向"的思路，也是我反复调试这套系统后觉得最值得分享的经验。希望这篇文章能让你少走几步弯路，把更多精力放在真正能提升技术理解的事情上。