简介一份面向Java毕业设计与论文写作的完整参考文档围绕基于SpringBootVue的垃圾分类回收系统展开从课题背景、技术选型到需求分析、概要/详细设计与系统测试均有章节阐述适合正在撰写管理类系统论文或需要对照项目结构补全毕业设计文档的读者。论文按毕业设计规范组织依次覆盖系统概述、开发环境Java、Mysql、SpringBoot、可行性分析、数据库设计、功能模块说明与测试方案并配有目录、关键词、参考文献等可直接借鉴章节编排、图表说明和结论写法。资源共1个doc文件压缩包约2.11MB属于完整论文Word版而非代码工程内容还包含运输管理、字典管理、垃圾回收管理、出库申请等后台与用户端功能描述。目前已有99人学习下载。相比零散代码仓库该论文胜在结构完整、章节对应开发流程尤其适合需要快速搭框架、凑齐毕业设计文档要点的学生参考价值较高。1. “垃圾分类回收系统论文.doc”这个文件名到底在要求你做什么“垃圾分类回收系统论文.doc”这个名字几乎就是毕业设计工作目录里最常出现的那个交付物。后缀是.doc不表示技术旧它提醒你系统开发、测试记录和文档撰写必须是一条流水线而不是代码写完后再补一篇流水账。读这篇文章的人大概率正在做开题或者代码已跑通但不知道论文里的“系统设计”章节怎么写得有说服力。我的建议很直接先不要急着写代码把角色、回收单状态和数据表定下来再动手这样最后产出的doc里每一张 ER 图、测试表和截图才都有真实数据支撑。下文用 Spring Boot Vue 作为实现基线所有 SQL 和接口示例都可以直接改造使用重点放在“论文里要讲得清”的业务闭环上。2. 领域建模与数据表设计先把“回收单状态”定死回收系统本质上和电商系统同构订单是主线。用户提交的是回收单回收员处理的是回收单管理员统计的还是回收单。垃圾从“用户待处理”变成“已回收入库”中间经历的所有状态都应该有明确的字段和时间记录。很多人的论文被提问一下就会露怯因为只会在截图里点按钮说不出当前记录处于哪个状态、为什么这个状态可流转到下一步。所以这一章先解决“状态从哪来、数据存哪里”。2.1 三个业务角色的权限边界怎么划常见做法是按“用户、回收员、管理员”划三个视角不需要额外引入复杂的 RBAC 表在用户表里用一个角色字段就够了。用户视角看到的是垃圾类型查询、预约回收、积分流水回收员视角看到的是待接单列表、称重录入、完成订单管理员视角看到的是类型维护、清运台账和分类准确率报表。这种划分在论文的需求分析章节非常容易描述每个角色对应一组用例用例之间没有交叉操作。开发时也可以把后端接口按/user、/worker、/admin三个前缀组织权限校验统一在一个拦截器里做避免每个 Controller 里重复判断角色。2.2 订单主表和五张关联表的 SQL 设计我习惯先从t_recycle_order反推其他表。订单表必须包含“谁提交、谁回收、什么垃圾、多少重量、多少积分、当前状态、创建时间、完成时间”这些信息。下面这五张表足够覆盖基础演示表名用途核心关联t_user用户、回收员、管理员共用账号体系角色字段区分t_garbage_type垃圾类型及分类说明被订单引用t_recycle_order回收单主流程关联用户和垃圾类型t_integral_log积分流水与订单一一对应关联订单和用户t_feedback用户对分类结果纠错留言关联订单用 MySQL 建订单表的 SQL 建议写成这样CREATE TABLE t_recycle_order ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 主键, order_no VARCHAR(32) NOT NULL COMMENT 回收单号前端展示用, user_id BIGINT NOT NULL COMMENT 提交回收的用户id, receiver_id BIGINT DEFAULT NULL COMMENT 回收员id接单后写入, garbage_type_code VARCHAR(16) NOT NULL COMMENT 垃圾类型编码recyclable/harmful/kitchen/other, weight_kg DECIMAL(10,2) DEFAULT 0.00 COMMENT 实际称重重量单位kg, point_amount INT DEFAULT 0 COMMENT 本次获得的积分, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0待接单 1已接单 2待称重 3已完成 -1已取消, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_user (user_id), KEY idx_status (status) ) COMMENT回收订单主表;这里有三个字段值得在论文里专门解释。garbage_type_code用编码而不是直接用中文名称是为了分类统计时减少脏数据并且和后续的垃圾分类词库保持一致。point_amount虽然可以由weight_kg和类型再次计算但一旦订单完成积分就应当作为既成事实固定下来否则积分流水对账时会出现金额漂移。status加索引是因为业务查询高频按状态过滤后面做回收员“待接单”列表时这就是主要查询条件。2.3 论文里要画的图用例图、ER 图和状态图在很多优秀毕业设计里绘图往往被当作任务完成但你知道这些图的真正作用是约束代码。用例图先画出来接口数量基本就定死了ER 图先画出来表字段就不好随便加状态图先画出来Controller 里就少了很多 if 分支。建议在论文的系统设计里放一张“回收单状态流转图”待接单 → 已接单 → 待称重 → 已完成同时标出每个状态之间的触发动作。这张图的价值在于它能直接指导你写数据库更新语句。比如从待接单变成已接单必须用带WHERE status 0的更新语句防止两个回收员同时抢同一单。这个细节写进论文的“系统实现”部分比贴一屏代码更能打动评阅老师。3. 后端接口实现创建回收单和称重结算要在一个事务里系统能不能演示取决于几个核心接口是否稳。真正的风险点不在 CRUD而在“并发重复提交”和“积分与订单不一致”。本章给出两个可以直接运行的 Spring Boot 接口思路同时把论文里要写的关键判断逻辑讲透。3.1 创建回收单的接口与参数约定用户端预约回收时前端表单只需要提交三个信息垃圾类型编码、预约地址、备注。后端生成唯一单号并把订单状态置为“待接单”。接口定义如下PostMapping(/order/create) public ResultLong createOrder(RequestBody Valid CreateOrderVO vo, RequestAttribute Long userId) { RecycleOrder order new RecycleOrder(); order.setOrderNo(RC System.currentTimeMillis()); order.setUserId(userId); order.setGarbageTypeCode(vo.getGarbageTypeCode()); order.setStatus(0); orderMapper.insert(order); return Result.ok(order.getId()); }这个接口有几个细节。RequestAttribute Long userId来自登录拦截器不要在参数体里信任前端传来的用户 ID否则就是越权漏洞。order_no用时间戳拼接虽然简单但论文里写清运台账时可能会有重复概率建议改成“日期随机数”的格式例如20250507103012A3F1。状态初始值为 0这点不可前端传入后端强制设定保证所有入口都走同一套状态机。3.2 称重完成并发放积分为什么必须加事务回收员点击“确认称重”时系统要同时完成三件事更新订单重量和状态、计算积分、写入积分流水。这三件事只要有一件失败整单都必须回滚。下面是核心代码Transactional public Long confirmWeight(ConfirmWeightVO vo) { RecycleOrder order orderMapper.selectByIdForUpdate(vo.getOrderId()); if (order null || !order.getStatus().equals(2)) { throw new BizException(订单不存在或当前状态不允许称重); } int points PointsCalculator.calc(order.getGarbageTypeCode(), vo.getWeightKg()); order.setWeightKg(vo.getWeightKg()); order.setStatus(3); order.setPointAmount(points); orderMapper.updateById(order); IntegralLog log new IntegralLog(); log.setOrderId(order.getId()); log.setUserId(order.getUserId()); log.setPoints(points); integralLogMapper.insert(log); return order.getId(); }关键在selectByIdForUpdate这一行。它会在事务内锁住这条订单记录另一个回收员如果同时操作同一订单会被阻塞直到事务提交。配合状态判断就能避免“同一袋垃圾被称两次、积分发两次”的问题。积分计算单独抽成PointsCalculator.calc()不要写在 Controller 或 Mapper 里这样后续要调整“塑料瓶每公斤 10 积分”之类规则时只改一个方法即可。3.3 统一返回体让前端协作更省事前后端分离项目里接口返回结构应该固定。我常用ResultT结构包含状态码、提示信息和数据体。常见定义为返回码含义前端处理建议0成功读取 data 渲染4001订单状态错误提示用户刷新列表4002重复提交禁用按钮并提示稍后重试5000服务异常记录日志并展示通用报错如果状态码设计得合理前端几乎不需要通过错误文本来判断逻辑。比如用户重复点击“提交回收单”按钮时后端通过唯一索引捕获重复单号返回 4002前端直接把按钮置灰并提示“正在处理中”。这套规范放到论文的“接口设计”章节比贴十个接口地址有用得多。4. 垃圾分类判断实现用词库匹配构建可演化的分类能力垃圾分类回收系统的核心差异点在“分类”这个动作上。最稳的做法是让用户手动下拉选择垃圾类型但这在论文里没有发挥空间。稍微进阶一点的做法是构建一个垃圾名称关键词库用户输入垃圾名称后系统自动推荐分类。这类规则方案不需要训练模型却能稳定演示而且准确率可统计。4.1 规则优先的分类策略避免一上来就上模型常见误区是直接引入图像识别卷积神经网络训练数据没有、标注成本高、演示现场还可能推理缓慢。对于课设和毕业设计先用“关键词匹配 人工纠错”把闭环打通是性价比最高的路线。系统的垃圾类型按国标四分法分成四类可回收物、有害垃圾、厨余垃圾、其他垃圾。每条垃圾类型记录都维护一个关键词列表比如“矿泉水瓶”属于可回收物“香蕉皮”属于厨余垃圾“过期药片”属于有害垃圾“脏纸巾”属于其他垃圾。论文里可以把这套词库设计成管理后台可增删的配置而不是硬编码在代码里这样就能解释“系统具有可扩展性”。4.2 关键词匹配的分类实现与类型优先级核心匹配逻辑可以写在独立的分类服务里public String classify(String inputText) { String text inputText.toLowerCase(); ListGarbageType types garbageTypeMapper.selectAll(); GarbageType matched null; int maxScore 0; for (GarbageType type : types) { for (String keyword : type.getKeywords()) { if (text.contains(keyword)) { int score type.getPriority() keyword.length(); if (score maxScore) { maxScore score; matched type; } } } } return matched ! null ? matched.getCode() : other; }这段代码里有两个设计点需要解释。第一是priority有害垃圾的优先级必须最高因为“充电电池”同时包含“电池”这个词而普通干电池在其他语境里属于其他垃圾但充电电池应判为有害垃圾。第二是匹配得分关键词越长、越具体得分越高这样“过期药片”不会被“药”这样的短词带偏。最终结果落到other兜底保证系统永远有返回而不是报错。分类关键词可以按下面这个粒度维护垃圾类型典型关键词演示场景可回收物矿泉水瓶、纸箱、易拉罐、旧书、铁皮积分累计最多厨余垃圾剩饭、菜叶、香蕉皮、果核重量型订单有害垃圾充电电池、过期药品、水银温度计、油漆桶高优先级匹配其他垃圾脏纸巾、烟蒂、陶瓷碎片、一次性餐具兜底类目4.3 纠错反馈和准确率报表给论文提供真实数据只做自动判断还不足以支撑论文。我在订单结束后增加了“纠错反馈”功能如果用户或回收员认为分类结果不正确可以通过t_feedback表记录正确类型和错误类型。管理员后台统计分类准确率SELECT COUNT(*) AS total_count, SUM(CASE WHEN feedback.correct_type feedback.guess_type THEN 1 ELSE 0 END) AS correct_count FROM t_feedback WHERE DATE(feedback.create_time) CURDATE();这一段的论文价值很高。你可以整理出一张“分类准确率测试表”输入 100 条垃圾名称记录系统判定、人工判定、是否一致最后算出准确率。只要这个比例在 85% 以上论文测试章节就有话可说如果低于这个值就反向说明需要扩充词库这本身就是系统迭代记录。5. 把系统表现写进论文.doc测试用例图、运行截图和导出技巧论文.doc 最怕出现的问题是“图和表对不上”。这里给出一条保证文档可信度的操作链。5.1 用测试用例表替代大段文字描述测试章节不要写“经测试系统运行良好”这种空话直接用表格记录关键用例。格式可以参照下面的字段用例编号、操作步骤、预期结果、实际结果、是否通过。用例编号操作预期结果实际结果结论TC-01用户提交可回收物预约单生成待接单记录生成单号并处于待接单状态通过TC-02回收员确认称重 2kg 塑料瓶积分入账 20 分积分流水出现 20 分记录通过TC-03重复提交同一订单第二次提交被拒绝返回 4001 状态码通过这些用例最好在系统开发完成后真实执行一遍把每一条对应的数据库查询结果截图保存。论文答辩时老师问任何一个数字你都能现场打开 Navicat 或终端查出同一笔记录。5.2 截图必须四件套对应每个重要功能至少保留四张图前端页面操作图、后端接口返回图、数据库对应记录图、日志输出图。时间要一致最好在同一个时间段内完成这样评阅人能从修改时间反推出测试是真实执行的。推荐统一命名规则比如05-订单称重.png并按论文章节编号归档最终插入 Word 时不会搞混。5.3 导出和排版的两个细节文档要导出为 PDF 再提交但导出前务必更新目录页码Word 里的目录域如果不刷新会带着错误的页码提交。另一个细节是代码截图不要多超过十行代码建议用等宽字体排版到正文里短代码再截图。这样做既控制页数又方便评阅人直接阅读逻辑。本文还有配套的精品资源点击获取 垃圾分类回收系统论文实现：从数据库设计到接口开发
简介一份面向Java毕业设计与论文写作的完整参考文档围绕基于SpringBootVue的垃圾分类回收系统展开从课题背景、技术选型到需求分析、概要/详细设计与系统测试均有章节阐述适合正在撰写管理类系统论文或需要对照项目结构补全毕业设计文档的读者。论文按毕业设计规范组织依次覆盖系统概述、开发环境Java、Mysql、SpringBoot、可行性分析、数据库设计、功能模块说明与测试方案并配有目录、关键词、参考文献等可直接借鉴章节编排、图表说明和结论写法。资源共1个doc文件压缩包约2.11MB属于完整论文Word版而非代码工程内容还包含运输管理、字典管理、垃圾回收管理、出库申请等后台与用户端功能描述。目前已有99人学习下载。相比零散代码仓库该论文胜在结构完整、章节对应开发流程尤其适合需要快速搭框架、凑齐毕业设计文档要点的学生参考价值较高。1. “垃圾分类回收系统论文.doc”这个文件名到底在要求你做什么“垃圾分类回收系统论文.doc”这个名字几乎就是毕业设计工作目录里最常出现的那个交付物。后缀是.doc不表示技术旧它提醒你系统开发、测试记录和文档撰写必须是一条流水线而不是代码写完后再补一篇流水账。读这篇文章的人大概率正在做开题或者代码已跑通但不知道论文里的“系统设计”章节怎么写得有说服力。我的建议很直接先不要急着写代码把角色、回收单状态和数据表定下来再动手这样最后产出的doc里每一张 ER 图、测试表和截图才都有真实数据支撑。下文用 Spring Boot Vue 作为实现基线所有 SQL 和接口示例都可以直接改造使用重点放在“论文里要讲得清”的业务闭环上。2. 领域建模与数据表设计先把“回收单状态”定死回收系统本质上和电商系统同构订单是主线。用户提交的是回收单回收员处理的是回收单管理员统计的还是回收单。垃圾从“用户待处理”变成“已回收入库”中间经历的所有状态都应该有明确的字段和时间记录。很多人的论文被提问一下就会露怯因为只会在截图里点按钮说不出当前记录处于哪个状态、为什么这个状态可流转到下一步。所以这一章先解决“状态从哪来、数据存哪里”。2.1 三个业务角色的权限边界怎么划常见做法是按“用户、回收员、管理员”划三个视角不需要额外引入复杂的 RBAC 表在用户表里用一个角色字段就够了。用户视角看到的是垃圾类型查询、预约回收、积分流水回收员视角看到的是待接单列表、称重录入、完成订单管理员视角看到的是类型维护、清运台账和分类准确率报表。这种划分在论文的需求分析章节非常容易描述每个角色对应一组用例用例之间没有交叉操作。开发时也可以把后端接口按/user、/worker、/admin三个前缀组织权限校验统一在一个拦截器里做避免每个 Controller 里重复判断角色。2.2 订单主表和五张关联表的 SQL 设计我习惯先从t_recycle_order反推其他表。订单表必须包含“谁提交、谁回收、什么垃圾、多少重量、多少积分、当前状态、创建时间、完成时间”这些信息。下面这五张表足够覆盖基础演示表名用途核心关联t_user用户、回收员、管理员共用账号体系角色字段区分t_garbage_type垃圾类型及分类说明被订单引用t_recycle_order回收单主流程关联用户和垃圾类型t_integral_log积分流水与订单一一对应关联订单和用户t_feedback用户对分类结果纠错留言关联订单用 MySQL 建订单表的 SQL 建议写成这样CREATE TABLE t_recycle_order ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 主键, order_no VARCHAR(32) NOT NULL COMMENT 回收单号前端展示用, user_id BIGINT NOT NULL COMMENT 提交回收的用户id, receiver_id BIGINT DEFAULT NULL COMMENT 回收员id接单后写入, garbage_type_code VARCHAR(16) NOT NULL COMMENT 垃圾类型编码recyclable/harmful/kitchen/other, weight_kg DECIMAL(10,2) DEFAULT 0.00 COMMENT 实际称重重量单位kg, point_amount INT DEFAULT 0 COMMENT 本次获得的积分, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0待接单 1已接单 2待称重 3已完成 -1已取消, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_user (user_id), KEY idx_status (status) ) COMMENT回收订单主表;这里有三个字段值得在论文里专门解释。garbage_type_code用编码而不是直接用中文名称是为了分类统计时减少脏数据并且和后续的垃圾分类词库保持一致。point_amount虽然可以由weight_kg和类型再次计算但一旦订单完成积分就应当作为既成事实固定下来否则积分流水对账时会出现金额漂移。status加索引是因为业务查询高频按状态过滤后面做回收员“待接单”列表时这就是主要查询条件。2.3 论文里要画的图用例图、ER 图和状态图在很多优秀毕业设计里绘图往往被当作任务完成但你知道这些图的真正作用是约束代码。用例图先画出来接口数量基本就定死了ER 图先画出来表字段就不好随便加状态图先画出来Controller 里就少了很多 if 分支。建议在论文的系统设计里放一张“回收单状态流转图”待接单 → 已接单 → 待称重 → 已完成同时标出每个状态之间的触发动作。这张图的价值在于它能直接指导你写数据库更新语句。比如从待接单变成已接单必须用带WHERE status 0的更新语句防止两个回收员同时抢同一单。这个细节写进论文的“系统实现”部分比贴一屏代码更能打动评阅老师。3. 后端接口实现创建回收单和称重结算要在一个事务里系统能不能演示取决于几个核心接口是否稳。真正的风险点不在 CRUD而在“并发重复提交”和“积分与订单不一致”。本章给出两个可以直接运行的 Spring Boot 接口思路同时把论文里要写的关键判断逻辑讲透。3.1 创建回收单的接口与参数约定用户端预约回收时前端表单只需要提交三个信息垃圾类型编码、预约地址、备注。后端生成唯一单号并把订单状态置为“待接单”。接口定义如下PostMapping(/order/create) public ResultLong createOrder(RequestBody Valid CreateOrderVO vo, RequestAttribute Long userId) { RecycleOrder order new RecycleOrder(); order.setOrderNo(RC System.currentTimeMillis()); order.setUserId(userId); order.setGarbageTypeCode(vo.getGarbageTypeCode()); order.setStatus(0); orderMapper.insert(order); return Result.ok(order.getId()); }这个接口有几个细节。RequestAttribute Long userId来自登录拦截器不要在参数体里信任前端传来的用户 ID否则就是越权漏洞。order_no用时间戳拼接虽然简单但论文里写清运台账时可能会有重复概率建议改成“日期随机数”的格式例如20250507103012A3F1。状态初始值为 0这点不可前端传入后端强制设定保证所有入口都走同一套状态机。3.2 称重完成并发放积分为什么必须加事务回收员点击“确认称重”时系统要同时完成三件事更新订单重量和状态、计算积分、写入积分流水。这三件事只要有一件失败整单都必须回滚。下面是核心代码Transactional public Long confirmWeight(ConfirmWeightVO vo) { RecycleOrder order orderMapper.selectByIdForUpdate(vo.getOrderId()); if (order null || !order.getStatus().equals(2)) { throw new BizException(订单不存在或当前状态不允许称重); } int points PointsCalculator.calc(order.getGarbageTypeCode(), vo.getWeightKg()); order.setWeightKg(vo.getWeightKg()); order.setStatus(3); order.setPointAmount(points); orderMapper.updateById(order); IntegralLog log new IntegralLog(); log.setOrderId(order.getId()); log.setUserId(order.getUserId()); log.setPoints(points); integralLogMapper.insert(log); return order.getId(); }关键在selectByIdForUpdate这一行。它会在事务内锁住这条订单记录另一个回收员如果同时操作同一订单会被阻塞直到事务提交。配合状态判断就能避免“同一袋垃圾被称两次、积分发两次”的问题。积分计算单独抽成PointsCalculator.calc()不要写在 Controller 或 Mapper 里这样后续要调整“塑料瓶每公斤 10 积分”之类规则时只改一个方法即可。3.3 统一返回体让前端协作更省事前后端分离项目里接口返回结构应该固定。我常用ResultT结构包含状态码、提示信息和数据体。常见定义为返回码含义前端处理建议0成功读取 data 渲染4001订单状态错误提示用户刷新列表4002重复提交禁用按钮并提示稍后重试5000服务异常记录日志并展示通用报错如果状态码设计得合理前端几乎不需要通过错误文本来判断逻辑。比如用户重复点击“提交回收单”按钮时后端通过唯一索引捕获重复单号返回 4002前端直接把按钮置灰并提示“正在处理中”。这套规范放到论文的“接口设计”章节比贴十个接口地址有用得多。4. 垃圾分类判断实现用词库匹配构建可演化的分类能力垃圾分类回收系统的核心差异点在“分类”这个动作上。最稳的做法是让用户手动下拉选择垃圾类型但这在论文里没有发挥空间。稍微进阶一点的做法是构建一个垃圾名称关键词库用户输入垃圾名称后系统自动推荐分类。这类规则方案不需要训练模型却能稳定演示而且准确率可统计。4.1 规则优先的分类策略避免一上来就上模型常见误区是直接引入图像识别卷积神经网络训练数据没有、标注成本高、演示现场还可能推理缓慢。对于课设和毕业设计先用“关键词匹配 人工纠错”把闭环打通是性价比最高的路线。系统的垃圾类型按国标四分法分成四类可回收物、有害垃圾、厨余垃圾、其他垃圾。每条垃圾类型记录都维护一个关键词列表比如“矿泉水瓶”属于可回收物“香蕉皮”属于厨余垃圾“过期药片”属于有害垃圾“脏纸巾”属于其他垃圾。论文里可以把这套词库设计成管理后台可增删的配置而不是硬编码在代码里这样就能解释“系统具有可扩展性”。4.2 关键词匹配的分类实现与类型优先级核心匹配逻辑可以写在独立的分类服务里public String classify(String inputText) { String text inputText.toLowerCase(); ListGarbageType types garbageTypeMapper.selectAll(); GarbageType matched null; int maxScore 0; for (GarbageType type : types) { for (String keyword : type.getKeywords()) { if (text.contains(keyword)) { int score type.getPriority() keyword.length(); if (score maxScore) { maxScore score; matched type; } } } } return matched ! null ? matched.getCode() : other; }这段代码里有两个设计点需要解释。第一是priority有害垃圾的优先级必须最高因为“充电电池”同时包含“电池”这个词而普通干电池在其他语境里属于其他垃圾但充电电池应判为有害垃圾。第二是匹配得分关键词越长、越具体得分越高这样“过期药片”不会被“药”这样的短词带偏。最终结果落到other兜底保证系统永远有返回而不是报错。分类关键词可以按下面这个粒度维护垃圾类型典型关键词演示场景可回收物矿泉水瓶、纸箱、易拉罐、旧书、铁皮积分累计最多厨余垃圾剩饭、菜叶、香蕉皮、果核重量型订单有害垃圾充电电池、过期药品、水银温度计、油漆桶高优先级匹配其他垃圾脏纸巾、烟蒂、陶瓷碎片、一次性餐具兜底类目4.3 纠错反馈和准确率报表给论文提供真实数据只做自动判断还不足以支撑论文。我在订单结束后增加了“纠错反馈”功能如果用户或回收员认为分类结果不正确可以通过t_feedback表记录正确类型和错误类型。管理员后台统计分类准确率SELECT COUNT(*) AS total_count, SUM(CASE WHEN feedback.correct_type feedback.guess_type THEN 1 ELSE 0 END) AS correct_count FROM t_feedback WHERE DATE(feedback.create_time) CURDATE();这一段的论文价值很高。你可以整理出一张“分类准确率测试表”输入 100 条垃圾名称记录系统判定、人工判定、是否一致最后算出准确率。只要这个比例在 85% 以上论文测试章节就有话可说如果低于这个值就反向说明需要扩充词库这本身就是系统迭代记录。5. 把系统表现写进论文.doc测试用例图、运行截图和导出技巧论文.doc 最怕出现的问题是“图和表对不上”。这里给出一条保证文档可信度的操作链。5.1 用测试用例表替代大段文字描述测试章节不要写“经测试系统运行良好”这种空话直接用表格记录关键用例。格式可以参照下面的字段用例编号、操作步骤、预期结果、实际结果、是否通过。用例编号操作预期结果实际结果结论TC-01用户提交可回收物预约单生成待接单记录生成单号并处于待接单状态通过TC-02回收员确认称重 2kg 塑料瓶积分入账 20 分积分流水出现 20 分记录通过TC-03重复提交同一订单第二次提交被拒绝返回 4001 状态码通过这些用例最好在系统开发完成后真实执行一遍把每一条对应的数据库查询结果截图保存。论文答辩时老师问任何一个数字你都能现场打开 Navicat 或终端查出同一笔记录。5.2 截图必须四件套对应每个重要功能至少保留四张图前端页面操作图、后端接口返回图、数据库对应记录图、日志输出图。时间要一致最好在同一个时间段内完成这样评阅人能从修改时间反推出测试是真实执行的。推荐统一命名规则比如05-订单称重.png并按论文章节编号归档最终插入 Word 时不会搞混。5.3 导出和排版的两个细节文档要导出为 PDF 再提交但导出前务必更新目录页码Word 里的目录域如果不刷新会带着错误的页码提交。另一个细节是代码截图不要多超过十行代码建议用等宽字体排版到正文里短代码再截图。这样做既控制页数又方便评阅人直接阅读逻辑。本文还有配套的精品资源点击获取