毕业设计选题年年都有新花样，但“无人机+农业”这个方向是真的值得聊一聊。我见过不少同学选了这个“基于Spring Boot的无人机农田巡查系统”的题目，有的是自己从零开始写，有的是拿到现成源码后想真正搞明白每一行代码在干什么，还有的是为了调试运行、改功能焦头烂额。这篇文章我就从这个毕设项目的实际体量出发，把它的系统设计、核心实现、调试运行全流程和你捋一遍，顺便把那些常规文档不会写清楚的坑也一并交代出来。无论你是刚拿到题目还没头绪，还是已经在写代码的路上卡住了，这篇都能给你一个清晰的地图。
先说清楚这个系统解决了什么问题。传统农田巡查靠人工下地，耗时间、覆盖范围有限、数据也不够直观。无人机在天上飞一圈，拿到的正射影像、多光谱数据、疑似病虫害点位，如果全靠人眼去看、手动去记，那无人机带来的效率红利基本被损耗在数据处理环节。这套系统做的事情，就是把“无人机飞行”和“农田数据管理”串成一条完整的业务链路：从巡检任务的创建、航线规划，到无人机飞行数据与图像的上传存储，再到农田网格的影像标注、异常告警、统计分析，全部在一个平台上闭环管理。适合的人群也很明确：正在做Java毕业设计的学生、想快速上手Spring Boot前后端分离项目的开发者，以及对智慧农业方向感兴趣但不知道从哪里入手的人。
1. 系统整体设计与功能拆解：先看地图再走路
1.1 农田巡检业务里的核心角色与流程
一个合格的毕设项目，不能只是一个“能跑就行”的CRUD堆砌，而是要清楚自己到底在模拟哪条真实业务链路。无人机农田巡查系统围绕的核心角色主要有三类：系统管理员、巡飞操作员（或叫飞手）、数据查看人员（如农技员或管理者）。这三类角色在权限上天然分层，实际操作中飞手只负责执行巡飞任务和上传飞行数据，农技员则更关心影像数据的分析和告警结果，管理员负责基础数据维护和用户管理。
业务主流程可以概括成四个阶段。第一是基础数据准备，包括农田地块的录入、农田网格的划分、无人机设备型号和参数的维护；第二是巡检任务的创建与派发，操作员在系统里创建一次巡飞任务，指定农田区域、飞行高度、航线类型，并把任务与无人机设备绑定；第三是执行与数据回传，无人机按航线飞行后，拍摄的影像和传感器数据通过接口上传到系统，系统自动关联到对应的农田网格；第四是结果处理，系统对上传的数据做归档、展示、统计，并对超出阈值的异常数据（比如植被指数异常、疑似积水区域）生成告警记录。整个流程走完，系统才有完整的故事线，而不是一个个孤立的增删改查页面。
1.2 为什么是Spring Boot：技术选型的现实考量
很多同学在选技术栈的时候会纠结，为什么这个题目默认就是Spring Boot，而不是SSH（老Spring MVC + Hibernate那套），也不是Python Flask之类。原因很直接：Spring Boot在Java毕设领域已经事实上成为标准方案。它对第三方组件的自动配置能力极大缩短了项目搭建时间，内嵌的Tomcat让部署从“装服务器、配web.xml”变成了“直接打jar包跑起来”，这对毕设场景来说太友好了。
更关键的是，Spring Boot生态对后续扩展的支持非常完善。你接一个MySQL数据库，加一个MyBatis Plus依赖，配置一下数据源就能跑；你要做登录校验，Spring Security或者简单的JWT拦截器都有大量现成方案；你要做定时统计任务，Spring自带Scheduling注解就能搞定。我经常和学生说的一句话是：毕设选题里技术栈本身不构成创新点，但技术栈决定你把时间花在业务逻辑还是环境配置上。Spring Boot能让你把主要精力放在无人机巡检业务本身，而不是消耗在写配置文件上。
1.3 典型功能模块地图
整套系统按功能边界一般拆成六个模块，每个模块在毕设文档里都可以作为一个小章节去阐述。
用户与权限模块负责登录认证、角色管理、菜单权限分配。农田资源模块管理地块信息、网格划分、土壤类型和作物类型等基础档案。无人机设备模块记录设备型号、飞行参数、实时状态（可用/飞行中/维护中）。巡检任务模块是核心，涵盖任务的创建、审核、派发、执行状态跟踪。数据管理模块处理影像上传、文件存储、影像与网格的关联。统计分析模块则从任务完成率、异常数量、农田覆盖率等维度产出统计图表。
这个模块划分不是随便列的，它对应了你在答辩时经常会被问到的问题：“这个系统都有哪些功能？”“每个功能之间的数据关系是什么？”你把模块之间的依赖关系理清楚，答辩思路也就顺了。
2. 技术架构与分层设计：别让代码堆成一团乱麻
2.1 前后端分离的结构选择
当前主流毕设写法基本都是前后端分离，后端负责业务接口和数据处理，前端用Vue或原生页面消费这些接口。我建议不要为了省事做服务端渲染的老式单体，因为前后端分离不但更贴近实际生产环境，而且答辩时可以明确说出“前端通过HTTP接口与后端交互，使用JWT做无状态认证”，这一句话的专业感就出来了。
后端项目结构推荐按经典分层来组织：controller层接收请求和参数校验，service层写业务逻辑，mapper层（如果用MyBatis的话）做数据库持久化操作，entity层放数据库实体，dto/vo层做数据传输和视图模型转换。很多同学代码写乱，就是controller里直接塞了一大堆SQL和业务规则，后面加一个功能就要四处打补丁。
2.2 核心依赖与配置文件要点
一个典型的Spring Boot项目pom.xml里会包含spring-boot-starter-web、spring-boot-starter-validation、mybatis-plus-boot-starter、mysql-connector-java、lombok、jwt相关依赖。这里有几个细节值得注意。
MyBatis Plus的选择我很推荐，它把单表的增删改查封装到近乎无感，你不需要为每一个表写一套基础的Mapper方法，遇到复杂统计查询再写自定义SQL就行。这在毕设项目里能省下大量时间。JWT依赖建议用成熟的库，比如java-jwt，不要自己手写加密和过期校验逻辑，自己写的非常容易出安全漏洞，虽然毕设没有安全测试，但答辩老师追问到token的时效问题，你得能说明白。
application.yml里核心配置包括数据源配置、端口配置、JWT密钥和过期时间、文件上传大小限制、以及MyBatis Plus的逻辑删除和驼峰映射配置。第一次运行项目的人最容易在这里踩坑，数据库连接、账号密码对不上是起步阶段最高频的问题，后面会专门讲。
2.3 接口文档与统一返回结构
前端对接后端接口，最怕的是每个人定义的返回格式都不一样。我在项目里一般会定义一个统一响应类Result类型，结构固定为code、message、data三个字段。code为200表示成功，500表示服务器内部错误，业务异常可以自定义业务码。所有controller返回这个封装类型，前端就能用统一的拦截器处理响应，不需要每个接口单独解析。
再配合Swagger或者springdoc-openapi生成在线接口文档，前端开发或者答辩演示的时候直接打开页面就能看到每个接口的参数和返回值。这一步看起来简单，但很多学生忽略，导致后期联调效率极低。接口文档对毕设文档的附录部分也是加分项，截图放进去，整个项目的完整度直接拉满。
3. 数据库设计：农田巡检系统的数据骨架
3.1 表结构与字段设计的基本原则
数据库设计常常被同学们在一开始就敷衍过去，但恰恰这个巡检系统的表结构是有业务逻辑在里面的。核心表至少有八张：用户表、角色表、农田地块表、网格区块表、无人机设备表、巡检任务表、影像数据表、告警记录表。
设计的时候要遵循几个原则。第一，主键统一使用自增id或雪花id，不用UUID字符串做主键，性能和索引长度都会好一些。第二，所有表要带create_time和update_time字段，这是一条新手也必须养成的好习惯，数据出问题时排查有据可依。第三，多对多关系要建中间表，比如用户与角色就是典型的多对多，可以用user_role中间表维护。第四，状态字段用tinyint而不是varchar存储，比如任务状态0待执行、1执行中、2已完成、3已取消，不要直接写“待执行”“执行中”这种字符串，程序里定义枚举常量去关联，扩展性更好，也避免中文在不同环境下的编码问题。
3.2 巡检任务与影像数据的关联设计
巡检任务表和影像数据表是整个系统的两条主线。巡检任务表字段一般包括任务编号、关联地块id、关联无人机id、计划开始时间、实际执行时间、飞行高度、航线类型、任务状态、执行人员id。这里注意一个细节：任务编号用带业务含义的流水号会比自增id更适合展示，比如“XJ20250601001”，前端列表展示和检索都比纯数字更友好。
影像数据表相对更复杂一点，因为一张巡检任务可能对应多张影像，每张影像需要记录上传时间、存储路径、图片所属网格id、任务id，以及可选的影像分析指标字段，比如归一化植被指数估算值。影像和任务之间是一对多关系，和网格之间是多对一关系，这在表设计里要体现清楚。
为什么不直接把影像路径挂在任务表下面用逗号拼接？这个问题我在指导过程中反复强调过：第一，一张任务几十张图片，拼接字段会非常臃肿；第二，你需要单独按网格维度去检索影像记录时，拼接方案基本没法做。建一张独立的影像表，数据查询灵活度完全不一样。
3.3 冗余字段与查询性能的取舍
毕设项目数据量不大，但我会建议同学们在设计时还是考虑冗余字段的合理使用。比如巡检任务表里可以冗余存一个地块名称、设备型号名称，不必每次查询都去联表。这个思路在生产环境里叫“空间换时间”，在答辩时拿出来讲，能体现你对性能维度有思考。
另外一个值得说的是逻辑删除。MyBatis Plus的逻辑删除功能开启后，delete操作会转成update设置deleted字段为1，这让数据不至于物理消失，对毕设场景下的误操作恢复非常有价值。你只要在实体里加一个@TableLogic注解的字段即可。需要注意的是，凡是有业务唯一性约束的字段，逻辑删除会导致重复数据问题，比如用户账号删除后再次注册同名账号会被唯一索引挡住，这个问题在答辩前一定要自己测试一遍。
4. 核心功能实现：从接口到业务逻辑的落地细节
4.1 巡检任务的创建与状态机流转
巡检任务模块是系统里业务逻辑最完整的部分，也是答辩时容易出彩的地方。任务的创建接口入参包括地块id、无人机id、计划时间、航线参数等，后端要做三件核心事情：校验农田地块和设备是否处于可用状态；生成任务编号；初始化任务状态为待执行。
任务的状态流转建议用状态机思想来管理。一个任务从待执行开始，只能流转到执行中、已完成或者已取消，执行中之后是已完成。不要在代码里随意写法，让状态跳来跳去，比如已取消的任务不能直接跳成已完成。这种状态机的约束可以在service层用if判断实现，也可以用更清晰的状态枚举加一个流转校验方法来实现。在答辩时能讲清楚“为什么不允许已取消状态直接流转到已完成”，本身就是加分项。
我见过不少同学的实现里，任务状态字段随手改，前端页面和后端接口对状态的描述都对不上。我这个建议是：状态枚举类单独放一个包，所有状态名称和描述统一维护，前端需要的状态列表也通过一个枚举接口动态获取，前后端不硬编码。这样后期任何状态变更，只改一处代码。
4.2 航线规划模块的抽象与模拟
真实的无人机航线规划涉及地面站软件和复杂的飞行控制协议，毕设系统不太可能也不需要在代码里实现完整的航线算法。但完全不涉及航线又会让系统显得单薄。我的建议是做一个合理抽象：在任务创建时可以设置航线类型（如弓字形扫描、环绕巡视、定点悬停），并保存关键参数，如飞行高度、速度、航线间距、扫描覆盖面积等。
这些参数存到数据库后，系统可以基于简单数学模型计算预估覆盖范围和飞行时间。比如弓字形扫描预估航程可以用地块长度除以航线间距向上取整再乘以地块宽度来计算，这个结果可以在任务详情页展示为“预估覆盖面积”“预估飞行时间”。这样既不需要真的对接无人机，也让系统有了业务计算逻辑，而不是纯粹的数据登记系统。
如果项目组里有人熟悉前端地图开发，还可以在页面里做一个简易可视化：用Canvas或者Leaflet在地图上画出模拟航线轨迹，数据就是刚才的航线参数。视觉效果好，答辩演示时屏幕一放大，整个系统的专业感完全不一样。
4.3 影像数据上传与存储路径的设计
影像上传是整个系统对文件处理的关键点。建议采用本地存储配合数据库记录路径的方式，不要直接把图片以Base64字符串存入数据库。本地存储方案下，上传接口接收MultipartFile，后端做文件类型校验（只允许jpg、png等）、大小校验（比如单张不超过10MB）、按日期目录分文件夹存储，并把存储的相对路径写入影像数据表。
文件命名也值得统一规范，推荐格式是：任务编号_网格编号_时间戳.jpg，比如XJ20250601001_G01_20250601103025.jpg。这样即使脱离数据库，单看文件名也能知道这张图来自哪个任务和区域，调试和排查问题时极其方便。这个经验是我做了几个文件上传功能后总结出来的，简单一条命名规范就能省去大量痛苦。
另外要做访问映射。Spring Boot里可以配置静态资源映射，把本地磁盘的上传目录映射成一个虚拟路径，这样前端只需要拼URL就能直接显示图片。配置上注意上传目录的绝对路径不能写死，要在配置文件里维护，换机器部署时不用改代码。
4.4 异常告警与统计分析的实现思路
告警逻辑是这个系统的点睛之笔。可以有两种实现层次：简单一点的方案是上传影像时由操作人员手动选择异常类型（如疑似病虫害、疑似积水、长势较弱等），生成告警记录；复杂一点的方案是通过影像的指标数据（例如计算平均植被指数，对比区域历史基线）自动判定是否超过阈值。
毕设项目我一般建议先做第一种，但第二种可以在文档里作为扩展设计提出来。告警记录表需要记录告警任务、网格、类型、级别、处理状态。统计分析模块则以告警记录和任务记录为基础，按天、按周、按地块维度做统计。实现时主要靠MyBatis Plus的条件构造器，或者写几条group by的SQL查询，统计结果喂给前端图表组件（如ECharts）渲染。
这里特别提醒一点：统计SQL建议单独放在统计Mapper里，不要把统计逻辑和普通业务查询混在一起。统计SQL往往涉及多表关联和分组聚合，一旦和业务查询混用，一个小改动就可能牵动全局。分类放置之后，出问题定位更快，答辩时你也能清楚地说出“哪一类查询走哪个Mapper”。
5. 本地环境搭建与调试运行实录
5.1 从零开始把项目跑起来的完整步骤
很多同学拿到一套源码后第一件事不是看代码，而是急着启动，结果报错一大堆就慌。正确的启动流程应该是：先看README和数据库初始化脚本，再改配置，最后启动并逐个接口验证。
第一步是准备基础环境。JDK建议用1.8或11版本，不要用太新的版本比如17或21，因为很多毕业设计的依赖并不保证做好了高版本适配，碰到奇怪的反射报错会欲哭无泪。Maven使用3.6以上版本，IDE建议直接用IDEA社区版或旗舰版。MySQL用5.7或8.0都可以，但注意8.0以上的驱动配置要加时区参数serverTimezone=Asia/Shanghai，不加启动时大概率报连接串相关错误。
第二步初始化数据库。找到项目里的sql脚本，在Navicat或命令行里创建数据库，然后执行脚本。执行后检查表数量是否符合文档描述，常见的坑是脚本里有中文注释、执行时字符集不对导致乱码，或者脚本本身依赖了存储过程/视图而没开权限。执行完毕后随便打开几张表看看数据，确认基础数据已经录入。
第三步改配置。打开application.yml，把数据库地址、账号、密码换成你本机的。如果项目配置了Redis，本地没有装Redis就直接先停用这个依赖或配置，先把主要业务跑起来。很多项目会在配置里塞一个第三方服务的appKey之类，如果暂时用不到可以先置为占位符，不要因为这个卡住启动。
第四步启动项目。建议直接用IDEA的main方法启动，不要先打jar包。看到控制台打印启动成功日志后，先用浏览器访问Swagger或登录接口，确认后端活着。然后启动前端项目，如果是Vue项目，先npm install再npm run dev。如果依赖装得很慢，可以换国内镜像源，装完后启动。
5.2 前端联调中的几个关键细节
前端启动后第一件要处理的事就是跨域问题。生产环境前后端分离通常通过Nginx反向代理解决，但本地开发时最常见的方案是在后端配置CORS跨域放行。具体来说，在config层写一个CorsFilter或者使用@CrossOrigin注解，允许所有来源、所有请求头、所有方法。注意如果你加上了JWT认证拦截器，预请求OPTIONS要直接放行，否则前端每次请求都会被拦截器挡下来，页面表现为接口全部401或403，这个坑非常典型。
登录功能的联调也需要留意。前端登录成功后拿到token，之后的所有请求在请求拦截器里加上Authorization头。后端的拦截器里要解析这个token并获取用户信息。我建议用拦截器解析后把用户id放入ThreadLocal或者Request的attribute里，在controller里直接取出使用，不要在接口里让前端每次都传userId参数，这既不安全也不专业。很多同学图省事让前端传userId，这个细节在评审老师眼里非常掉档次。
5.3 真正验证一次“完整的业务闭环”
项目启动成功后不建议只是对着接口文档点一遍就以为完事了。强烈建议走一遍完整业务链路：登录系统，创建一个农田地块和无人机设备，创建巡检任务，上传模拟影像数据，查看影像在网格上的关联展示，生成告警，查看统计报表。这个过程会暴露很多只在联调时才会出现的问题，比如某个列表数据查不到、统计图不出现、文件上传后图片打不开。
我一般会建议学生拿一套完整的测试数据，数据里包含至少3个地块、每块地至少4个网格、多台设备、几十条任务、上百条影像记录。这样的数据量才能触发分页问题、状态筛选问题、统计数据的边界问题。很多答辩时的功能演示翻车，都是因为演示数据太少，页面空荡荡，评委看不到功能的完整流转。提前准备一份漂亮的数据，演示效果会好很多。
6. 常见问题排查与避坑速查
6.1 启动阶段的“拦路虎”
启动阶段遇到的问题可以整理成一个速查表，我这几年代码调试里遇到最多的前五名是这些。
数据库连接失败是第一名，原因大多是MySQL没启动、账号密码错误、数据库没创建。解决方式是先用Navicat手动测试连接，不要直接启动项目。端口被占用是第二名，Spring Boot默认8080端口经常被其他程序占用，改配置里的server.port或者杀掉占用进程都可以。依赖下载失败是第三名，一般是Maven镜像源问题，换阿里云镜像就能解决。Maven编译报版本错误是第四名，检查JDK版本和pom里java.version是否匹配。缺少配置项导致启动空指针是第五名，比如使用了Redis配置类但是没配Redis地址，启动时初始化Redis连接失败。
6.2 运行时业务逻辑的常见“怪毛病”
项目启动成功后，更多的问题会出现在业务逻辑层。状态跑飞是最常见的一种，比如任务状态卡在待执行，怎么点执行都没反应。这种问题八成是前端请求根本没发到正确接口，或者后端更新逻辑里状态判断条件不满足，需要在controller打日志看入参。
列表数据不显示的问题，先从控制台看SQL语句。MyBatis Plus会打印SQL日志，你直接复制SQL到数据库客户端执行，如果SQL查不出来，那就是条件构造器写错了；如果SQL能查出来但接口返回空，那就不是SQL的问题，是返回结果转换出错。这一步能快速定位问题范围。
图片上传成功但访问404也是常见问题。确认上传路径和静态资源映射路径一致，确认文件名没有中文字符，Linux和Windows系统对路径分隔符的处理是不同的，代码里尽量用Java的File.separator，不要写死“/”或“\”。另外检查一下图片目录是否有读写权限，Windows本地一般没问题，Linux服务器上经常因为这个权限导致上传失败。
6.3 排查问题的思维方式比记住答案更重要
我在带学生的过程中反复强调一个观念：排查问题不要靠猜，而是靠“分段定位”。一个请求从浏览器发出去到页面有反馈，链路是前端请求、后端Controller接收、Service处理、Mapper查询数据库、结果逐层返回。当现象和预期不一致时，先判断是哪一段出了问题。
最简单的排查方式是每一层打日志。前端控制台看请求是否发出、响应码是多少；后端Controller入口看是否收到请求；Service层看入参和处理结果；最后看SQL执行结果。加上日志后，问题基本在几分钟内就能定位。这种排错思路不仅适用于这个毕设，将来任何真实项目中都是核心技能。不要一上来就怀疑框架本身有问题，框架出错的概率比你写错代码的概率低太多了。实际调试里九成问题都是自己的代码逻辑没考虑全面。
6.4 遇到“看不太懂”的报错怎么处理
开发中难免会遇到完全看不懂的报错信息，尤其是英文长堆栈。我的建议是先读第一行，不要被后面的长堆栈吓住。第一行通常会告诉你异常类型和关键信息，比如ClassNotFoundException、NullPointerException、SQLSyntaxErrorException，这些关键词直接暴露了问题方向。拿到第一行后全文搜索这个异常类型，在网上基本都能找到解决方案。
遇到自己解决不了的问题，把报错第一行加关键配置信息整理成一句话去搜索，不要只复制整个堆栈。很多人搜出来的结果和实际问题无关，就是因为提问太模糊。另外，Stack Overflow和国内的技术社区里，Spring Boot相关报错的解决方案极其丰富，耐心看前几条高赞答案，大部分都能解决。
7. 毕设文档撰写与答辩准备的实战建议
7.1 论文结构怎么组织才不容易被挑刺
这个系统作为毕设题目，论文结构一般建议按序排列：绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望。每个章节之间要有逻辑递进，不要写成“第一个技术介绍完第二技术介绍完然后就跳到了实现”，这样显得没有整体思考。
需求分析章节建议用用例图配合文字说明，把每个角色的操作权限和业务流程讲清楚。系统设计章节覆盖架构图、功能模块图、数据库ER图和核心表结构说明。系统实现章节按模块逐个展示实现逻辑、核心代码片段和页面截图。核心代码不要贴太多，每个模块选最有代表性的方法讲解就够了，关键是讲清楚这个方法的入参、出参和业务判断逻辑。
系统测试章节是很多人的薄弱环节。不要只写“经测试系统功能正常”一句话，要用表格列测试用例：模块、功能描述、操作步骤、预期结果、实际结果、是否通过。有个六到八个用例，覆盖登录、任务创建、数据上传、告警生成、统计查询这些核心链路，表格一贴，测试章节的充实度立刻不一样。
7.2 答辩时候的高频问题和准备角度
答辩老师在这个题目上很可能会盯住三个方向：第一个是数据的真实性来源，比如“你这些影像数据哪来的？”，准备时想清楚答案是“系统采用模拟数据和测试数据验证功能，实际部署时可对接无人机地面站数据接口”；第二个是并发与性能方面的提问，比如“如果多台无人机同时上传影像会不会有问题？”，可以从服务器处理能力和文件存储扩展的角度谈优化空间；第三个是安全方面的提问，比如“如何防止未授权用户调用接口？”，要能说清楚JWT的认证过程和token过期策略。
准备答辩时不要背系统代码，而是准备业务故事线。用一两分钟把系统的运行流程说清楚：“用户登录后创建巡检任务，绑定农田网格和无人机设备，执行任务后上传影像数据，系统通过影像关联到具体网格，根据异常指标产生告警并汇总到统计报表”，这个表述平静、完整、专业。答辩老师的提问再刁钻，只要业务链路清楚，基本都能接得住。
7.3 从“能用”到“有亮点”的改造建议
如果你的毕设想要拿高分，或者导师要求你在此基础上做出更多工作，我建议从三个方向考虑。第一是接入真实的无人机数据来源，目前有一些开源地面站软件能导出飞行日志和遥测数据，做一个定时任务解析这些日志文件导入系统，就能把“模拟数据”变成“半真实数据”。第二是引入更专业的图像分析接口，比如接入云端的图像识别服务来识别作物健康情况，虽然需要申请服务，但毕设中做一个接口调用demo的展示是可行的，效果很有冲击力。第三是增加移动端适配，做一个H5版本让飞手在手机上查看任务和上传现场照片，页面不用太复杂，重点突出“移动办公”的场景。
这三个方向里任何一个做成，都能作为论文里“系统特色”章节的核心支撑点。指导老师看到你在原有框架上做了增量，而不是简单复刻，评价会高一个档次。
8. 一些我自己很深的体会
做这种题目做得多了，我最深的感触是：不少同学不是不会写代码，而是对“系统”两个字缺乏整体感知。他们把大量时间耗在某个细节页面的样式调整上，却不愿意花半小时把数据库表梳理清楚。实际上数据库关系一旦理清楚了，后面的接口和页面开发速度是惊人的，因为你的数据流是通的，每个功能只是把数据流的一段展示出来而已。
如果你拿到的是一套已有的源码，也不要急着大改特改，先让系统原样跑起来，再做增量修改。跑不起来的一切改动都是空中楼阁，等你能自如地说出某张表是干什么的、某个接口被哪个页面调用的时候，你才真正“拥有”了这个项目。到那时候，无论是答辩还是继续做扩展，你都不会慌。
另一个体会是：测试数据真的很值钱。我见过很多演示翻车案例，不是功能写错了，而是测试数据太残缺，页面空空如也，评委看不到完整效果。顺手准备一套覆盖全流程、数据量适中、字段完整的数据，可以让你在演示环节从容许多。这个小习惯的成本极低，回报却高得离谱。
最后再说一个小技巧。开发这个系统的时候，前端页面如果觉得时间紧张，直接用现成的后台管理模板，不要从零写样式。市面上开源的Vue后台模板很多，把登录页改成项目风格，把菜单换成系统模块，工作效率能提升一大截。你省下来的时间应该花在业务逻辑和接口设计上，那些才是这个系统的真正内核。
