企业官网建设流程全解析

简介：面向高校计算机相关专业毕业设计场景，这可是一套基于Spring Boot、Vue和MySQL构建的智能无人仓库管理项目完整资料。系统针对信息管理混乱、出错率高、劳动强度大等实际痛点，实现了货物出入库、补货申请、库存状态跟踪等业务功能，并采用前后端分离架构，方便在Idea或Eclipse中直接运行与调试，适合正在完成仓储类课题或希望学习主流框架整合的开发者使用。压缩包共包含347个文件，大小约30.95MB，其中82个Java文件对应后端业务逻辑，34个Vue文件构成前端管理界面，还有15个JS脚本用于交互处理，以及SQL数据库脚本、XML和YML配置文件、自动构建的bat脚本、演示视频和毕业论文文档，目录层次清晰，便于按模块检索与二次开发。目前已有126人学习或下载该资源。通过下载这份资料，读者可以获得完整可运行的源代码、数据库表结构、毕业论文以及操作视频，既能直接用于毕业设计答辩，也能据此快速掌握Spring Boot与Vue的整合流程和项目部署方式。

1. 智能无人仓库管理毕设：值得做，但别把它做成 CRUD 大礼包

仓库门口那本纸质台账、入库靠人肉记忆找空位、出库翻半天不知道先发哪批货——这套系统要解决的就是这三件事。基于 SpringBoot+Vue+MySQL 开发的智能无人仓库管理，本质是用 Web 技术栈把「入库登记、库位分配、出库核销、库存盘点、超期预警」串成一条无人值守的自动化流程，毕设里常见形态是「扫码或输入单号自助存取 + 管理后台看板」。它适合三类人：想用前后端分离项目证明工程能力的本科生、需要给管理系统加点业务深度的求职者、以及想搞懂 SpringBoot+Vue 全家桶从数据库到页面怎么才能跑通的新手。相比纯增删改查的系统，它的加分点在于「无人」两个字逼着你做业务流程编排和规则逻辑，本文按后端、前端、数据库、联调部署、避坑、答辩验证的顺序把完整落地路径讲清楚。

2. SpringBoot+Vue+MySQL 的组合为什么合适：先想清楚技术与业务的对应关系

2.1 三层各管什么：不是流行才用，是分工刚好

先看这套组合在无人仓库场景里的分工：MySQL 管货架、货物、出入库记录这些事实数据；SpringBoot 管业务规则和流程——谁有权限操作、入库放哪个库位、出库是否合规、库存够不够；Vue 管人与系统打交道的界面——仓库看板、出入库操作台、库存查询、权限管理。

选 SpringBoot 而不是 SSM，核心理由是两个：一是配置方式从 XML 变成注解+自动配置，写毕设代码的时间能省出三分之一，对一个人开发来说很关键；二是内嵌 Tomcat，打 jar 就能跑，答辩现场的部署环节不容易翻车。选 Vue 而不是 React，则是生态原因：Element UI 这类组件库把表格、表单、弹窗全备好了，仓库管理这类后台管理界面的开发速度会快很多，而且中文资料齐全，出了 bug 搜得到类似场景。

有一点必须提前想明白：所谓「无人」，在这个项目里意味着「自助式业务流程」而不是「高度人工智能」。具体落地是三件事：无人值守入库（扫码或输入编号后由系统自动分配库位）、无人值守出库（系统按先进先出规则给出应出批次）、库存自动预警（定时任务扫描超期或低库存数据）。业务规则清晰，程序逻辑就好写，答辩时也能讲得清楚。

2.2 把「无人」拆成三条可编码的业务规则

无人值守不能是口号，必须拆成系统能执行的规则。我的做法是定义三条核心规则，全部落到后端服务层，再在接口层面做校验兜底。

规则一：入库货物必须有「库位推荐」——系统按「品类分区优先、同区空位优先」的方式从数据库里筛选货架。新增货物时，先查品类分区表找到允许存放的货架集合，再按当前存量升序取空位最多的货架返回，前端操作员确认或由系统自动确定。

