做了几年Java后端写过的管理系统不少但大多是标准的增删改查。去年帮一家果蔬种植合作社做了一套作物疾病防治管理系统倒是让我重新体会了一下“业务系统也能有技术含量”这件事。农户在棚里发现西红柿叶片不对劲打开手机选几个症状系统就能告诉他大概率是什么病、该用什么药、剂量怎么配——这套流程真正跑通的时候现场的人都说挺值。这篇博文就把这个基于SpringBootVue的“果蔬作物疾病防治系统”完整拆一遍。项目后端用SpringBoot搭服务、MyBatis做持久层、MySQL存数据前端Vue Element UI铺页面从数据库设计到诊断逻辑再到预警推送和统计报表所有核心模块我都会讲清楚设计思路和实现细节还会把联调阶段踩过的坑一并整理出来。不管是准备做毕业设计、学习前后端分离项目还是想给农业场景写个接地气的管理系统都有可以直接参考的地方。1. 项目整体设计与技术选型1.1 业务场景与需求拆解先说这套系统到底解决什么问题。果蔬种植过程中病害是影响产量和品质的头号因素。传统做法是农户发现异常后拍照发群、问农资店老板、或者请技术员到现场看效率低且依赖人工经验。我接触的这家合作社下辖十几个大棚种植品种有番茄、黄瓜、草莓、辣椒等技术员就两个人每到病害高发季节根本跑不过来。所以系统的核心需求可以拆成四条主线病害知识数字化把常见果蔬病害的症状描述、发病条件、防治方法整理成结构化数据按果蔬种类和病害类型分类管理。诊断过程标准化用户选择果蔬种类、勾选观察到的症状系统根据症状匹配知识库返回疑似病害列表和对应防治方案。防治任务可追踪诊断出结果后生成防治任务记录用药、用量、防治日期形成可追溯的农事档案。异常预警及时化结合环境温湿度数据与病害发病条件做比对达到阈值就触发预警提醒技术员提前干预。这四条主线分别对应知识库管理、诊断分析、防治任务和环境预警四个子系统再配上用户登录、权限管理、统计报表这些通用功能就是一个完整的可落地项目。1.2 为什么选这套技术栈选型这件事很多人纠结其实核心就看三点开发效率、生态成熟度、上手门槛。后端用SpringBoot原因很直接它是目前Java Web领域事实上的标准自动配置省掉大量XML配置时间内嵌Tomcat让部署变成“java -jar”一条命令。用Spring Boot开发这种业务管理系统骨架搭起来半小时以内搞定。持久层选了MyBatis而不是JPA我是有考量的。这个系统的查询场景里诊断匹配、统计报表、多条件筛选这类复杂SQL占了很大比例MyBatis允许手写SQL能把SQL控制在完全可控的状态。像“按月份统计各病害发生次数”这种报表SQL写起来很顺手。有人觉得MyBatis写XML麻烦但在这个项目里SQL的灵活可调比ORM的自动省事更有价值。前端Vue Element UI算是国内中后台项目的经典组合。Vue的响应式数据绑定做表单交互非常顺手Element UI把表格、表单、弹窗、日期选择器这些组件都封装好了开发者不需要在UI上花太多时间把精力集中在业务逻辑上。MySQL作为存储层没什么争议。这个项目的数据量规模单表最多几万行MySQL完全够用。字符集统一用utf8mb4考虑到农户可能会录入一些生僻字或者表情符号utf8mb4比utf8更稳。1.3 源码头组织与部署方式项目采用前后端分离结构源码分为backend和frontend两大块backend ├── pom.xml ├── src/main/java │ └── com.farm.disease │ ├── controller │ ├── service │ ├── mapper │ ├── entity │ ├── config │ ├── common │ └── task └── src/main/resources ├── application.yml └── mapper/*.xml frontend ├── package.json ├── vue.config.js └── src ├── main.js ├── router ├── store ├── api └── views ├── login ├── disease ├── diagnosis ├── task ├── warning └── statistics开发环境里前端通过axios访问后端8080端口vue.config.js里配置代理解决跨域问题。生产环境下用Nginx做反向代理把/api开头的请求转发到SpringBoot服务前端静态文件由Nginx直接托管。整个部署过程就是前后端各打包一次一份jar包加一份dist目录扔到服务器上就能跑。关于数据库初始化项目直接提供一个init.sql脚本包含建库建表和基础字典数据的插入。第一次部署时执行脚本导入即可源码里附带的几十条病害知识记录也在这个脚本里。这块建议别用代码自动建表手动脚本可控性更强而且方便在已有环境上增量升级。2. 数据库设计与核心表结构2.1 核心表结构设计思路数据库设计是这个系统里最关键的部分没有之一。业务功能再多表结构不合理后面写代码处处别扭。我当时设计时围绕“病害诊断”这个核心业务展开所有表都服务于“记录症状—匹配病害—生成防治任务—沉淀数据”这条链路。核心表一共7张sys_user系统用户包含管理员、技术员、农户三类角色。vegetable果蔬种类比如番茄、黄瓜、草莓。disease病害知识表存储病害名称、类型、发病条件、防治方案等。symptom症状标签表比如“叶片有褐色斑点”“果实表面水渍状”“叶片卷曲发黄”。disease_symptom病害与症状的关联表多对多关系这是诊断匹配的核心依据。diagnosis_record诊断记录表保存每次诊断的输入条件和结果。prevention_task防治任务表记录某次诊断后产生的防治操作。另外还有pesticide农药信息表、stock_log出入库记录表、alert_rule预警规则表、alert_log预警记录表、weather_data环境监测数据表这几张辅助表。这里最需要注意的设计是disease_symptom这张关联表。病害和症状不是一对一一种病害通常有多个症状表现一个症状也可能对应多种病害。如果不做拆分在disease表里塞一个symptom_ids字段存逗号分隔的ID查询时根本没法做高效匹配。拆成关联表后用JOIN就能算出每个病害命中了多少症状匹配逻辑瞬间清晰。2.2 关键表字段与MyBatis映射挑几张核心表的字段设计具体说说。disease_symptom关联表CREATE TABLE disease_symptom ( id BIGINT PRIMARY KEY AUTO_INCREMENT, disease_id BIGINT NOT NULL, symptom_id BIGINT NOT NULL, weight INT DEFAULT 1, UNIQUE KEY uk_disease_symptom (disease_id, symptom_id) );weight字段表示该症状对此病害的典型程度匹配时可以用来加权打分。比如番茄晚疫病的典型症状是“叶片水渍状病斑”权重设为3而“叶片卷曲”只是次要症状权重设为1。这样诊断结果不是简单计数而是按权重求和排序准确率更高。diagnosis_record表CREATE TABLE diagnosis_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, vegetable_id BIGINT NOT NULL, user_id BIGINT NOT NULL, symptom_ids VARCHAR(255) NOT NULL, result_ids VARCHAR(255) NOT NULL, match_score DOUBLE DEFAULT 0, status TINYINT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );symptom_ids直接存逗号分隔的症状ID串result_ids存返回的病害ID串技术员后续确认了实际病害后status字段从0改成1数据就能用来做统计分析和诊断模型优化。诊断记录是后续报表统计的数据底座必须存原始输入和结果输出。prevention_task表CREATE TABLE prevention_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, record_id BIGINT NOT NULL, task_no VARCHAR(32) NOT NULL, pesticide_id BIGINT, dosage VARCHAR(50), method VARCHAR(200), task_date DATE NOT NULL, executor VARCHAR(50), status TINYINT DEFAULT 0, remark VARCHAR(500) );task_no是任务编号格式为日期加流水号比如“20250615001”方便线下对账和追溯。dosage字段虽然定义为VARCHAR但它存的不是纯数字而是“15ml/亩”这样的完整描述这是考虑到实际用药场景中农户更习惯看完整的用法用量说明。Mapper层我用XML方式写SQL。MyBatis最常用的场景是动态SQL比如诊断记录的多条件筛选接口用户可能按时间范围、按果蔬种类、按病害名称查询这时候用where加if组合最合适代码里不需要拼字符串SQL的可读性和安全性都更好。2.3 存储细节与初始化数据字符集统一utf8mb4排序规则用utf8mb4_general_ci这块在建库时就固定好后面再改字符集很麻烦。时间字段的类型统一用DATETIME虽然MySQL 8支持TIMESTAMP的自动更新但DATETIME在业务查询和写入时的行为更直白不会受时区偏移影响。初始化数据方面知识库是系统的核心资产。我当时整理了番茄、黄瓜、草莓、辣椒四种作物的常见病害每类8到12种加上对应的症状标签和防治方案一共六十多条知识记录。防治方案不是简单的一句话而是拆成“农业防治”“化学防治”“生物防治”三个维度描述比如化学防治里写清楚推荐的药剂类型和稀释倍数。这些数据看起来不起眼却是系统能不能真正用起来的关键。如果知识库空洞界面再漂亮也没用。3. 后端核心模块实现3.1 登录认证与权限控制后端入口是三部分Spring Security做认证授权、JWT做无状态Token、拦截器校验请求权限。这套组合在前后端分离项目里是标准姿势核心交互流程是前端调/api/auth/login接口提交用户名密码。后端校验通过后生成JWT Token返回给前端并缓存在本地。前端后续请求在HTTP Header里带Authorization: Bearer token。后端拦截器解析Token从里面取出用户ID和角色放行或拒绝。JWT Token里我放了三样东西userId、userName、role。没放太多别的Token体积越小传输开销越低。过期时间设为8小时农业场景下农户白天使用频率高8个小时覆盖一次工作周期到期重新登录也不算频繁。权限控制做了三级角色管理员可以管理用户、果蔬种类、病害知识库、预警规则。技术员可以诊断、创建防治任务、修改诊断结果、查看统计报表。农户只可以诊断、查看自己的诊断记录和防治任务。这个权限模型在前后端各实现了一层。后端在Controller方法上用PreAuthorize(hasRole(ADMIN))做硬校验前端在路由守卫里根据角色过滤菜单。两套方案都做是因为后端校验是安全底线前端过滤是为了交互体验缺一不可。Spring Security的配置有个细节容易踩坑放行接口列表要精确控制。登录接口、验证码接口必须放行但别的接口不能图省事全部放行。我在SecurityConfig里用permitAll()只放行了登录接口和静态资源路径其余接口都要求认证这样系统不会裸奔。3.2 病害诊断分析逻辑诊断模块是整个系统的业务核心也是技术上最有意思的部分。用户在前端选好果蔬种类、勾选症状标签后后端接收请求执行诊断分析返回病害匹配列表。诊断逻辑的核心就一句话根据命中的症状权重总和对已知病害做相似度排序。我分三步实现第一步根据蔬菜种类过滤病害范围。番茄的病害不会出现在黄瓜上这一步把数据量缩小到当前作物的病害集合避免计算结果被不相关病害干扰。第二步拿用户勾选的症状ID集合去disease_symptom关联表里JOIN按disease_id分组算出每个病害命中了哪些症状、权重累加值是多少、命中率是多少。第三步算匹配分。我用了一个简单但效果不错的公式matchScore 命中症状权重总和 / 该病害所有症状权重总和 * 100举个例子番茄晚疫病在知识库里有4个症状总权重是10。用户勾选的症状里命中了其中3个命中权重和为7那么晚疫病的评分就是70分。这个分数代表“用户描述的症状与知识库中该病害典型症状的吻合程度”。最后按分数从高到低排序返回Top5结果每条结果附带病害名称、类型、典型症状、发病条件和防治方案。这里有个实际处理细节用户勾选的症状可能既有病害A的典型症状也有病害B的典型症状导致某个病害命中的权重很低但也被返回了。为了避免无意义的推荐我设置了一个最低阈值60分低于60的病害直接过滤掉。这个阈值是我用历史数据反复验证出来的低于它推荐结果的可用性很差高于它又会漏掉一些不典型症状的病害。诊断Service层的代码逻辑这样组织public ListDiseaseMatchResult analyze(DiagnosisRequest request) { ListDisease diseaseList diseaseMapper.selectByVegetableId(request.getVegetableId()); ListSymptomWeight symptomWeights diseaseSymptomMapper.selectWeightsBySymptomIds(request.getSymptomIds()); MapLong, Integer weightMap new HashMap(); MapLong, Integer totalWeightMap new HashMap(); for (SymptomWeight sw : symptomWeights) { weightMap.merge(sw.getDiseaseId(), sw.getWeight(), Integer::sum); } for (Disease disease : diseaseList) { totalWeightMap.put(disease.getId(), diseaseSymptomMapper.sumWeightByDiseaseId(disease.getId())); } ListDiseaseMatchResult results new ArrayList(); for (Disease disease : diseaseList) { Integer hitWeight weightMap.getOrDefault(disease.getId(), 0); Integer totalWeight totalWeightMap.getOrDefault(disease.getId(), 1); double score hitWeight * 100.0 / totalWeight; if (score 60) { results.add(buildResult(disease, score)); } } results.sort((a, b) - Double.compare(b.getScore(), a.getScore())); return results; }每次诊断结束后把输入症状、返回结果、评分写入diagnosis_record表。这些记录除了做历史追溯更重要的是积累数据。等记录量上来以后可以做统计分析和诊断准确率校准这是系统后续优化迭代的数据基础。3.3 预警任务与统计接口预警模块的作用是“治未病”。很多病害在爆发前有明显的环境征兆比如番茄晚疫病在高湿低温环境下极易发生草莓灰霉病在持续阴雨天高发。如果能在环境数据达到临界条件时提前通知技术员防治效率会大幅提升。实现方案数据库里建alert_rule预警规则表每条规则包含病害ID、关联气象因子类型、阈值范围、预警等级。比如“当温度低于20度且湿度高于85%持续3天时触发番茄晚疫病黄色预警”。后端启动一个Scheduled定时任务每天凌晨执行一次。逻辑是读取当天及前两天的环境监测数据与预警规则逐一比对满足条件就写入alert_log表并生成站内通知。环境数据可以从大棚里的物联网设备接口拉取也可以手工录入这个项目里我预留了一个weather_data表支持两种方式的写入。统计接口这一块主要跑两类数据一是病害发生趋势按月份统计各类病害的诊断次数展示柱状图二是防治任务完成情况按技术员、按任务状态统计用饼图展示。报表SQL用GROUP BY按月份聚合比如“统计近12个月每月诊断记录数量”的SQLSELECT DATE_FORMAT(create_time, %Y-%m) AS month, COUNT(*) AS count FROM diagnosis_record WHERE create_time DATE_SUB(NOW(), INTERVAL 12 MONTH) GROUP BY DATE_FORMAT(create_time, %Y-%m) ORDER BY month;这个查询在MySQL里执行效率没问题量级大的时候可以在create_time上建索引。统计接口统一返回给前端ECharts渲染用的数据结构前端不需要二次加工直接绑定数据就行。4. 前端Vue页面搭建与交互4.1 页面架构与路由前端这部分用的是Vue 2 Element UI ECharts Pinia。有人问我为什么不直接上Vue 3说实话Vue 2的生态在这个项目里太成熟了Element UI的组件和Vue 2配合稳定参考案例多踩坑成本低。如果是从零学起的新手Vue 2的教程资料也更全。路由设计按照业务模块拆分const routes [ { path: /login, component: Login }, { path: /, component: Layout, redirect: /dashboard, meta: { requiresAuth: true }, children: [ { path: dashboard, component: Dashboard, meta: { title: 首页看板, roles: [ADMIN, TECH, USER] } }, { path: disease, component: DiseaseList, meta: { title: 病害知识库, roles: [ADMIN, TECH] } }, { path: diagnosis, component: Diagnosis, meta: { title: 病害诊断, roles: [ADMIN, TECH, USER] } }, { path: record, component: DiagnosisRecord, meta: { title: 诊断记录, roles: [ADMIN, TECH, USER] } }, { path: task, component: PreventionTask, meta: { title: 防治任务, roles: [ADMIN, TECH] } }, { path: warning, component: WarningLog, meta: { title: 预警信息, roles: [ADMIN, TECH] } }, { path: statistics, component: Statistics, meta: { title: 数据统计, roles: [ADMIN, TECH] } }, { path: system/user, component: UserMgt, meta: { title: 用户管理, roles: [ADMIN] } } ] } ];导航菜单是根据路由表里的meta信息动态生成的用户登录后根据角色过滤可访问的路由再生成对应的菜单项。这样做的好处是后端接口有权限校验前端菜单也做了角色过滤双重保障用户看不到也进不去没有权限的页面。axios实例统一封装在api目录下配置请求拦截器加上Tokenaxios.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; });响应拦截器统一处理401跳登录页、500弹错误提示这类公共逻辑每个页面不需要重复写错误处理。4.2 诊断页面与结果展示诊断页面是这个系统用户用得最多的页面交互设计直接影响使用体验。整个页面分三步走第一步选作物。页面上方放一个果蔬种类的卡片选择区番茄、黄瓜、草莓、辣椒各一张卡片点击选中会高亮显示。第二步勾症状。下方是症状标签区域按“叶片症状”“果实症状”“茎秆症状”“根部症状”分类用户点击标签进行多选。症状标签是圆形图标加文字的形式选中后图标变绿很直观。第三步点“开始诊断”。前端把vegetableId和symptomIds数组提交到后端诊断结果返回后右侧弹出一个结果抽屉按匹配分高低展示病害列表。每个病害卡片上标明匹配度百分比、典型症状、发病条件和推荐的防治方案还附一个“生成防治任务”按钮一键跳转到任务创建表单。这里有个交互细节当用户勾选症状时前端其实可以先做一次本地过滤提示比如“这些症状更像番茄晚疫病的表现是否查看”但考虑到知识库数据必须在后端过滤才能保证准确性这个提示逻辑就放到后端返回结果后再展示前端不做前置猜测避免误导用户。诊断记录的页面用表格展示字段包含果蔬种类、勾选的症状、推荐的病害、匹配分、确认状态、诊断时间。技术员可以对记录做“确认病害”操作把最终确诊的结果更新进去。这个功能看起来简单但对数据质量提升非常关键——只有确认过的记录才能用于后续的准确率评估。4.3 数据统计与报表可视化统计页面的核心价值是让管理者一眼看懂病害的发生规律为下一季的种植计划提供参考。我用了ECharts做可视化三张图分别回答三个问题趋势图近12个月各病害发生次数折线图直观看到病害的高发期。分布图当前所选月份各病害占比饼图知道哪个病害最需要关注。对比图不同果蔬种类病害数量对比柱状图看出哪些作物更容易发生病害。前端获取数据的接口返回JSON结构用ECharts的series配置直接绑定。以趋势图为例this.axios.get(/api/statistics/trend, { params: { months: 12 } }).then(res { const data res.data; this.chart.setOption({ xAxis: { type: category, data: data.months }, series: [{ type: line, data: data.counts, smooth: true }] }); });这里的图表加载时机有一个小坑页面进来时DOM可能还没渲染完成直接初始化ECharts实例会拿不到容器高度。我用了this.$nextTick(() { this.chart echarts.init(this.domRef); })确保容器存在后再初始化。另外窗口大小改变时图表不会自动适配需要在浏览器resize事件里手动调用chart.resize()。这两个细节不处理开发环境看不出问题部署后在不同分辨率的终端上就会出糗。5. 联调排错与常见问题汇总5.1 开发联调中的高频坑前后端分离项目的坑大部分集中在联调阶段。前端说后端返回的数据格式不对后端说前端传的参数有问题这类沟通成本非常耗费时间。我在这个项目里总结了三个高频问题。第一个坑前端传参格式与后端接收不一致。比如诊断接口接收的是ListLong symptomIds但前端不小心传成了逗号分隔的字符串“1,2,3”后端直接报400。解决方式有两种前端统一用JSON数组传参或者在Controller层用RequestParam ListLong配合前端qs库序列化。我更推荐前一种前后端各写清楚接口文档传JSON对象字段名和类型严格对齐联调阶段能省一半时间。第二个坑跨域请求配置不当。开发环境前端在8081端口后端在8080端口浏览器默认禁止跨域请求。在vue.config.js里配置代理是最省事的方式devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }注意changeOrigin必须设为true不然后端拿到的请求域名还是8081部分严格校验HOST的场景会出问题。还有如果是配置Spring后端的CORS需要保证前端请求的OPTIONS预检请求也能被正确响应否则跨域问题会时好时坏。第三个坑Transactional事务失效。这个很容易被新手忽略。我一开始写诊断记录保存和防治任务创建时在Service方法上加Transactional结果发现运行时事务根本没生效。后来排查原因发现是同一个类内部方法自调用导致代理失效。在Controller里调Service方法没问题但Service里一个方法调另一个带事务注解的方法代理机制不会拦截内部调用。解决方式有两种把事务方法拆到独立Service或者通过AopContext.currentProxy()手动获取代理对象。我的习惯是前者代码结构更清晰。5.2 常见问题速查表把项目调试过程中遇到的其他典型问题整理成一张速查表方便直接照查问题现象根本原因解决方案登录后请求接口一直401Token过期或未正确存入localStorage检查响应拦截器是否在登录后正确存储Token确认请求头携带格式为Bearer加空格上传图片大小超限Spring默认单文件1MB限制在application.yml中配置spring.servlet.multipart.max-file-size和max-request-size时间显示比数据库慢8小时时区未配置导致UTC时间在数据库连接URL加serverTimezoneAsia/Shanghai前端统一格式化动态SQL语句多出一个逗号MyBatisif标签拼接不当使用trim标签配合prefixOverrides,避免逗号残留前端图表在部分浏览器不显示ECharts版本兼容问题统一升级ECharts版本避免使用旧版canvas特性部署后接口404但本地可访问前端路由用了history模式Nginx配置try_files $uri $uri/ /index.html或者改用hash模式数据库导入中文乱码客户端连接字符集不一致导入前执行SET NAMES utf8mb4确保SQL文件本身是UTF-8编码这里面最值得多说一句的是时间问题。MySQL连接串里如果不加serverTimezoneAsia/Shanghai高版本的MySQL驱动默认使用UTC时区查询结果会比北京时间晚8小时。这个坑非常隐蔽很多人调整了半天代码都没用最后发现是连接串少了一个参数。我在系统初始化的时候就在配置文档里把这个点写进去之后接手的同学基本没再踩到。还有一个小技巧也值得分享诊断接口的性能优化。业务量小的时候每次诊断实时JOIN没问题但记录多了以后知识库查询会变慢。我在disease_symptom表上建了一个联合索引(disease_id, symptom_id)并且在应用启动时用PostConstruct把完整的病害知识库加载到内存中。知识库数据量不大全量常驻内存完全没问题诊断请求直接查内存Map性能从几十毫秒降到几毫秒。数据变更时更新缓存即可。写在最后我个人做完这个项目的最大感受是技术选型不是越新越好适合业务场景才是第一原则。SpringBoot Vue的组合在当前阶段仍然是中小型管理系统最稳妥的方案生态资料丰富遇到问题几乎都能找到现成答案。病害诊断模块的规则匹配算法并不复杂却让我重新认识了一件事——很多所谓的“智能功能”最核心的不是算法多高深而是业务数据整理得是否扎实。知识库设计得越细致权重分配越合理系统给出的结果就越接近有经验的老师傅的判断。最后再分享一个经验做完系统后我特意让合作社的技术员用了两个月发现实际使用中农户最常用的功能不是诊断而是防治任务记录和查询——他们更关心“上次怎么处理的”。这也提醒了我做业务系统要多听真实用户的声音功能优先级往往和开发者的预设有很大出入。如果你正在做类似的系统建议在需求确认阶段多花时间跟实际使用者聊比闷头开发多做几个功能有用得多。
