企业官网建设流程全解析

1. 项目概述与题目解读

1.1 这个题目到底在做什么

如果你正在做毕业设计，或者帮别人评估课题难度，看到“基于Spring Boot的二手手机销售系统”这个名字，第一反应可能是：这不就是一个简单的电商系统嘛。但实际动手你会发现，这个题目比“学生管理系统”这类CRUD项目要值钱得多，也复杂得多。它要解决的是一条完整的二手手机交易链路：商品发布、审核、上下架、搜索筛选、下单支付（模拟）、订单状态流转、个人中心与评价，还牵扯到买卖两端不同的用户体系。

我当初拿到这个课题的时候，第一件事不是写代码，而是把题目里的关键词拆开逐个看：Spring Boot决定后端技术栈，二手手机决定了商品模型和业务规则（成色分级、新旧程度、序列号等），销售系统决定了必须有前台交易和后台管理两套界面。把这三个词吃透，项目骨架就已经在脑子里了。

1.2 适合谁参考、能解决什么问题

这套项目最适合三类人：一是计算机/软件工程专业的毕业生，需要一个业务完整度高、技术栈主流的课题来支撑论文和答辩；二是想转行全栈开发的初学者，这个项目从前端页面到后端接口到数据库设计非常齐全，能帮你把零散知识串成一条线；三是想快速给客户交付同类型系统的开发者，Spring Boot 版本选得好、代码结构清晰的话，改成“二手电脑销售系统”“闲置物品交易平台”成本很低。

它解决的核心问题也很明确：二手手机交易中的信任与管理难题。新机销售只需要管好库存和订单，二手手机却必须处理成色评估、卖家发布申请、平台审核、交易纠纷等环节。这些业务细节是论文里可以浓墨重彩去写的亮点，也是答辩时展示系统复杂度最有力的支撑。

2. 整体设计思路与技术选型逻辑

2.1 为什么选 Spring Boot 而不是别的

Spring Boot 在毕业设计里几乎是统治级的存在，原因很简单：它提供了快速起步的能力。你不需要像使用传统的 Spring MVC 那样手工配置一大堆 XML 文件，一个spring-boot-starter-web依赖就能把 Web 环境跑起来。再配合 MyBatis Plus 操作数据库、Spring Security 或 JWT 做认证，整个后端的开发重心就转移到业务代码上而不是配置细节上。对毕业生来说，这意味着你一个月之内就能把核心功能跑通，剩下时间可以打磨论文和准备答辩。

有人可能会问，用 SSM（Spring + Spring MVC + MyBatis）行不行？技术上当然可以，但框架集成成本高、配置繁琐，答辩时也很难讲出新意。现在用人单位普遍要求熟悉 Spring Boot，毕设选择它本身就是对你就业技能的一次预演。我在实际做的时候特意选的 Spring Boot 2.7.x 系列，而不是 3.x，原因是 3.x 基于 Jakarta EE 命名空间，很多教材和老版本依赖对不上，遇到问题的排查成本较高，而 2.7.x 生态最成熟、B站教程最多、遇到报错基本能搜到答案。

2.2 前后端分离还是一起开发

这里要做一个关键决策。传统毕设喜欢使用 Thymeleaf 模板引擎，前后端混在一起；我这次采用的是“前后端分离”方案：后端纯 API 接口，前端用 Vue 3 + Element Plus 单独工程。你不用问哪个一定好，但你要知道每个选择的成本和收益。

如果是纯模板引擎方案，你少学一门 Vue 技术栈，部署时也是一个包搞定，但页面的交互体验比较生硬，而且论文里的“系统设计”篇幅会显得单薄。前后端分离做法的好处是职责清晰：后端返回 JSON 数据，前端负责渲染与交互，答辩时可以讲 RESTful API 设计、跨域处理、JWT 无状态认证这些热门知识点。代价是你需要同时掌握 Vue 的工程化开发、构建打包、反向代理配置。我的建议是：如果你的前端基础较弱且时间只剩两三个星期，选择 Thymeleaf 方案是更稳妥的公关策略；如果时间充裕，务必选择前后端分离，这个决定本身就会成为论文中的一个创新点。

2.3 系统模块如何划分