规则二：出库按「先进先出」核销——同一种货物有多批入库记录时，出库单默认锁定额度内最早入库的批次。这个规则必须在事务里做，否则并发出库时两个请求可能核销同一批货，库存数据直接乱掉。

规则三：权限与操作留痕——普通操作员只能做入库、出库、查询，不能改货架基础数据；所有出入库请求必须落记录表，提供「谁在什么时间做了什么操作」的审计数据。无人仓库的「无人」本质是靠流程纪律和审计兜底，不是靠摄像头和机器人。

这三条规则落完后，系统才具备「业务深度」：出库接口不再是一句简单的 SQL UPDATE，而是先查批次、算余量、再扣减、后写流水的一整套流程。这也是毕设答辩时最有话聊的部分。

2.3 不要做的部分：哪些现有选择其实没必要引入

常见做法是把系统做复杂：引入 Redis 缓存、RabbitMQ 消息队列、Spring Cloud 微服务。我建议全砍掉，理由与技术水平无关，与项目边界有关。

首先，单机部署的仓库管理系统，并发量在演示场景下就是个位数，MySQL 完全扛得住。Redis 缓存如果只是给库存查询加速，反而多一套序列化、缓存穿透的维护成本。其次，消息队列是分布式系统解耦用的，单人开发的单体项目引入它属于自己造复杂度；答辩老师追问「为什么用 MQ」时，你很难给出一个真实的业务理由。最后，微服务在这个规模下是纯负担：拆出三个服务就要处理服务间调用、分布式事务、统一配置，这些内容在毕设周期内做不透，做不透的模块上了台就是送分题。

技术选型的合理边界是：让每个引入的技术都有业务理由。SpringBoot 管流程编排、Vue 管交互、MySQL 管持久化、定时任务管预警，够了。

3. 后端与数据库：先设计表结构，再写事务与规则

3.1 五张主表的设计：仓库业务的核心实体与关键字段

数据库设计是这种管理系统的地基。我习惯先画业务实体图，再落建表语句；毕设论文里的数据库设计章节也应与建表语句一一对应，方便评委照图索骥。

整个无人仓库的核心数据表可以收敛为五张：用户表、货架表、货物表、入库记录表、出库记录表。关系如下：货架表与货物表是位置对应关系；货物表与出入库记录表是主档与流水的关系；用户表独立支撑权限控制。下面的建表语句可直接用于初始化：

-- 用户表：支撑登录与角色控制 CREATE TABLE `user` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', `password` VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码', `role` VARCHAR(20) NOT NULL DEFAULT 'OPERATOR' COMMENT 'ADMIN/OPERATOR', `real_name` VARCHAR(50) DEFAULT NULL COMMENT '姓名，留作审计字段', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 货架表：库位主体，状态字段决定是否可分配 CREATE TABLE `shelf` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `shelf_no` VARCHAR(20) NOT NULL UNIQUE COMMENT '货架编号，如A-01', `category` VARCHAR(30) NOT NULL COMMENT '允许存放的品类分区', `capacity` INT NOT NULL DEFAULT 100 COMMENT '最大容量', `current_count` INT NOT NULL DEFAULT 0 COMMENT '当前已放数量', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1可用 0停用', UNIQUE KEY `uk_shelf_category_no` (`category`, `shelf_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 货物表：库存主档，注意批次字段是出库核销的依据 CREATE TABLE `goods` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `goods_no` VARCHAR(30) NOT NULL UNIQUE COMMENT '货物编号', `name` VARCHAR(100) NOT NULL COMMENT '货物名称', `category` VARCHAR(30) NOT NULL COMMENT '品类，与货架分区对应', `batch_no` VARCHAR(50) NOT NULL COMMENT '入库批次号，先进先出依据', `quantity` INT NOT NULL DEFAULT 0 COMMENT '当前库存量', `shelf_id` INT DEFAULT NULL COMMENT '所在货架ID', `inbound_time` DATETIME NOT NULL COMMENT '入库时间', KEY `idx_category_batch` (`category`, `batch_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 出入库流水表：合并为一张操作记录表，简化审计逻辑 CREATE TABLE `inventory_log` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `type` TINYINT NOT NULL COMMENT '1入库 2出库', `goods_id` INT NOT NULL, `quantity` INT NOT NULL COMMENT '变动数量', `operator_id` INT NOT NULL COMMENT '操作人ID', `before_quantity` INT NOT NULL COMMENT '变动前库存，留痕字段', `after_quantity` INT NOT NULL COMMENT '变动后库存', `log_time` DATETIME DEFAULT CURRENT_TIMESTAMP, KEY `idx_goods_time` (`goods_id`, `log_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有一个毕设常见误区：货物表只存当前库存总量，没有批次维度。这会导致先进先出规则无法实现。上面的 goods 表把 batch_no 作为独立字段存放，同一货物多次入库时会出现多条记录，出库时按入库时间排序逐条扣减即可。库存流水表里同时记录变动前后的值，是审计和追溯的关键，字段不能省。

