企业官网建设流程全解析

前两天有个学弟来找我聊计算机毕业设计选题，刚坐下就问我：“哥，我准备用SpringBoot做一个智慧城市垃圾分类管理系统，这题是不是太烂大街了？”我反问他：你打算怎么做？他说：“就是管理员后台，加上垃圾智能识别，再加个清运管理呗。”我听完就知道，绝大部分人拿到这个题目，都容易把它想成一个普通的增删改查后台。但说实话，这个题目里面藏着两条真正有含金量的技术主线：一是垃圾智能识别，二是清运调度。如果把这两条线做出深度，再配合SpringBoot本身扎实的业务实现，这个题不但不“水”，反而是一个特别典型的智慧城市落地场景。这篇文章，我就按我自己的实战经验，把从选题拆解、技术选型、识别模块落地、调度算法设计，到SpringBoot实战中容易踩的坑和答辩准备的完整链路，一次性讲清楚。

1. 这个题目隐藏着两条主线：识别与调度，别被“管理系统”四个字带偏

1.1 拆开题目：它其实是四个子系统拼在一起

很多同学看到“智能垃圾处理信息化管理系统”这个名字，第一反应就是做一个后台管理系统，结果做着做着就变成了：用户管理、角色管理、日志管理，再加几张业务表，最后答辩的时候老师一问“智能在哪”，当场卡壳。

这个题目的正确拆法，是把“智慧城市垃圾分类与回收监管平台”当成一个完整的产品来做。往细了分，它至少包含四个端：

• 居民端：微信小程序或H5页面，居民注册登录、扫码开箱、投放垃圾、查看分类结果、获取积分。这里涉及图片上传、识别结果回显、积分流水。
• 运营监管后台：面向社区或环卫管理人员，查看每个站点的实时状态、投放记录、分类正确率、违规事件、基础数据管理。这是SpringBoot最典型的管理系统部分。
• 清运端：面向清运司机/环卫工人，接收清运任务、查看任务列表、标记任务完成、上报异常。
• 识别服务：独立或嵌入的图像分类服务，接收前端上传的垃圾图片，返回垃圾类别和置信度。这个模块是整个项目“智能”的核心，也是答辩时的亮点。

这四个端不是孤立存在的，它们靠一条业务主线串起来：居民投递垃圾 → 系统拍照识别 → 判定分类是否正确 → 积分入账 → 站点填充率变化 → 触发清运任务 → 司机完成清运回收 → 站点状态重置。

只要这条链路是通的，这个系统就不再是普通的CRUD，而是一个有完整数据闭环的智能监管平台。

1.2 真正的难点和加分点在哪里

我把这个题目能给分的地方排了个序：

1. 识别准确率与业务兜底逻辑。识别不是丢一个模型接口就完事，你需要处理置信度低、图片模糊、识别失败这些真实场景。比如识别置信度低于0.6时，系统要让用户重新投放或者转人工判定，这个兜底设计比识别本身更能体现工程能力。
2. 清运调度策略。垃圾桶什么时候满？满了之后派谁去清？如果同时多个垃圾桶满了，路线怎么安排？哪怕只做“按紧急程度+距离”的贪心策略，也比纯手工派单高级得多。
3. 数据可视化与监管报表。站点分布地图、分类正确率趋势图、清运及时率，这些是老师最容易看懂、也最容易加分的部分。
4. 模拟数据与演示效果。没有真实传感器数据怎么办？做一套模拟数据生成器，让系统在演示时数据是“活”的，这一点我会在第六章专门讲。

1.3 评委看什么：完整业务闭环大于单点炫技

我见过不少同学把一个算法跑得很炫，但业务系统只有几张表，这种项目答辩时反而容易翻车。为什么？因为这是“计算机毕业设计”，核心考核点是你能否独立完成一个完整的软件工程任务，而不是发论文。评委更愿意看到的是：

• 你清楚这个系统解决了什么现实问题；
• 你有完整的需求分析、数据库设计、模块划分；
• 你能把识别、调度这些技术点合理地融进业务里；
• 整个系统跑起来是一个看得见摸得着的产品。

所以我的建议是：先把业务闭环做扎实，再去优化模型和算法。业务闭环是及格线，识别和调度是拉分项，顺序不能反。

2. SpringBoot版本选择：为什么我建议直接锁定2.7.18，而不是最新版

2.1 版本焦虑从哪来，又该怎么解决

