不吃章鱼烧毕设选“社区垃圾分类与回收服务系统”微信小程序，这个题目我从几个角度都觉得很值得做。它挂着微信小程序的热点，又有垃圾分类这个明确的应用场景，底层还能把网络请求、数据交互、图表可视化这些基本功全串起来，难度适合本科毕设，工作量也容易控制在两三个月内。关键是演示效果很直观——手机端下单回收、后台看到订单流转、大屏上展示分类数据趋势，答辩时讲起来有画面感，比纯做CRUD管理系统的同学有优势得多。
这篇文章我会从选题思路、功能拆解、数据建模、核心技术实现、演示录像制作，到答辩避坑，完整走一遍复盘。哪怕你现在只拿到一个半成品源码，照着这篇文章的思路也能快速搞懂系统结构，然后改造成真正属于自己的毕设项目。
1. 毕设选题与系统整体设计思路
1.1 为什么“社区垃圾分类回收”是好题目
毕设选题最怕两个极端：题目太空，比如“基于XX的智能管理系统”，做完也说不清解决了什么实际问题；题目太深，比如“基于深度学习的垃圾图像识别”，本科阶段光调模型就要脱一层皮，还容易卡在数据集和算力上。
“社区垃圾分类与回收服务系统”恰好卡在中间偏上的位置。它有明确的社会背景支撑——垃圾分类政策推进多年，社区回收链条里居民端缺乏便利的投放/预约工具，物业或回收企业端缺乏数据化的管理手段。这个痛点真实存在，系统做出来能讲清楚“解决了谁的问题”。
从技术角度看，它是典型的前后端分离项目，但不像电商系统那么复杂。核心业务是：居民线上预约回收、查看分类指南、获取积分；管理员处理订单、管理回收品类、查看统计图表。数据量不大，逻辑不绕，但该用的技术栈都能覆盖到，包括微信小程序的登录授权、接口鉴权、文件上传、ECharts可视化、Excel导出这些高频技能，每一个在找工作时都能单独拿出来当谈资。
这个题目还有天然的可扩展性。基础版做完后，你可以加积分商城、加地图选址、加回收员接单派单，甚至加一个爬虫脚本自动更新垃圾分类词库。扩展方向很多，而且每个方向都不需要重写系统，答辩时“未来展望”这一问就不会卡壳。
1.2 系统功能模块划分：用户端、回收员端、管理后台
我参考了多个开源毕业设计项目后，把功能收敛成三大端。为什么是三端而不是两端？因为单纯做“用户+管理员”会导致回收业务流程断裂——用户提交回收预约后，谁去接单、谁去上门、谁确认回收？如果都由管理员线下处理，这个系统就没有真正完成业务闭环，答辩时老师一定会问。
所以合理的划分是：
- 用户端（微信小程序）：微信登录、垃圾分类指南查询、垃圾名称搜索、预约上门回收、我的预约列表、积分记录、个人中心。
- 管理端（Web后台）：回收品类管理、预约订单审核与派单、订单状态流转（待接单→已接单→已完成）、用户管理、积分规则配置、数据统计图表。
- 移动端展示（可选加分项）：以数据可视化大屏或小程序内嵌图表形式，呈现各社区投放量、回收品类占比、月度趋势。
1.3 技术栈选型：为什么推荐“小程序原生 + Spring Boot”
很多同学纠结技术栈选什么。我直接说结论：小程序端用微信原生框架，后端用Spring Boot + MyBatis-Plus + MySQL，可视化用ECharts。
选微信原生不选uni-app，是因为毕业设计讲究“可控性”。原生框架出了问题，微信官方文档和社区一搜就有答案，答辩时老师问“这个API的原理是什么”，你能清晰回答。uni-app虽然一套代码多端复用，但它是二次封装，一旦遇到兼容性bug，排查成本反而高。对于毕设这种体量，不需要多端复用，原生最稳。
后端选Spring Boot而不是PHP或Python，有现实考量。JAVA在高校课程体系里覆盖率最高，你的指导老师大概率是Java背景，答辩时用Java技术栈，老师问的问题你基本都能预判。另外Spring Boot生态太成熟了，MyBatis-Plus的代码生成器能直接省掉大量重复的CRUD代码，JWT做登录鉴权、Spring Security做权限控制，都有非常成熟的方案。
如果你擅长PHP或Python，也不是不能用，但要注意：毕设的评分标准里有“技术难度”一项，Spring Boot + MyBatis-Plus + Redis + JWT这套组合在评分上明显高于单纯的PHP或者Flask+Layui。在不增加太多工作量前提下，选评分上限更高的组合是聪明做法。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心功能拆解与数据库建模
2.1 用户端核心流程：登录→查询→预约→积分
用户端的业务主线是四个动作：登录、查询、预约、查看积分。
微信登录这一块要提前搞清楚逻辑：小程序前端调用 wx.login() 拿到临时code，传给后端，后端用code向微信接口换取openid，再用openid去用户表查有没有这个用户，没有就自动注册，最后返回自定义token给前端。这个流程里最容易被坑的是没有配置AppID和AppSecret，或者把接口请求域名配错了，导致真机调试一直报“获取登录后的微信用户失败”。解决方法是：开发阶段在微信公众平台把“不校验合法域名”打开，同时后端做好测试接口的兼容。
分类指南模块，数据不能写死在前端，要放在后端数据库里，通过接口动态获取。因为垃圾类别和具体物品名称是会变化的，比如“小龙虾壳”到底是厨余垃圾还是其他垃圾，不同城市规定还不一样。所以数据表设计要考虑“城市”这个维度，或者至少预留一个扩展字段。
预约回收是核心交易流程。用户选择可回收垃圾品类（纸类、塑料、金属、织物等），填写上门地址、联系人和期望上门时间，提交后生成预约单。这里要注意库存逻辑：某些品类可能暂时不回收，需要状态管理来避免前端展示误导。简单做法是给回收品类表加一个“是否开启回收”的布尔字段，后台可控。
积分模块是给系统“加戏”的。用户完成一次回收后获得积分，积分可以在后续版本对接商城。毕设阶段不需要真的做支付和商品发货，只要积分记录清晰、后台能调整规则就行。
2.2 管理端功能设计：从订单派单到数据统计
管理端建议做成Web页面，原因有三个：一是毕设需要展示“完整的前后端分离能力”，后端接口即可以被小程序调用，也可以被Web后台调用，这本身就是加分项；二是管理后台做数据可视化大屏更自然，ECharts在PC上的展示效果明显好于小程序；三是答辩演示时，一边投屏显示后台操作，一边手机演示小程序，画面感更强。
管理端的功能尽量克制，不要贪多。核心是这几块：
- 仪表盘（数据看板）：今日新增用户、今日预约单量、待处理订单数、累计回收重量（如果有重量数据）、7日趋势折线图、品类占比饼图。
- 订单管理：订单列表按状态筛选（待接单/已接单/已完成/已取消），支持接单、完成、取消操作，订单详情里能看到用户信息和预约地址。
- 品类管理：回收品类的增删改查，配置单价、是否启用、排序。
- 用户管理：用户列表、禁用/启用账号、查看用户积分明细。
- 积分规则：配置每单获得积分的基础值、上下浮动条件。
2.3 数据库表设计与关键字段说明
数据库设计是毕设文档里的核心章节，表设计得好不好，直接决定后面所有业务逻辑的清晰程度。我按实际开发经验列一下核心表和关键字段。
用户表 t_user
sql复制CREATE TABLE `t_user` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`openid` varchar(64) NOT NULL COMMENT '微信openid',
`nickname` varchar(64) DEFAULT '' COMMENT '昵称',
`avatar` varchar(255) DEFAULT '' COMMENT '头像URL',
`phone` varchar(20) DEFAULT '' COMMENT '手机号',
`status` tinyint(4) DEFAULT 1 COMMENT '1正常 0禁用',
`create_time` datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_openid` (`openid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
回收品类表 t_category：核心字段是 name（品类名）、price（参考单价）、unit（单位）、enabled（是否启用）。注意价格字段用decimal而不是float，避免浮点数精度问题。
预约订单表 t_order：核心字段是 order_no（订单号，用时间戳+随机数生成）、user_id、category_id、address、contact_name、contact_phone、appoint_time（期望上门时间）、status（0待接单、1已接单、2已完成、3已取消）、remark。这里要加索引 idx_user_id 和 idx_status，因为业务查询基本都是按用户或者按状态走。
垃圾分类表 t_garbage_item：核心字段是 name（垃圾名称）、category（所属分类，可枚举：可回收/厨余/有害/其他）、detail（说明）、city（城市，默认全国通用）。
积分记录表 t_integral_log：核心字段是 user_id、order_id（关联订单，便于溯源）、change_type（1获得 2消耗）、value、remark。
这五张表是最小闭环，再加上管理员表 t_admin 就够了，不需要过度设计。一个关键提醒：很多同学喜欢在表里塞外键和触发器，毕设里完全没必要。用逻辑外键，通过MyBatis-Plus查询时自己关联，减少数据库层面的耦合，反而好维护。
3. 关键技术实现与实操过程
3.1 微信小程序前端开发：页面结构与接口封装
小程序前端我建议直接用微信开发者工具创建“原生小程序”项目，不要用云开发。用云开发省了后端，但你的毕设亮点就少了一大块，答辩时老师一眼看出没有真正的服务端。老老实实用原生 + HTTPS接口对接自己的Spring Boot后端。
目录结构按业务划分：
code复制/pages
/index 首页（垃圾分类指南入口+快捷预约入口）
/search 搜索垃圾名称
/recycle 预约回收（选品类、填地址）
/order 我的预约列表
/mine 个人中心
/login 登录页（可以并入mine）
/utils
request.js 封装的wx.request请求
auth.js token存取与登录态判断
request.js封装时要注意两件事。第一，所有请求带上token，放在header里；后端统一从header解析token得到用户信息。第二，请求401时要做全局处理，跳转登录页重新授权。这个封装逻辑是所有小程序项目的通用骨架，学会了以后做任何小程序都用得上。
示例代码片段：
javascript复制const request = (url, method, data) => {
return new Promise((resolve, reject) => {
const token = wx.getStorageSync('token')
wx.request({
url: BASE_URL + url,
method: method || 'GET',
data: data || {},
header: {
'Content-Type': 'application/json',
'Authorization': token ? 'Bearer ' + token : ''
},
success: (res) => {
if (res.data.code === 401) {
wx.removeStorageSync('token')
wx.navigateTo({ url: '/pages/login/login' })
reject(res.data)
} else if (res.data.code === 200) {
resolve(res.data)
} else {
wx.showToast({ title: res.data.msg, icon: 'none' })
reject(res.data)
}
},
fail: (err) => {
wx.showToast({ title: '网络异常', icon: 'none' })
reject(err)
}
})
})
}
预约回收页面的表单要特别注意“期望上门时间”的选择。不要用 <picker mode="date"> 只选日期，最好加上时间段选择，因为回收员上门需要时间窗口。这个细节虽然小，但在答辩演示时能体现你考虑业务的完整性。
3.2 后端接口开发与角色权限控制
后端按模块拆包：
code复制com.example.recycle
/controller
UserController.java
CategoryController.java
OrderController.java
GarbageController.java
AdminController.java
/service
/mapper
/entity
/config
/common
JwtUtil.java
Result.java
AuthInterceptor.java
用户端和管理端共用一套接口，通过@RequireRole注解区分。用户接口需要登录态，管理员接口需要管理员token。我用JWT生成token，用户token的payload里带userId和role两个字段，管理员token的role字段是admin。拦截器拦截请求后解析token，把用户信息放到ThreadLocal里，后续业务逻辑直接取。
这里分享一个我踩过的坑：Spring Boot拦截器注册时，静态资源和登录接口要放行，否则小程序调登录接口会一直被拦截。配置放行路径时注意，/api/user/login这种接口放行要精确匹配，而/api/admin/**全部拦截。
java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(authInterceptor())
.addPathPatterns("/api/**")
.excludePathPatterns("/api/user/login")
.excludePathPatterns("/api/garbage/list")
.excludePathPatterns("/api/garbage/search");
}
}
预约下单接口要注意重复提交问题。用户如果连续点了两次“提交预约”，会生成两条一模一样的订单。解决思路很简单：前端在提交按钮上加防重复点击状态，后端在接口里判断同一用户5秒内不能重复提交相同品类和地址的订单。这个并发问题不复杂，但能体现你考虑问题够不够细。
3.3 垃圾分类词库的获取：爬虫方案的取舍与合规实践
垃圾分类指南里需要大量的“垃圾名称→分类”数据。手动录入几百条不现实，这时候就显示出爬虫的价值了。
网上有一些公开的垃圾分类查询网站，它们的数据接口是JSON格式。你可以写一个Python爬虫调接口拉取数据，清洗后导成SQL脚本，插进t_garbage_item表。这个思路在答辩时也是一个亮点——说明你不是只会Java后端，还具备Python数据处理能力。
但我要提醒几点合规事项。第一，只爬公开的、非加密的查询接口，不碰需要登录、有验证码、有明显反爬机制的平台，更不要爬个人隐私数据。第二，爬取频率要低，加延时，不要给对方服务器造成压力。第三，数据仅用于学习研究，不商用，不传播原始数据集。
爬虫代码的逻辑很简单，核心就是请求→解析→存储：
python复制import requests
import json
import pymysql
# 假设目标接口返回JSON
url = "https://example.com/api/garbage/search?keyword={keyword}"
headers = {"User-Agent": "Mozilla/5.0"}
def fetch_and_save(keyword_list):
conn = pymysql.connect(host="localhost", user="root", password="123456", database="recycle_db")
cursor = conn.cursor()
for keyword in keyword_list:
try:
resp = requests.get(url.format(keyword=keyword), headers=headers, timeout=10)
data = resp.json()
for item in data.get("data", []):
sql = "INSERT INTO t_garbage_item (name, category, detail) VALUES (%s, %s, %s)"
cursor.execute(sql, (item["name"], item["category"], item.get("detail", "")))
time.sleep(1) # 控制节奏，尊重目标服务器
except Exception as e:
print(f"抓取 {keyword} 失败: {e}")
conn.commit()
cursor.close()
conn.close()
如果你不想碰爬虫，也有替代方案：直接搜索“垃圾分类数据JSON”或者GitHub上的开源词库，很多热心开发者已经整理好了。但注意检查数据的版权和准确率，毕竟你系统里展示的数据要经得起老师抽查。
3.4 数据可视化：让毕设脱颖而出的关键模块
数据可视化是不少同学的弱项。多数人停留在“用表格展示数据”的层面，而用了ECharts的图表仪表盘，项目档次立刻不一样。
我推荐在管理后台首页做四个核心图表：
- 折线图：近7天预约订单量趋势，前端用ECharts的
line类型。 - 饼图：不同垃圾品类的预约占比，前端用
pie类型。 - 柱状图：各社区回收量排行（如果有社区字段），前端用
bar类型。 - 数字卡片：今日预约数、总用户数、总订单数、回收品类数。
接口设计上，后端写一个/api/admin/dashboard聚合接口，一次返回所有图表数据，前端只调一次接口就能渲染整个看板。数据结构类似：
json复制{
"code": 200,
"data": {
"userCount": 1024,
"orderCount": 356,
"todayOrderCount": 12,
"categoryCount": 8,
"sevenDayTrend": [{"date": "2025-03-19", "count": 8}, ...],
"categoryRatio": [{"name": "纸类", "value": 45}, ...],
"communityRank": [{"community": "阳光花园", "count": 23}, ...]
}
}
需要注意一个可视化细节：折线图的日期一定要按时间升序排列，饼图的颜色色系要统一。这些视觉细节直接影响答辩时的第一印象。而且你的图表数据要真实，答辩前最好往数据库里补录几十条测试订单，把趋势线和占比做得丰满一些。
3.5 演示录像制作：录出导师认可的效果
标题里提到“演示录像”，说明这是毕设常见的交付物。很多同学忽略演示录像的重要性，以为交了源码就行。实际上，一份质量高的演示录像能帮你撑过远程答辩，也能让指导老师在前期检查时快速了解你的项目完成度。
录演示视频用OBS Studio或者EV录屏，免费够用。我建议按这个脚本录制，总时长控制在6-10分钟：
- 开场（30秒）：展示项目名称、技术栈。
- 用户端演示（3分钟）：微信开发者工具启动小程序，演示登录、搜索垃圾、预约回收、查看订单。
- 管理端演示（3分钟）：浏览器打开后台，演示登录、查看数据看板、接单并流转状态、新增回收品类。
- 代码亮点展示（1-2分钟）：展示后端接口文档或核心代码段，讲解JWT鉴权和订单状态机。
- 收尾（30秒）：总结实现了哪些功能，扩展方向是什么。
录制时有一个关键操作：手机模拟器里的数据要提前准备好，订单状态要有不同阶段的数据，这样演示时不用现场造数据。很多同学现场登录发现数据库是空的，点哪里都没反应，全程尴尬。真机调试如果出现“获取微信用户失败”，先在本地把登录逻辑调到能通过，再去录视频。
4. 常见问题与排查技巧实录
4.1 微信小程序真机调试常见报错
第一个高频报错是wx1cb4398e1413dce7这种形式的“获取登录后的微信用户失败”。这个报错最常见的原因是：你的小程序在微信公众平台上没有配置正确的AppSecret，或者后端调用jscode2session接口时传的code是空值。排查顺序是：先在微信开发者工具里打印wx.login回调结果，确认code拿到了；再在后端接口里打印传入的code，确认参数没有丢失；最后检查AppID和AppSecret是否匹配、是否在公众平台的“开发管理→开发设置”里正确配置。
第二个高频报错是“不在以下合法域名列表中”。真机运行小程序时，微信强制校验request请求域名必须是在公众平台配置过的HTTPS域名。开发阶段解决方法是：在微信开发者工具右上角“详情→本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。但要注意，这个选项只对开发工具和预览有效，真正提交体验版时必须在公众平台配置合法的HTTPS接口域名。
第三个坑是“顶部导航栏高度适配”。小程序部分页面的自定义导航栏在不同机型上高度不一样，iPhone的刘海屏和安卓的挖孔屏差异很大。如果用自定义导航，可以用wx.getWindowInfo()获取状态栏高度，再动态计算；如果图省事，直接用微信原生导航栏，不去自定义，就完全没这个问题。
4.2 后端运行时的三个经典故障
Java后端项目容易踩的坑，集中在这三个地方。
一个是java.lang.OutOfMemoryError: Insufficient memory。这个错误经常出现在IDEA或Maven编译时，并不是你的代码真的内存溢出了，而是IDEA分配给JVM的堆内存太小。解决方法是：Help→Change Memory Settings把IDEA堆内存调到1024MB或更高；Maven编译则在pom.xml里配置maven-compiler-plugin的fork=true和meminitial/maxmem参数。如果是Spring Boot应用运行时报这个错，就在启动参数里加-Xmx512m -Xms256m。
另一个是Lombok警告“You aren't using a compiler supported by Lombok”。这个问题的根源是JDK版本和Lombok版本不兼容。比如JDK 21配了老版本的Lombok 1.18.24就会报这个错。解决办法是把Lombok升级到1.18.30以上，或者在pom.xml里显式指定高版本。另外一个隐藏坑是Lombok需要IDEA安装插件并开启Annotation Processing，很多同学导入新项目后@Data注解不生效，就是这里没配置。
第三个是跨域问题，Web后台调用后端接口报Access-Control-Allow-Origin错误。Spring Boot跨域配置有两种写法，一种是在Controller类上加@CrossOrigin注解，一种是在WebMvcConfig里统一配置CorsMapping。我推荐用后者，因为一个项目里可能有很多Controller，逐个加注解太丑了。
java复制@Configuration
public class CorsConfig {
@Bean
public CorsFilter corsFilter() {
CorsConfiguration config = new CorsConfiguration();
config.addAllowedOriginPattern("*");
config.addAllowedHeader("*");
config.addAllowedMethod("*");
config.setAllowCredentials(true);
UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
source.registerCorsConfiguration("/**", config);
return new CorsFilter(source);
}
}
4.3 数据准备与演示翻车自救
演示时最尴尬的事情是数据没了，或者数据太假。我的建议是：答辩前一周就往数据库里导入模拟数据，覆盖近30天的场景。模拟数据要有层次，比如订单状态要覆盖待接单、已接单、已完成；用户不少于50个；垃圾分类词条不少于300条。这些数据用SQL脚本批量插入就行。
如果答辩当场出现数据库连接失败或者后端没启动，不要慌，先检查三件事：MySQL服务是否在运行（Windows下服务列表里查看）、后端启动端口是否被占用（netstat -ano | findstr 8080）、配置文件里的数据库账号密码是否正确。这些问题80%都是开发环境重启后忘了启动MySQL或者环境变量有问题导致的，提前写好一个启动脚本能省很多事：
bash复制@echo off
echo 正在启动MySQL...
net start mysql
echo 正在启动Spring Boot服务...
cd /d D:\project\recycle-backend
mvn spring-boot:run
pause
4.4 拿到开源源码后怎么快速跑起来
如果你下载的是别人的毕设源码，第一次跑通往往比重新写还费劲。我建议按这个顺序排查：
- 先看README，没有的话看配置文件。找到
application.yml或application.properties，确认数据库名称、账号、密码。把spring.datasource.url里的数据库名改成你本地建的库。 - 找到
init.sql或schema.sql，在MySQL里执行建表和初始化数据。如果源码没有SQL脚本，打开实体类，根据字段反推建表语句，或者用MyBatis-Plus的代码生成器连数据库自动建表。 - 后端跑起来后，先在浏览器访问
http://localhost:8080/api/garbage/list，看返回的JSON是否正常。这一步能确认后端是否通。 - 小程序端打开
config.js或utils/config.js，把BASE_URL改成你的本地接口地址。开发阶段用http://localhost:8080，但注意真机调试必须用局域网IP，比如http://192.168.1.101:8080。 - 微信开发者工具导入项目后，点击编译。如果白屏，看Console报错，最常见的是
BaseURL不对或者域名校验问题。
5. 答辩前要准备什么：演示流程与高频提问
5.1 答辩演示的标准流程
答辩时间一般控制在10-15分钟，演示节奏很重要。一般来说分四步。
第一步讲选题背景和意义，不要超过2分钟。重点说清楚“解决什么问题”：居民不知道怎么分类、回收预约不方便、社区回收管理缺乏数据支撑。这里不要说套话，用具体场景描述。
第二步讲系统设计，包括技术架构、功能模块、数据库设计。建议提前画好一张系统架构图，不需要多精致，但模块划分要清晰，展示出你确实有整体规划能力。
第三步是现场演示，这是核心。按照前面提到的演示脚本操作一遍，注意不要为了演示单个功能来回切换页面太多，流程顺畅最重要。演示过程中要主动讲操作背后的逻辑，比如“我现在把订单状态改为已完成，这样用户端就能看到积分到账的记录了”，用业务串联代替单纯的点击操作。
第四步是总结与展望，控制在1分钟以内。讲清楚已经完成的内容，再提一两个扩展方向，比如“后续可以接入积分商城”或者“实现智能语音垃圾识别”。不要夸海口，说“后续可以”而不是“我已经实现了”。
5.2 老师喜欢追问的技术细节
根据我在毕设答辩现场的观察，老师最常追问的问题集中在下面几个方向，每个方向都要心里有数。
第一个是登录安全：“token过期时间设的多少？”“refresh token怎么处理？”简单的回答方案：token有效期2小时，用户每次进入小程序检查登录态，过期后自动调用wx.login刷新。只要你确实实现了，就能讲清楚。
第二个是订单状态流转：“如果用户取消订单，积分怎么处理？”你的逻辑里如果没做取消订单加回积分，这里就是漏洞。建议在订单取消时加回积分，或者明确取消订单不送积分，两种方案都行，但答的时候必须自洽。
第三个是数据可视化：“图表的数据是实时查的还是缓存的？”最稳妥的回答是“每次进入看板时实时查询数据库聚合，因为数据量不大，性能没有瓶颈”。如果你在SQL里写了复杂的聚合查询，或者用了Redis缓存，也可以补充说明。
第四个是并发问题：“有没有考虑多人同时下单？”这种问题不用慌，回答角度可以是：小程序端提交按钮有防重复处理，后端MySQL的INSERT和UPDATE是原子操作，同一用户短时间内重复下单通过业务校验拦截。你能说出这些，老师基本不会再追。
5.3 论文写作与项目代码的对应关系
很多同学生怕写论文，但毕业论文其实就相当于把做过的项目用文档再讲一遍，有清晰的对应关系。我建议这么对应：
- 第一章绪论：对应选题背景、国内外现状。这里要引用相关文献，比如垃圾分类政策文件、智慧社区建设研究等。
- 第二章关键技术：对应小程序框架、Spring Boot、MyBatis-Plus、ECharts、JWT等。不要只列名词，每个技术写2-3句原理描述和使用理由。
- 第三章需求分析：对应功能模块图、用例图。把用户端、管理端每个功能描述清楚，配业务流程描述。
- 第四章系统设计：对应数据库表结构、接口设计、系统架构。数据库设计的SQL脚本可以放附录。
- 第五章系统实现：对应核心代码、页面截图、关键过程讲解。
- 第六章系统测试：写功能测试用例和结果表，配合真实测试截图。
论文的图表要“少而精”，每张图都有独立编号和文字引用。代码展示不要大段贴，只挑核心的2-3个模块，比如JWT拦截器、订单状态流转、数据聚合查询。
6. 项目上线与后续扩展建议
6.1 怎样把毕设项目变成作品集亮点
毕设做完不是终点，它可以成为你找工作的作品集素材。我的建议是做好两件事。
第一，把项目部署到服务器上，生成一个长期可访问的演示链接。学生服务器很便宜，微信小程序需要HTTPS接口，用Nginx配置SSL证书也不复杂。部署成功后，简历上写“项目已上线，可通过二维码访问”，这个说服力远超“我做过一个管理系统”。
第二，在GitHub上开源你的项目，README写清楚项目简介、技术栈、功能截图、运行步骤。不是让你把源码公开供人抄袭，而是展示你的代码规范度和文档能力。招聘方看到规范的项目文档和清晰的提交记录，印象分很高。
6.2 功能升级路线图参考
如果你做完基础版还有精力，我建议按下面的优先级做扩展。每个扩展点都有独立的展示价值，但工作量不大。
- 积分商城（中优先级）：用户积分兑换优惠券或小礼品，后台可以新增兑换记录表。这个功能很直观，也容易讲。
- 回收员App或小程序（高优先级）：让回收员用手机接单，独立入口，展示完整的角色权限体系设计。
- 垃圾分类AI识别（低优先级但抢眼）：用第三方图像识别API，上传照片返回垃圾分类结果。这个可以调现成接口，作为创新点展示。
- 地图选点与路径规划（中优先级）：在预约页面嵌入地图，展示周边回收站位置。用微信自带
wx.chooseLocation接口就能做到基础版。
我为什么建议按这个优先级排？因为积分类和回收员端直接丰富业务闭环，评委能从中看到你设计了多角色系统；而AI识别虽然炫酷，但属于单独功能，和主业务线联系不紧密。扩展功能要紧扣主业务，不要为了炫技而加不相关的功能。
6.3 关于“白嫖源码”的正确姿势
标题里有“白嫖源码”几个字，说明很多人是先拿一份现成源码再改。我只能说，可以拿源码参考，但绝对不要原封不动提交。真正聪明的做法是：把别人源码的结构和业务逻辑吃透，至少替换30%以上的代码和界面UI，然后加入两到三个别人没有的小功能。这样既避免查重风险，也能在答辩时对每一个代码块都说得清来龙去脉。
而且，改源码的过程本身就是学习。我见过太多同学下载了源码之后，连项目怎么启动都不知道。你至少要能回答：数据库表为什么这么设计？接口为什么这么返回？某个页面跳转时传的参数是什么？这些追问在答辩现场都是高频的。源码是参考，学会是目的，答辩能讲清楚才是最终目标。
写在最后
做“社区垃圾分类与回收服务系统”这个毕设，我最大的体会是：好的毕设项目不是代码写得多炫，而是业务逻辑闭环完整，技术选型合理，展示效果直观。这个题目刚好三个条件都占了。整个开发过程从需求分析到数据库设计，从接口开发到数据可视化，每一步都有实实在在的技术含量，但又不至于让人做不下去。
最后再分享一个实操层面的小建议：不要等到所有功能都完成才开始准备答辩材料，每完成一个模块，就顺手截图、录屏、记录实现思路。后面写论文和做PPT时，这些素材全都是现成的，能省掉大量返工时间。愿你顺利拿下这个项目，答辩那天从容发挥。