3.2 入库与出库的服务层实现：事务边界决定数据一致性

表设计完成后，看后端核心代码。入库和出库不是简单的 insert/update，必须放进同一个事务方法里，保证「加库存、更新货架、写流水」三件事要么全成、要么全败。

@Service @RequiredArgsConstructor public class InventoryService { private final GoodsMapper goodsMapper; private final ShelfMapper shelfMapper; private final InventoryLogMapper logMapper; /** * 入库：分配货架 + 写入货物批次 + 更新货架占用 + 写流水 * 事务由 Spring 注解控制，异常时回滚全部操作 */ @Transactional(rollbackFor = Exception.class) public void inbound(InboundRequest req, Long operatorId) { // 1. 找到可用的货架：同品类且未停用且未满 List<Shelf> candidates = shelfMapper.findAvailable(req.getCategory()); if (candidates.isEmpty()) { throw new BusinessException("该品类暂无可用货架"); } // 2. 推荐空位最多的货架：当前占用数最少优先 Shelf target = candidates.stream() .min(Comparator.comparingInt(Shelf::getCurrentCount)) .orElseThrow(() -> new BusinessException("货架分配失败")); // 3. 组装货物记录，批次号用时间戳+序号生成 Goods goods = new Goods(); goods.setGoodsNo(generateGoodsNo()); goods.setName(req.getName()); goods.setCategory(req.getCategory()); goods.setBatchNo(generateBatchNo()); goods.setQuantity(req.getQuantity()); goods.setShelfId(target.getId()); goods.setInboundTime(new Date()); goodsMapper.insert(goods); // 4. 更新货架当前占用数量 shelfMapper.increaseCount(target.getId(), req.getQuantity()); // 5. 写库存流水，存变动前后值 InventoryLog logRecord = new InventoryLog(); logRecord.setType(1); logRecord.setGoodsId(goods.getId()); logRecord.setQuantity(req.getQuantity()); logRecord.setOperatorId(operatorId); logRecord.setBeforeQuantity(0); logRecord.setAfterQuantity(req.getQuantity()); logMapper.insert(logRecord); } }

这段代码的关键是事务注解和货架分配策略。事务保证「插入货物后更新货架」时如果发生异常，两条数据都不会落库；货架推荐使用 Stream 的 min 找 current_count 最小的记录，正是 2.2 节「空位优先」规则的直译。generateBatchNo 一般用 yyyyMMddHHmmss + 三位随机数，保证同秒入库的货物能区分批次先后。

出库逻辑相对特殊：不能简单地扣总数，要逐批次扣。假设库里有三批 A 货物，入库日期分别是 6 月 1 日、6 月 10 日、6 月 15 日，出库 50 件时应先扣 6 月 1 日批次的库存，不够再顺延第二批。

@Transactional(rollbackFor = Exception.class) public void outbound(OutboundRequest req, Long operatorId) { // 1. 按先进先出取批次：同品类下入库时间正序 List<Goods> batches = goodsMapper.findByCategoryOrderByInboundTimeAsc(req.getCategory()); int remaining = req.getQuantity(); for (Goods batch : batches) { if (remaining <= 0) { break; } int deduct = Math.min(remaining, batch.getQuantity()); // 扣减当前批次库存 goodsMapper.decreaseQuantity(batch.getId(), deduct); // 写流水：记录每次批次扣减，入库时间最早的先扣 writeOutboundLog(batch, deduct, operatorId); remaining -= deduct; } if (remaining > 0) { throw new BusinessException("库存不足，仅能出库 " + (req.getQuantity() - remaining) + " 件"); } }

这段逻辑里有个隐蔽问题：如果批次列表里有一条记录 quantity 为 0（比如之前已经被并发出库扣完了），当前实现会直接把 0 作为可扣减数量处理，不影响结果但会多写一条无意义流水。更稳妥的做法是在查询时加WHERE quantity > 0条件过滤空批次，这也是性能无关但逻辑严谨度相关的细节，答辩时可以说出来加分。

3.3 定时预警与权限控制：把「智能」落到规则引擎和任务调度

「智能」这个点在实现上可以分为两个部分：一是库位推荐，已在上文落进代码；二是库存预警与超期处理。这里我用 Spring 自带的 @Scheduled 注解实现定时任务，不引入 Quartz 框架，因为系统只有一个任务维度——每天零点扫描库存数据。

@Component @RequiredArgsConstructor public class StockAlertTask { private final GoodsMapper goodsMapper; private final AlertRecordMapper alertMapper; /** * 每天 0 点执行：扫描低库存与超期批次 */ @Scheduled(cron = "0 0 0 * * ?") public void scanStockAlert() { // 1. 低库存预警：数量低于阈值的批次 List<Goods> lowStockList = goodsMapper.findBelowThreshold(20); lowStockList.forEach(g -> alertMapper.insert(g.getId(), "低库存", "当前库存 " + g.getQuantity() + " 低于阈值 20") ); // 2. 超期预警：入库超过 90 天的批次 Date thresholdDate = DateUtils.addDays(new Date(), -90); List<Goods> expiredList = goodsMapper.findBeforeDate(thresholdDate); expiredList.forEach(g -> alertMapper.insert(g.getId(), "超期", "入库时间超过 90 天") ); } }

定时任务写完后，别忘了在启动类上加 @EnableScheduling 注解，否则任务不会执行。这是排查时最容易漏的一步：代码写得没错，就是没扫描到启动开关。库存预警阈值 20 和超期天数 90 建议做成系统配置项存到数据库配置表，而不是硬编码在代码里；虽然实现时多一个查询步骤，但答辩时「可配置化」是个设计亮点。

4. 前端与交互：Vue 项目搭建到联调的完整路线

4.1 Vue 项目的目录与四个核心页面：先搭骨架再填组件

前端我用 Vue 2 + Element UI 这套成熟组合。项目创建用 Vue CLI 或 Vite 均可，目录组织建议按功能拆分，而不是按页面类型拆分：

src/ ├── api/ # 所有后端接口的 axios 封装 │ ├── inventory.js # 出入库相关接口 │ ├── shelf.js # 货架管理接口 │ └── user.js # 登录与用户接口 ├── router/ # 路由配置，含权限守卫 ├── store/ # Vuex，存用户信息和全局状态 ├── views/ │ ├── Dashboard.vue # 仓库总览看板 │ ├── Inbound.vue # 入库操作台 │ ├── Outbound.vue # 出库操作台 │ └── StockQuery.vue # 库存查询与入库记录 └── utils/ └── request.js # axios 实例与拦截器

四个核心页面覆盖了无人仓库的所有场景：Dashboard 展示货架占用率、库存总量和最近预警；Inbound 和 Outbound 是自助操作的入口，业务员扫码或输入货物编号即可；StockQuery 是查库存与流水的地方。看板页有一个高频交互——库位状态可视化：我用 Element UI 的 Table 组件加自定义 class 实现，货架当前占用率超过 80% 的行标红，低于 30% 标绿，让「空位在哪」一眼可见。

4.2 axios 请求封装与跨域配置：联调时的两个关键卡点

前后端联调第一个翻车点往往是跨域。Vue 开发服务器默认跑在 8080，SpringBoot 跑在 9090，两个端口不同，浏览器会拦截响应。前端侧的常见做法是用 Vite 或 webpack-dev-server 的代理把 /api 前缀转发到后端，绕开跨域；后端侧的兜底写法是配置 CORS 过滤器。

// src/utils/request.js axios 实例封装 import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const service = axios.create({ baseURL: '/api', // 开发环境走代理，生产环境走 Nginx 转发 timeout: 10000 // 10 秒超时，防止接口卡死无响应 }) // 请求拦截器：自动附带登录令牌 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 !== 200) { Message.error(res.msg || '请求失败') return Promise.reject(new Error(res.msg)) } return res }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } Message.error(error.message || '网络异常') return Promise.reject(error) } ) export default service

跨域与请求封装两者要配合：开发阶段用代理解决跨域，可以让 axios 的 baseURL 直接写成相对路径/api，部署时后端接口也不暴露真实地址，安全性和可维护性都好。后端 CORS 配置是兜底，我一般只在后端开发环境开启，上线前关掉。

拦截器里的 401 跳转很实用：登录过期时用户不再看到满屏报错，而是被自动送回登录页。这个细节对演示体验影响很大，答辩时不希望当场被评委看到红色报错弹窗。

4.3 出入库操作台的交互：如何让操作员在屏幕上三步完成存取

微信支付宝上操作，「扫码-确认-提交」三步走就是无人物流的交互标尺。出入库操作台也按这个节奏设计。

入库页面的流程是：操作员输入货物编号，前端自动带出名称和品类；系统调用货架推荐接口返回推荐库位；操作员核对数量后点「确认入库」。出库页面则复杂一点：输入货物编号后，前端先调库存查询接口，展示当前有哪些批次、每批多少件；再输入出库数量，前端做一次「可用总量」校验，避免提交后因库存不足被后端驳回。

关于出库交互有一个设计细节：后端返回批次列表后，前端不要把「先进先出」的批次顺序打乱展示。最常见的坑是按数量排序或按随意顺序渲染，操作员看到的第一行不是最早批次，就容易现场提问时答不上来。我一般让后端返回时就标好inbound_time，前端 Table 组件直接按时间升序排列，并在每行加「建议优先出库」的文字标识。

5. 从源码到演示：六个常见坑的排查记录

5.1 SpringBoot 版本与学生电脑的 JDK 不匹配，启动即失败

现象：mvn spring-boot:run 启动时报Unsupported class file major version，下载的源码包在本地就是起不来。

原因：SpringBoot 2.x 与 3.x 对 JDK 版本要求不同，3.x 强制要求 JDK 17+，而很多毕设环境还是 JDK 8。标题里没有写版本信息，所以拿到源码后第一件事是看 pom.xml 里的 parent 版本定义。

解决：pom.xml 里 spring-boot-starter-parent 版本是 2.7.x 就用 JDK 8 或 11；是 3.x 就装 JDK 17。强烈建议在 IDEA 里给项目单独指定 JDK 版本，不要改系统环境变量，免得影响其他项目。

5.2 MySQL 8 的时区与驱动问题

现象：后端启动失败，报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，或者连接能建立但中文乱码。

原因：MySQL 8 的默认时区与 JDBC 驱动不一致；连接串里没有指定 serverTimezone 和 characterEncoding。

解决：JDBC URL 写成统一格式：

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

allowPublicKeyRetrieval 参数是 MySQL 8 的专属坑，不加它有时会报 Public Key Retrieval is not allowed。这是我在多个环境里踩出来的固定组合，直接复制可用。

5.3 前端「代理失效」玄学：地址没改对，接口 404

现象：后端接口用 Postman 测试全通，前端页面请求却 404；浏览器 Network 面板里请求地址是http://localhost:8080/api/xxx。

原因：vue.config.js 里 devServer.proxy 的 target 配错或没触发。最常见的问题是 axios baseURL 写的是http://localhost:9090，这等于绕过了代理直接跨域请求；又或者代理只匹配/api，而实际请求路径是/inbound/list。

解决：前端所有请求统一以/api开头，代理配置写成：

// vue.config.js（Vue CLI 项目） module.exports = { devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:9090', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }

pathRewrite 的作用是把/api/inbound/list转发成/inbound/list，注意后端@RequestMapping的路径里不能带/api前缀，否则要多一层拼接。

5.4 定时任务不执行，翻了半天代码发现没开开关

现象：数据库里已经插入低于阈值的库存数据，但预警记录表一直为空；@Scheduled注解看起来没问题。

原因：Spring Boot 的定时任务默认是不启动的，必须在启动类加@EnableScheduling。这个开关藏在注解里，新手经常忘记。

解决：主类上加注解后重启即可。另外调试时把 cron 表达式改短一点验证执行逻辑，比如0 */1 * * * ?每分钟跑一次，验证完再改回每日执行。

5.5 打包后的 Vue 页面放进 SpringBoot 后白屏

现象：前端npm run build生成的 dist 目录拷进src/main/resources/static，启动后端后打开首页白屏，控制台报找不到 JS 文件。

原因：Vue Router 用的是 HTML5 history 模式时，刷新/inbound这类非根路径，后端没有对应路由，返回 404；另外静态资源路径是绝对路径，如果应用没部署在根路径下就会找不到。

解决：两个方案选一个。方案一是把 Vue Router 改为 hash 模式，URL 变成/#/inbound，刷新不会发请求；方案二是保持 history 模式，在后端写一个 fallback controller，把非/api的路径都转发到index.html。毕设演示建议直接用 hash 模式，少一个配置点。

5.6 演示现场数据库连接失败

现象：答辩或演示时打开系统，列表页全部空白，后端日志报Communications link failure。

原因：数据库服务没启动、端口被占用、或者账号密码与配置文件不一致。三个原因里前两个最常见。

解决：做一个「演示前检查三步走」：确认 MySQL 服务在任务管理器或net start里显示运行；用telnet 127.0.0.1 3306验证端口通不通；直接在后端日志中确认数据源连接成功再打开页面。强烈建议把这三个动作做成习惯，每次演示前固定执行，比你临时查半天日志靠谱得多。

6. 让答辩认出「好工程」：四条验证路径与一个加分技巧

系统跑通之后，下一步不是写论文，而是验证设计和寻找演示漏洞。我会按四条路径做验收，每一条都对应评委可能追问的设计点。

第一条路径是业务闭环验证：从空库状态出发，连续入库三种货物、再出库，检查货架占用数、库存流水、批次扣减顺序是否与预期一致。重点看先进先出：分别入库两批同品类货物后出库，看系统扣的是不是第一批。

第二条路径是异常路径验证：故意提交超出库存数量的出库，看提示是否友好；停用一个货架后再入库该品类，看系统是否跳过停用货架；用普通操作员账号尝试删除货架基础数据，看权限是否被拦截。这些异常场景才是「无人」系统最需要展示的价值点。

第三条路径是数据可视化验证：打开 Dashboard 看板，确认入库后货架占用率图表即时刷新，预警记录出现低库存条目。看板是评委对系统第一印象的来源，数据不同步会直接暴露前后端联调粗糙。

第四条路径是部署文档可复现验证：换一台干净电脑，按 README 从零部署，能独立走通就是合格的交付。一个隐藏加分技巧是：把部署过程录屏，答辩现场不能保证网络环境，但提前录好的启动演示可以规避环境风险。这里需要提醒一句，视频演示只能作为补充，现场启动成功始终是基本功。

把这几轮验证的坑补进论文和演示文稿，答辩时你讲的不再是「系统有什么功能」，而是「系统怎么保证不犯错」——这个视角的分水岭，会让评委认为你真的理解工程，而不是只会调代码。我把这个习惯保留到了工作以后：每上线一个模块，先按用户路径把异常场景全部走一遍，再谈新功能。希望帮到你。

本文还有配套的精品资源，点击获取