整个系统划分成两个端：前台用户端和后台管理端。前台用户端包含注册登录、首页轮播、商品分类导航、商品关键字搜索、商品列表筛选（按价格区间、按成色、按品牌）、商品详情、加入购物车、立即购买、个人中心（我的订单、我的商品、我的收藏、收货地址、我的评价）、卖家中心（发布商品、管理商品、查看卖出订单）。后台管理端包含管理员登录、用户管理、商品审核、商品分类管理、订单管理、公告管理。

这个模块划分不是拍脑袋想出来的，而是从“二手交易角色”倒推的。二手手机交易有别于新机销售的、最有特色的环节就是商品发布和审核。普通用户想卖手机，必须先填写商品信息提交申请，管理员在后台确认无误后商品才会上架展示。这个流程是论文中可以展开讲的“业务流程设计”，同时也决定了前台必须有个“卖家中心”的概念，而不能像普通商城一样简单用“我的订单”概括所有操作。

3. 数据库设计与核心业务实现

3.1 表结构设计与关联关系

数据库设计直接决定系统能否撑起“完整业务销售系统”这个标题。我最终设计出来的核心表有这些：用户表（user）、商品表（goods）、商品图片表（goods_image）、商品分类表（category）、购物车表（cart）、订单表（orders）、订单明细表（order_item）、收货地址表（address）、收藏表（favorite）、公告表（notice）。

用户表是最基础的，包含username、password（MD5加密存储）、phone、email、avatar、role（USER/ADMIN）、status等字段。商品表字段则是业务特色的体现：goods_name、goods_desc、cover_image、price（用Decimal避免浮点误差）、original_price、category_id、quality（全新/99新/95新/9成新/有磨损）、brand、model、is_onsale、is_check、seller_id、sales_count等。这里特别说明一下quality字段，二手手机的价值差异主要体现在新旧程度，这个字段在前台搜索筛选时会作为关键维度出现。

订单表的设计也要花心思。二手交易不像普通商品只有一个状态维度，我设计了状态机流转：待付款（0）→ 待发货（1）→ 待收货（2）→ 已完成（3）→ 已取消（4），另外配一个退款状态字段。用户下单成功但是还没付款时，可以取消；付款之后卖家发货，买家确认收货后订单完成。订单编号我采用时间戳加随机数的组合生成，避免直接暴露自增主键。

3.2 后端代码分层思路

后端工程我严格控制了分层规范：controller层负责接收请求和参数校验，service层负责业务逻辑处理，mapper层负责与数据库交互，entity实体类与表一一对应，config层放配置类，common放统一返回结果类（封装了code/message/data结构）和全局异常处理器，util放 JWT 工具类、日期工具类等。

这里有个不少新手容易踩的坑：把业务逻辑写在 Controller 里，导致一个接口几百行，既难维护也说不出设计亮点。我在写商品发布的时候，把“判断用户是否登录 → 判断手机号是否认证 → 组装商品实体 → 保存商品图片 → 返回结果”这个流程完整放在 Service 中实现，Controller 只保留十行左右的调用代码。论文和答辩时就能讲清楚“MVC 三层架构”是如何落实到具体代码中的。

// 统一返回结果类的封装示例 @Data public class Result { private Integer code; private String message; private Object data; public static Result success(Object data) { Result result = new Result(); result.code = 200; result.message = "操作成功"; result.data = data; return result; } }

3.3 权限控制与登录状态管理

登录认证我采用的是 JWT（JSON Web Token）方案。用户拿账号密码请求登录接口，后端验证通过后签发一个有效期设为 24 小时的 Token 字符串返回给前端。前端把 Token 存在本地存储中，每次请求在请求头加上Authorization: Bearer <token>。后端写一个拦截器，对所有需要登录的接口校验 Token 是否存在且有效，并从中解析出用户 ID。

// JWT 工具类核心方法 public String generateToken(Integer userId, String username) { return Jwts.builder() .setSubject(username) .claim("userId", userId) .setExpiration(new Date(System.currentTimeMillis() + 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

使用 JWT 的好处是服务端不需要维护 Session，符合前后端分离场景下的无状态要求，同时在答辩时可以引出“为什么不用传统 Session”这个讨论点。需要留心的是，JWT 的密钥不能泄露，而且在用户修改密码时要考虑 Token 失效问题，我当时的处理是简单地将密钥在用户改密时进行版本号拼接校验，确保旧 Token 无法通过验证。

3.4 首页与商品搜索实现