说句实话，这个题目翻车率最高的地方根本不是业务逻辑，而是版本。现在IDEA新建SpringBoot项目默认直连Spring Initializr，很多同学手一抖就选了SpringBoot 3.x，JDK也顺手选了17甚至21。结果代码写到一半，发现自己依赖的教程全是基于SpringBoot 2.x写的，MyBatis-Plus版本对不上，网上搜到的报错方案也不兼容，最后越改越乱。

从我个人的经验来看，这个项目老老实实用SpringBoot 2.7.18 + JDK 1.8是性价比最高的选择。原因有三条：

• 2.7.18是SpringBoot 2.x系列的最终维护版本，度过了漫长的社区验证期，各种依赖兼容性文档齐全。
• 绝大多数毕业设计教程、开源项目、网上的报错解决方案，都是基于2.x和JDK1.8写的，你遇到任何问题几乎都能搜到答案。
• JDK1.8在开发环境、实验机房、服务器上兼容性最好，不用折腾版本切换。

如果你非要用SpringBoot 3.x也不是不行，但意味着你要接受：javax包名变成jakarta、部分starter命名变化、一些老牌第三方库不再维护等问题。对于毕设这个场景，完全没必要给自己增加这种不确定性。

2.2 推荐技术栈与架构分层

下面这个组合是我在类似项目中实测稳定的一套，直接照着用问题不大：

架构上我强烈建议不要拆微服务。我不是说微服务不好，而是这个体量的系统单应用完全扛得住，拆微服务只会增加部署复杂度，答辩的时候你还得解释服务间通信、分布式事务这些自己未必真能讲清楚的东西。正确的做法是：一个SpringBoot主应用 + 一个Python识别服务，两个进程通过HTTP通信，足够清晰，也足够体现前后端分离和跨语言协作能力。

2.3 数据库设计：核心表撑起整条业务链

这个项目核心表我建议控制在8张左右，字段宁精勿多。下面这几张表基本能覆盖整条业务链路：

这里我特别提醒一句：dump_record表是整个系统的“事实表”，识别结果、置信度、用户、站点、是否正确分类，全部要落在这张表里。后续的分类正确率统计、积分计算、站点负荷预测，都基于这张表的数据。所以这张表的设计一定要留足冗余字段，别图省事。

核心表建表语句我拿投放记录表举例：