首页需要展示轮播图、分类入口、最新上架商品、热卖商品。这些数据都是从后端接口动态获取的，前端通过 Axios 发起请求渲染。搜索功能使用 MyBatis Plus 的QueryWrapper实现动态查询，比如用户输入“iPhone 13”，系统按商品名称和描述模糊搜索，同时支持按品牌、成色、价格区间、排序字段（销量、价格、发布时间）进行多条件组合筛选。

public PageResult<GoodsVO> search(GoodsQuery query) { QueryWrapper<Goods> wrapper = new QueryWrapper<>(); if (StringUtils.hasText(query.getKeyword())) { wrapper.and(w -> w.like("goods_name", query.getKeyword()) .or().like("goods_desc", query.getKeyword())); } if (query.getCategoryId() != null) { wrapper.eq("category_id", query.getCategoryId()); } if (StringUtils.hasText(query.getQuality())) { wrapper.eq("quality", query.getQuality()); } if (query.getMinPrice() != null) { wrapper.ge("price", query.getMinPrice()); } if (query.getMaxPrice() != null) { wrapper.le("price", query.getMaxPrice()); } wrapper.eq("is_onsale", 1).eq("is_check", 1); wrapper.orderByDesc(query.getSort()); // 排序字段动态传入 return PageResult.ok(goodsMapper.selectPage(new Page<>(query.getPageNum(), query.getPageSize()), wrapper)); }

这里有一个值得公开的经验：二手商品搜索和普通搜索不一样，必须把“上架状态”和“审核状态”两个条件同时过滤掉。我在开发中一开始漏掉了is_check=1这个条件，结果后台未审核的商品直接出现在了前台页面上，这是个业务级事故，还好在自测阶段发现了。

4. 实操过程与关键环节实现

4.1 开发环境准备清单

在正式开始写代码前，先把环境统一好，可以减少大量无意义的报错。我的推荐配置如下：JDK 1.8（Spring Boot 2.7.x 最高支持到 JDK 17，但 1.8 最稳）、MySQL 8.0（注意字符集设置为 utf8mb4）、Maven 3.8+、IntelliJ IDEA 2023 或更新版本、Node.js 16+（运行 Vue 前端项目）、Postman 或 Apifox（调试后端接口）。

如果你是在校学生而且参与的是团队协作项目，建议统一通过 Git 管理代码，后端和前端分开仓库，.gitignore里排除target、node_modules等目录，这样远程调试或者给导师展示时，都能保证代码一拉下来就能跑。

4.2 创建 Spring Boot 工程的两种方式

创建初始工程有两种主流方式：一是访问 Spring Initializr 网站，在页面上勾选 Web、MyBatis、MySQL 驱动、Lombok 等依赖后生成压缩包，下载到本地解压后用 IDEA 打开；二是直接在 IDEA 里创建（New Project → Spring Initializr 或 Spring Boot 项目），IDEA 会帮你在图形界面里完成依赖选择和生成。

我建议用第二种方式，因为 IDEA 的界面中可以快速预览 Spring Boot 版本、Java 版本和依赖列表，生成的项目结构也更直观。需要注意一点：在依赖选择时不要直接选“Spring Boot Admin”、”Security“等重量级库，尤其 Security 的自动配置会默认拦截所有请求，新手往往绕不明白直接报 403 / 401 错误。我的做法是引入 JWT 工具库（jjwt）自行实现拦截器，安全控制更透明，也更好讲解。

工程生成后，修改application.yml，将数据源配置指向本地 MySQL：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/phone_sale?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: time-zone: Asia/Shanghai mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

4.3 前端页面搭建要点

前端我使用的是 Vue 3 + Vite + Element Plus 组合，页面用 Vue Router 做路由。开发阶段通过 Vite 的代理配置把/api前缀的请求转发到后端的 8080 端口，避免开发环境跨域问题。

// vite.config.js 关键配置 export default defineConfig({ plugins: [vue()], server: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } } })

页面数量上看上去很多，但很多页面的结构是类似的：比如商品列表页和后台的商品审核页都包含表格、筛选条件、分页组件。我的经验是先搭好一个带侧边栏和顶部导航的“整体布局组件”，再往不同的路由中填充内容组件，视觉统一，代码也容易维护。如果时间紧张，优先完成商品浏览、详情、购物车、订单这四条核心链路，再补新闻公告、个人资料等边缘模块。

4.4 远程调试的实战方法

远程调试对毕设项目来说，主要场景是老师或客户在另外一台电脑上看你的系统运行效果，而不是要求你把断点打在他的服务器上。我推荐两种实操方案，按需选择。

第一种是内网穿透方案。你把自己电脑上运行的前后端服务打包以后，通过内网穿透工具把本地 8080 端口映射到公网域名，对方通过手机或电脑浏览器直接访问公网地址即可。操作步骤如下：注册账号 → 下载客户端 → 执行映射 8080的命令行 → 得到一条类似https://xxx.tunnel的公网地址 → 把地址发给对方。这种方法适合演示和临时验收，稳定性和数据缓存都有限，不建议长期使用。

第二种是服务器部署方案。购买一台轻量云服务器（配置選1核2G即可），安装 JDK、MySQL、Nginx，把后端打成 jar 包通过java -jar运行，前端npm run build生成的dist目录交给 Nginx 托管，同时配置 Nginx 反向代理到后端的 8080 端口。做完这步，对方访问你的服务器公网 IP 就能看到系统，非常正式，也是论文中“系统部署”章节的最佳实战素材。

# 服务器上后端构建与启动 mvn clean package -DskipTests nohup java -jar phone-sale-server-1.0.jar > server.log 2>&1 & # Nginx 核心配置片段 location / { root /usr/local/phone-sale/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

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

5.1 数据库连接失败与解决思路

数据库连不上是出现频率最高的报错，典型提示包括Access denied for user 'root'@'localhost'、Communications link failure等。我总结的排查顺序是：第一步检查 MySQL 服务是否启动（Windows 下查看服务列表，Linux 下执行systemctl status mysql）；第二步检查用户名密码是否正确，特别要注意 MySQL 8 的默认账号权限问题；第三步在application.yml中留意serverTimezone和useSSL=false这两个参数，时间和 SSL 问题也会导致连接失败；最后看驱动版本是否匹配，MySQL 8 必须使用com.mysql.cj.jdbc.Driver，而 MySQL 5.7 使用com.mysql.jdbc.Driver更稳妥。

一个我亲身踩过的坑是：本机数据库密码有特殊字符（比如@），直接写在 YAML 文件里没有加引号，导致 Spring 解析配置时把后面的内容截断了。解决办法就是用英文引号将密码包裹起来，或者使用encrypt等加密配置方式。

5.2 跨域请求失败处理

后端接口写好了，前端请求却报No 'Access-Control-Allow-Origin' header is present，这种情况几乎必然出现在前后端分离开发中。解决办法分两类：如果是开发阶段，直接配置 Vite 代理转发即可，因为浏览器访问的是同源的 3000 端口；如果是生产环境，后端也要配置跨域使能。

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

同时要注意，如果后端使用了拦截器，OPTIONS预检请求不能直接被拦截器挡住。我的处理方式是在拦截器里直接放行OPTIONS请求，这样才能避免“明明配置了 CORS 却仍然跨域失败”的怪事。

5.3 前端页面数据不更新的问题

前端修改了数据后页面没变化，常见原因有三个：前端缓存、后端返回的数据结构不一致、路由跳转时没有重新拉取数据。我的排查套路是先用开发者工具 F12 打开 Network 面板看请求是否真的发出、返回的状态码和响应体是什么，如果请求没有发出去，大概率是 Axios 的拦截器里出错或路由守卫没放行；如果请求正常但页面没变，就是渲染层的问题，检查绑定的数据字段名是否对得上，或者是否用错了响应式变量（Vue 3 里使用reactive时要小心解构丢失响应性）。

在找问题的时候，利用后端打印 SQL 日志非常关键。我在 MyBatis Plus 配置里开启了控制台 SQL 输出，每一条请求对应的 SQL 语句和参数都直接打在日志里，两相对照，就能精准定位是哪一层的错误。

5.4 Spring Boot 版本太高引发的依赖陷阱

当前网络上的教程更新速度赶不上框架版本迭代，很多教程还在讲 Spring Boot 2.x，但学生新创建的项目已经默认拉到 3.3 甚至 3.4 版本。3.x 版本下使用javax.*包名的代码全部编译报错，因为已经迁移到jakarta.*；部分旧版插件和连接池也出现不兼容。我在教学中让学生踩坑之后形成的建议是：如果你对这个框架没有充分的排错经验，不要盲目追求最新版本，锁定 2.7.x 能让你把更多精力放在业务逻辑上。这批版本运行稳定，官方文档和第三方资料都齐备，和 MyBatis Plus 的兼容性也最好。

5.5 SQL 注入与数据合法性校验

别以为毕设项目就不用关心安全性，如果系统里有明显的安全漏洞，答辩现场被问住是非常难堪的。MyBatis Plus 的QueryWrapper已经大幅减少拼接 SQL 的可能行，但如果你自己写 XML 映射文件，务必使用#{}占位符接收参数，坚决避免${}直接拼接。前端传进来的数据后端也要做二次校验，例如下单时校验库存是否充足、购买数量是否大于零、价格字段是否为正数。我在 Controller 里使用@Valid注解配合实体类上的@NotBlank、@Min等约束注解统一做参数校验，很大程度上防止了脏数据流入业务层。

6. 论文撰写与答辩准备要点

6.1 论文目录与写作逻辑

毕业设计论文不是代码说明书的复制粘贴，它讲究“工程实现+理论支撑”。我建议的论文目录结构是：第一章引言（背景与意义、国内外研究现状、主要研究工作）、第二章相关技术介绍（Spring Boot、MyBatis Plus、Vue、MySQL、JWT）、第三章系统需求分析（可行性分析、功能需求分析、用例图、数据流图）、第四章系统设计（总体架构图、功能模块设计、数据库概念设计与物理设计）、第五章系统实现（核心功能模块的实现截图及关键代码说明）、第六章系统测试（测试用例设计、功能测试、性能测试、测试结果分析）、第七章总结与展望。

写作时要把握好“画图 + 截图 + 关键代码”的比例。我在第四章画了 E-R 图、用例图、系统架构图，在第五章每个核心功能都配了运行效果截图和一小段核心代码并加以解释，答辩老师翻到任何一页都能快速看到你的工作量和逻辑性。注意事项是图表要自己画，别直接复制网上的，确保与自己的表结构逻辑一致。

6.2 答辩常见问题应对

答辩时老师关心三个层面的问题：项目是不是你自己做的、核心业务流程是否清楚、技术亮点是否能讲明白。围绕这几个层面，提前准备好以下问题的答案：系统有哪些角色？每个角色有哪些权限？订单的状态是怎么流转的？商品审核是怎么实现的？为什么使用 JWT 而不是 Session？数据库表之间的关联关系是怎样的？如果用户量变大系统怎么优化（加缓存、加索引、分库分表）？

其中“订单状态流转”和“商品审核流程”几乎是必问题。回答时要能清晰说出从用户下单到付款到卖家发货再到买家确认收货的完整链路，并且能说出每个状态下用户可以执行的操作是什么、系统做了哪些数据变更。我建议画一张订单状态机图贴在论文里，答辩现场直接在稿纸上简单画一遍，分数印象会有明显加分。

6.3 后续扩展方向

如果你的论文需要体现一定的前瞻性，可以在总结与展望里提出几个简单可行的扩展点。比如引入 Redis 缓存热门商品和商品浏览量，降低数据库压力；接入支付宝沙箱支付，让支付流程更加真实；在商品推荐模块使用协同过滤算法，根据用户的浏览和购买记录做个性化推荐；把手机验机报告（如外观检测、功能检测）图片化展示，增强买家信任。这些方向不需要你真的实现，但能让答辩评委看到你对系统演进有思考，提问环节也会更友善。

7. 交付与远程调试的实战配合

7.1 交付物应该包含哪些内容

一个规范、可信的毕业设计交付包，不只是源码和论文那么简单。我习惯将交付物拆成几层：完整源码（含前后端工程、SQL 脚本文件、README 启动说明）、需求文档（如果有）、论文（Word 版含目录和图表）、答辩 PPT、演示视频（录屏展示核心流程）。这套打包方式也被很多同学验证过，答辩前给自己留一版“可一键启动”的环境，到时直接用本机演示比云服务器部署的稳定性和流畅度更高。

README. md必须写清楚这几件事：环境要求、数据库初始化步骤（如何执行init.sql）、后端启动方式、前端启动方式、默认账号密码（管理员和普通用户各一个）。我见过太多同学把源码发出去、别人拿到后根本跑不起来，就是因为没有写清楚启动步骤。这部分工作不到半小时就能完成，但能避免大量“怎么运行不了”的后续沟通成本。

7.2 远程调试沟通技巧

如果对方要求远程调试或远程讲解，不要直接甩给对方一个压缩包然后各看各的。我更推荐先约定一个统一的时间，通过腾讯会议或者钉钉共享屏幕的方式，控制在半小时内讲完核心流程：启动后端 → 启动前端 → 演示用户购物流程 → 演示管理员审核流程 → 演示卖家发布商品流程 → 如果时间充裕再展示关键技术代码。过程中注意把屏幕分辨率和字号调大，让对方看得清楚。

如果对方希望自己拿到源码后能本地跑起来，你可以提前把相关依赖导出一份requirements或者运行说明视频（比如录屏 8 分钟以内），让对方跟着操作，这样子远程出问题的概率会大幅降低。个人经验是，远程协助时最耗时间的往往不是代码造成的 bug，而是环境差异导致的编译问题，所以尽量让双方的基础环境保持一致（JDK 版本、Maven 仓库镜像、Node 版本），提前统一能省掉一大半沟通成本。

7.3 线上演示时的突发状况准备

演示环节最怕现场翻车。我自己的做法是：演示前先把后端接口的 SQL 日志关掉（一方面减少日志输出卡顿，另一方面避免泄露表结构），前端 Build 一把确保没有编译错误，浏览器清理缓存和外挂广告插件。准备一个测试账号、一个管理员账号，并且预先把一笔“待付款”订单和一笔“待发货”订单置入数据库，演示的时候直接点开这些订单展示状态流转，流程会顺畅得多。

另外一个经验是：尽量不要在演示现场现场下单支付，因为你需要等待跳转、支付成功回跳等步骤，任何一个环节网络波动都会拖慢节奏。预置好数据，让界面直接展示结果，比从头走一遍更稳妥。

8. 关于选题复用与二次开发的一些经验

8.1 如何把二手手机系统快速改成其他品类

这种“XX销售系统”的课题有很强的迁移性。把数据库里的category数据一换，图片一换，前端页面里关于“手机”的关键文案做下替换，“二手手机销售系统”就能很快变成一个“二手电脑销售系统”或“闲置数码交易平台”。我建议你在做代码的时候就把商品相关文案尽量通过常量或数据库配置来维护，而不是写死在页面里，这样后面复用的时候只改数据不改程序。

如果客户要求支持“卖家入驻审核”这类高级功能，本质上也只需在user表中增加一个seller_status字段，卖家中心入口根据该字段控制显示，管理员在后台可以把普通用户升级为卖家。这种小型功能扩展在大框架下非常容易实现，做一次后你会对“业务模型变化如何影响系统设计”有更真切的感受。

8.2 关于源码质量的坚持

很多同学交付的时候比较随意，类名直接用拼音，变量名用a、b、c，也没有注释。我真心建议不要在毕业设计中留下这种习惯。代码规范本身就是基本功，答辩老师翻到源码如果发现包名、类名混乱，哪怕功能全通，印象也会打折扣。我的习惯是统一用英文命名，类名首字母大写驼峰，方法名小写驼峰，常量全大写，关键业务方法写三到五行注释。这样不仅答辩体面，将来找工作写简历时也能直接把这个项目作为“个人编码规范意识”的例证。

8.3 从毕设项目到正式项目的距离

和真正的商用系统相比，这套毕设简化了支付环节、物流对接、消息推送、秒杀抢购等能力，但它的骨架和主流互联网项目的工程结构是一致的。你在掌握了这套系统的前后端联调、部署上线、权限控制、数据库设计后，再去看大厂的业务系统，会发现很多概念是相通的。把毕业设计当成一个“麻雀虽小五脏俱全”的练兵场，你完成的不仅仅是一个学分，而是从学生思维切换到工程思维的一次重要跳跃。

我在实际动手过程中最大的感受是：项目复杂度高低不是关键，关键是每一步业务逻辑能不能自圆其说。当你把二手手机商品审核流程、订单状态机、JWT 登录校验、前后端联调逐条吃透，并且能不经稿子就完整讲出来，这套系统的价值就已经超过了“毕业设计”这四个字本身。后续不管你是要扩展品类、接入真实支付，还是把它当作求职作品集里的一个亮点，你都会感谢当初在细节上多发的那份力。