CREATE TABLE `dump_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL COMMENT '投递用户ID', `site_id` bigint(20) NOT NULL COMMENT '站点ID', `image_url` varchar(255) DEFAULT NULL COMMENT '垃圾图片路径', `item_name` varchar(64) DEFAULT NULL COMMENT '垃圾名称', `category_result` varchar(32) DEFAULT NULL COMMENT '识别类别', `confidence` decimal(5,4) DEFAULT NULL COMMENT '识别置信度', `is_correct` tinyint(1) DEFAULT NULL COMMENT '分类是否正确', `handle_type` tinyint(1) DEFAULT NULL COMMENT '处理类型：0自动识别 1人工审核 2模拟数据', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_site_id` (`site_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意几个细节：使用InnoDB引擎，统一utf8mb4，外键关系不要物理建，靠索引和业务逻辑保证；时间字段只存utc时间，前端展示时再格式化；把所有查询高频字段都加上索引。

3. 垃圾智能识别模块：从“公开数据集+轻量模型”到SpringBoot调用

3.1 先泼盆冷水：毕设不需要你从零训练大模型

很多同学一想到识别，第一反应就是从零训练一个神经网络，然后陷入数据集标注、GPU训练的泥潭。其实这个思路错得离谱。对于毕设而言，你需要的不是“自己发明一个模型”，而是“把一个模型工程化地接入业务”。

我实际推荐的有三条路线，按性价比排序：

最推荐方案一：下载垃圾分类公开数据集，用轻量分类模型训练一下，再封装成一个内网可访问的Python服务，SpringBoot通过HTTP调用。这个方案的优势在于：你能讲清楚“图片从哪来、模型怎么训练、服务怎么部署、接口怎么对接”的完整链路，答辩老师无论问到工程还是算法，你都有话可说。

3.2 数据集和模型选型：别在这上面内耗

垃圾分类相关的公开数据集市面上有不少，常见的有TrashNet、Garbage Classification等，类别通常覆盖纸类、玻璃、金属、塑料、纸板、织物等。国内一些平台也提供了符合四分类标准的垃圾分类数据集。你可以根据自己系统的分类标准选取子集，不用全量训练。

模型选型上，不需要上ResNet101这种大网络，一个MobileNetV3或YOLOv5的分类分支足够：图片量几千到几万张，几个类别，用迁移学习方式很快能训练出80%以上的准确率。想少走弯路就直接找一个开源项目提供的预训练权重，在此基础上做迁移学习，训练时间、显存需求都低很多。

这里我想强调一点：识别准确率不是这个项目的唯一目标，系统的容错设计才是。哪怕模型准确率只有85%，只要你在错误发生时给了用户重新投放、人工判定、积分扣减等处理机制，这个系统同样是合格的。

3.3 用FastAPI把模型包成识别服务

训练好模型之后，我们用FastAPI写一个极简的识别服务。代码不复杂，核心逻辑就是接收图片，返回类别和置信度：

from fastapi import FastAPI, UploadFile, File import torch from torchvision import transforms from PIL import Image import io import models app = FastAPI() model = models.MobileNetV3(num_classes=6) model.load_state_dict(torch.load("garbage_model.pt", map_location="cpu")) model.eval() class_names = ["cardboard", "glass", "metal", "paper", "plastic", "trash"] transform = transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]) ]) @app.post("/classify") async def classify(file: UploadFile = File(...)): image = Image.open(io.BytesIO(await file.read())).convert("RGB") img_tensor = transform(image).unsqueeze(0) with torch.no_grad(): outputs = model(img_tensor) probs = torch.softmax(outputs, dim=1) conf, idx = torch.max(probs, dim=1) return { "category": class_names[idx.item()], "confidence": round(conf.item(), 4) }

服务启动后监听在某个端口，比如8000。SpringBoot这边只需要用RestTemplate或WebClient调用它：

public ClassifyResult classify(MultipartFile file) { String url = "http://localhost:8000/classify"; MultiValueMap<String, Object> body = new LinkedMultiValueMap<>(); body.add("file", new ByteArrayResource(file.getBytes()) { @Override public String getFilename() { return file.getOriginalFilename(); } }); HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.MULTIPART_FORM_DATA); HttpEntity<MultiValueMap<String, Object>> requestEntity = new HttpEntity<>(body, headers); ResponseEntity<ClassifyResult> response = restTemplate.postForEntity(url, requestEntity, ClassifyResult.class); return response.getBody(); }

这段代码在实际项目里我已经跑过很多次，关键点在于ByteArrayResource必须重写getFilename方法，否则服务端接收到的文件名是空的，某些框架会直接报错。

3.4 边界情况处理：识别失败的兜底机制

接口通了还不够，真正考验工程能力的是边界情况。我在实际开发中至少会遇到三类问题：

• 图片质量差导致置信度低：解决方案是设置阈值，低于0.6时返回“识别不明确，请重新投放”，同时生成一条人工审核记录，管理员在后台可以手动判定。
• 识别服务不可用：SpringBoot调用Python服务超时或连接拒绝时，不能把异常抛给前端断掉整个流程，应该降级处理，比如先记录投放但标记为“待人工审核”。
• 并发压力：一个社区可能同时在多个站点产生投放请求，单进程识别服务在高并发时响应会变慢。如果你只做毕设，可以加一个Redis队列，投放请求先进队列，后台线程异步消费，识别完成后通过WebSocket或轮询把结果推给用户端。这个设计在答辩时是非常好的加分项。

4. 清运调度模块：先把业务逻辑写透，再把路径规划做成加分项

4.1 任务从哪来：四种触发方式缺一不可

清运调度模块的核心不是路径算法，而是“任务怎么被正确生成”。我在设计中实现了四种来源，组合起来能让整个模块显得非常完整：

1. 阈值触发：站点current_load / capacity超过设定阈值（比如80%），自动生成清运任务。
2. 定时触发：按配置的计划，比如每天早晚各巡检一次，把负荷超过50%的站点纳入任务。
3. 居民上报：居民端设置“站点已满”或“垃圾外溢”上报按钮，上报产生异常事件，并生成紧急清运任务。
4. 预测触发：根据历史投放数据，预测某个站点在未来几小时可能达到满仓，提前生成任务。

前三种都很好实现，第四种是拉开差距的地方。不需要复杂算法，用简单的线性回归，按站点统计最近7天的每小时投放量，算出平均增长速率，就可以估算“预计满仓时间”。

4.2 任务包与路径规划的贪心实现

当有多个站点同时需要清运时，怎么安排路线是个经典问题。毕设阶段不需要上精确算法，贪心最近邻足够。思路很直白：从当前位置出发，每次选择离当前点最近、且紧急程度排在最前面的未访问站点，依次加入路线。

public List<DumpSite> planRoute(List<DumpSite> pendingSites, DumpSite startPoint) { List<DumpSite> route = new ArrayList<>(); DumpSite current = startPoint; while (!pendingSites.isEmpty()) { pendingSites.sort(Comparator .comparingInt((DumpSite s) -> s.getUrgencyLevel()) // 紧急度排前面 .thenComparingDouble(s -> distance(current, s))); // 再按距离 DumpSite next = pendingSites.remove(0); route.add(next); current = next; } return route; }

这个算法有一个明显的缺陷：它只考虑局部最优，整体路线可能不是最短的。但如果任务站点数量不多（比如50个以内），贪心结果完全够用。如果你想让答辩多一个聊点，可以在贪心基础上加一个2-opt局部优化，两两交换路线中的站点顺序，看总距离是否下降，迭代几百次就能逼近较优解。这个改进代码量不大，但体现的是“我知道算法局限，且知道我该怎么改进”的思考过程。

4.3 可视化：地图打点与轨迹回放

调度模块如果只有表格，说服力会弱很多。建议在后台管理界面做一个“调度地图”页，把站点地图打点、任务状态用颜色区分、当前任务路线用连线展示。前端实现可以用高德地图JS API，如果不想申请key或者想减少依赖，也可以用ECharts地图配合GeoJSON做简化版。

我需要提醒你的是：不用追求完美的轨迹回放。毕设阶段做到“地图上有站点标记、点击能看到负荷、任务发起后能画出推荐路线”，这个效果已经超过大多数同类题目了。

4.4 没有真实数据怎么办：模拟数据生成器

没有真实传感器、没有真实投放数据，演示的时候怎么办？最实用的办法是写一个模拟数据生成器。你可以做一个后台按钮，或者在系统启动时通过CommandLineRunner自动插入一批模拟数据：随机生成几个站点、随机生成近7天的投放记录、随机调整站点负荷，让系统跑起来就有真实感。

@Bean public CommandLineRunner initMockData(DumpSiteService siteService, DumpRecordService recordService) { return args -> { if (siteService.count() > 0) return; // 生成站点 List<DumpSite> sites = mockSiteGenerator.generate(20); siteService.saveBatch(sites); // 生成投放记录和站点负荷 mockRecordGenerator.generate(sites, 2000); }; }

模拟数据生成器有两个额外的好处：一是可以用于单元测试，二是可以证明你的系统经得起数据压力，而不是一页空表。

5. SpringBoot实战中更容易翻车的六个地方，每一个我都踩过

5.1 事务失效：同类调用与异常被吞

清运任务开始执行时，通常会有两步操作：把任务状态从“待处理”改成“处理中”，同时写入一条操作日志。很多同学都会写成同一个类里的两个方法：

public void startTask(Long taskId) { updateTaskStatus(taskId, "processing"); insertTaskLog(taskId, "开始执行"); }

如果insertTaskLog抛异常，updateTaskStatus照样提交了，因为@Transactional失效了。原因有两个：一是同类内部方法调用不会经过Spring代理，二是日志写入的异常被外面的catch吞掉。解决方法很简单，把日志写入和状态更新合并到一个受事务管理的方法里，或者把这个方法拆到另一个Service类中，并确保异常不要被吞。

5.2 MyBatis-Plus逻辑删除与唯一索引打架

我给user表加逻辑删除后，遇到一个很隐蔽的坑：当用户被删除后又重新注册时，如果手机号字段有唯一索引，第二次插入会直接报Duplicate entry。原因很简单，逻辑删除并没有真正删除这行记录，唯一索引依然存在。

解决方案有三种：删除时把手机号拼上一个时间戳后缀，让唯一索引不再冲突；或者把手机号和deleted字段联合起来建唯一索引；再或者单独建一张回收历史的表。我最推荐第二种，既能保留逻辑删除，又能保证唯一性校验合理。

5.3 @Scheduled多实例重复执行

如果系统部署了多个实例，或者你在本地启动了多个节点，每个用@Scheduled标注的任务会在每个实例上各跑一次，清运任务就会重复生成。解决方案是引入分布式锁，把任务执行权抢过来再跑：

public void generateCleaningTask() { String lockKey = "job:generateCleaningTask"; boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofMinutes(5)); if (!locked) return; try { // 任务逻辑 } finally { redisTemplate.delete(lockKey); } }

5.4 上传大小限制与静态资源映射

系统里居民要上传垃圾图片，SpringBoot默认的multipart文件大小上限是1MB。现在手机拍一张图动辄2-3MB，直接报MaxUploadSizeExceededException。需要在application.yml中配置：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 50MB

同时本地保存图片后，要给static目录或上传目录做资源映射。这件事很基础，但漏了会导致前端图片全部403，演示时极其尴尬。

5.5 LocalDateTime前端序列化问题

SpringBoot返回给前端的LocalDateTime默认序列化格式是“2025-01-01T12:00:00”，如果前端组件期望“yyyy-MM-dd HH:mm:ss”，就显示不对。全局配置一下即可：

@Configuration public class JacksonConfig { @Bean public Jackson2ObjectMapperBuilderCustomizer jsonCustomizer() { return builder -> { builder.simpleDateFormat("yyyy-MM-dd HH:mm:ss"); builder.serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); builder.deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); }; } }

5.6 配置文件与敏感信息管理

用application.yml写数据库密码、云平台密钥时，如果上传到公开仓库，等于把项目的地基漏给别人。至少做两件事：项目仓库加入.gitignore，排除application-prod.yml；配置里使用环境变量引用敏感信息。有条件的话可以引入Jasypt做加密，不过毕设做到“环境变量替换+不上传配置文件”已经合格。

6. 部署、演示与答辩：让项目从“能跑”变成“能打”

6.1 Dockerfile与docker-compose的落地写法

项目最终要提交运行，我建议把SpringBoot应用、MySQL、Redis用docker-compose编排起来，这样在评委电脑上部署或者录制演示视频时，一条命令就能启动整个服务。

先给SpringBoot应用写一个精简的Dockerfile：

FROM openjdk:8-jre-alpine ENV TZ=Asia/Shanghai RUN ln -sf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone WORKDIR /app COPY target/*.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

然后docker-compose把三个服务串起来：

version: "3.8" services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_DATABASE: garbage_system ports: - "3306:3306" volumes: - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql redis: image: redis:6-alpine ports: - "6379:6379" app: build: . depends_on: - mysql - redis environment: SPRING_PROFILES_ACTIVE: prod MYSQL_HOST: mysql REDIS_HOST: redis ports: - "8080:8080"

注意：数据库初始化脚本挂载到docker-entrypoint-initdb.d目录，容器首次启动时会自动执行，这个方式实测下来非常省事。

6.2 演示故事线：一条视频讲完整个闭环

答辩演示最忌讳的是东点一下西点一下。我建议提前准备一条完整的“故事线”：

1. 打开居民端，模拟一个用户投递垃圾，上传一张图片；
2. 展示识别结果和置信度，积分入账；
3. 切到后台，查看刚才这条投放记录；
4. 把某个站点负荷手动调到85%，触发清运任务；
5. 清运端打开任务列表，点击“开始”，地图上展示推荐路线；
6. 完成任务后，站点负荷归零，系统生成一条回收订单。

这条线讲完，整个系统的业务价值一目了然，老师不需要你解释太多就能看懂。演示前一定要清空脏数据，把模拟数据生成器的日期调整到“今天”，避免出现日期对不上的情况。

6.3 答辩被问得最多的五个问题

根据我自己的答辩和帮别人模拟答辩的经验，这几个问题出现频率最高：

6.4 最后的小建议：git提交历史与设计文档

如果时间允许，一定要把项目纳入Git管理，提交历史勤快一点。我自己评判一个学生水平的时候，最怕看到的是“整个项目只有一个最后的提交”，这说明过程要么是复制粘贴，要么是最后赶工。有完整的提交历史，配合一个按“需求分析-数据库设计-接口设计-功能实现-部署测试”组织的设计文档，答辩的底气完全不一样。

最后分享一点个人体会：毕设做这个题目，最难熬的不是技术，而是“永远感觉自己没准备好”的阶段。等你把识别服务跑通、把调度路线画出来、把demo录完，回头再看不理解的地方其实早就消化了。过程中如果卡住，先分清是“环境问题、依赖问题还是业务问题”，逐个击破，大多数坑都写在文档里了。希望这篇长文能帮你少走几步弯路，也欢迎在评论区交流你在这个项目里踩到的具体报错，我们接着聊。