做了几个工程类项目之后越来越觉得智能垃圾分类管理系统这类题目特别值得写一写。一方面它踩中了环保和智慧城市的热点另一方面从技术角度看Spring Boot 后端 管理后台 用户端小程序/App 的结构几乎覆盖了 Java 毕业设计最核心的技能点权限认证、数据统计、定时任务、接口文档、日志记录甚至还能往上加点消息队列和物联网设备模拟。所以很多同学选这个题不是因为它简单而是因为它好扩展、好答辩、好找工作。这篇博文我就把自己做这个系统的完整思路、核心模块的落地细节以及踩过的坑一起整理出来给正在做类似项目的朋友一个可以直接参考的样本。1. 项目定位与整体设计思路1.1 核心需求解析不只是增删改查刚拿到智能垃圾分类管理系统这个题目时容易把它理解成一个普通的信息管理平台管理员维护垃圾类别、用户查看分类指南、记录投放情况。但智能这两个字决定了系统不可能只是几张表的 CRUD。真正让这个项目有含金量的是下面几个层次的需求。第一个层次是基础数据管理。垃圾类别不是简单的四分类就完事国标里垃圾类别下面还有细分条目比如可回收物下面有废纸、塑料、玻璃、金属、织物有害垃圾下面有废电池、废灯管、过期药品等。每一类垃圾需要记录名称、所属类别、详细说明、投放提示、图片样例甚至降解周期这类科普信息。这些数据是后续所有智能功能的基础设计上必须留有扩展字段。第二个层次是业务闭环。系统不能只教人怎么分类还得管住分类之后发生了什么。投放记录、积分奖励、积分商城、违规记录这些是让用户愿意使用系统的核心机制。我在设计时定了一个原则每一次投放行为必须在系统里有完整痕迹包括投放人、投放点、垃圾类别、重量或数量、审核状态、获得的积分。这样管理员端才能做数据分析用户端才有参与感。第三个层次才是真正的智能体现。这里我不建议一上来就搞人工智能算法因为在有限的开发周期里这样做风险很大。我在项目中做了两个务实的智能功能一个是基于规则引擎的垃圾类别推荐用户输入垃圾名称系统通过分词匹配加同义词库推荐分类准确率能做到八成以上另一个是区域投放热力图分析通过统计各投放点的频次和时间段数据辅助管理员调整清运排班和宣传策略。1.2 技术选型为什么是 Spring Boot 2.7.18 MyBatis-Plus技术选型是整个项目最先要定的事。我最终选择了 Spring Boot 2.7.18、MyBatis-Plus 3.5.x、MySQL 8.0、Redis、Spring Security JWT 这套组合前端采用 Vue 3 Element Plus 做管理后台用户端做成微信小程序。这套选型几乎覆盖了企业级开发的主流技术栈又能控制在毕业设计的合理工作量内。Spring Boot 版本选 2.7.18 而不是 3.x是因为 2.7.18 是 2.x 系列的最后一个版本稳定且生态兼容性最好。很多第三方框架如 Activiti、Flowable 对 Spring Boot 3.x 的适配还不完善网上能找到的资料绝大多数也是基于 2.x。更重要的是如果以后做微服务改造2.7.x 可以平滑过渡到 Spring Cloud Alibaba。踩过一次 Spring Boot 3.2 JDK 17 老版本 MyBatis-Plus 的兼容性坑之后我对选型的认识就是不要为了新而新。MyBatis-Plus 在中小型管理系统里的优势太明显了。Wrapper 条件构造器省掉大量 XML 编写工作分页插件一行配置就能用字段自动填充处理 create_time、update_time 这类公共字段非常顺手。这些能力能省下至少三分之一的数据层开发时间把精力留给业务逻辑。1.3 系统功能结构梳理整个系统按角色分成三类使用者普通用户、小区管理员、系统管理员。普通用户通过小程序完成注册登录、垃圾分类查询、扫码投放、积分查询和兑换小区管理员负责审核投放记录、处理违规事件、管理投放点设备和查看本区域统计数据系统管理员负责全局数据维护、用户管理、积分规则配置、数据大屏和系统设置。为了让读者对系统全貌有个直观概念我把核心功能模块整理成下面的表格模块功能点关联角色用户认证模块小程序登录、手机号绑定、JWT 签发、角色鉴权所有角色垃圾分类库垃圾条目维护、类别管理、同义词库、图片素材系统管理员投放管理投放点管理、扫码投放、投放记录、异常上报用户、小区管理员积分系统积分获取规则、积分流水、积分商城、兑换管理所有角色设备管理智能垃圾桶信息、桶满状态上报、离线告警系统管理员、小区管理员数据统计分类正确率、区域热力数据、每日投放趋势、报表导出系统管理员系统管理用户管理、角色管理、操作日志、定时任务配置系统管理员这套结构最妙的地方在于模块之间的耦合度很低每个模块都能单独拿出来深挖作为论文的创新点。比如设备管理模块可以接入物联网模拟器数据统计模块可以做 ECharts 可视化大屏积分系统可以扩展成完整的商城。这就是我常说的一个题目能吃透整个技术栈。2. 数据库建模与表结构设计2.1 核心表设计与字段说明数据库设计是这个项目最不能省步骤的环节。表结构定不好后面写业务代码时到处都是别扭。我最终设计了 15 张核心表这里挑几张最有代表性的详细说说。用户表t_user除了常规的 id、username、password、phone、avatar 之外我特别加了三个字段openid用于小程序登录points存储当前积分余额region_id关联所在区域。积分余额字段其实是冗余设计理论上可以通过积分流水表聚合算出但考虑到用户中心和个人信息接口要频繁展示积分直接冗余存储能避免大量聚合查询代价只是每次积分变动时要保证事务一致性。垃圾类别表t_category和垃圾条目表t_garbage是多对一关系。t_garbage里除了 name、category_id 之外我加了keywords字段存同义词用逗号分隔比如塑料瓶这条例目的 keywords 可以是矿泉水瓶,饮料瓶,塑料瓶,pet瓶。这个字段是分类推荐功能的数据基础。另外还设计了recycle_method、degrade_cycle这类科普字段方便小程序端展示详细的投放指导。投放记录表t_delivery_record是整个系统数据量增长最快的表也是统计报表的数据来源。字段设计上我特意包含了三类维度人的维度user_id、地点维度device_id、region_id、物和行为的维度garbage_id、category_id、weight、image_url、status。status 字段用整型表示状态0 待审核、1 已通过、2 已驳回、3 违规。审核逻辑上普通用户投放后需要小区管理员确认这既保证了数据的真实性也让系统多了一个管理端角色功能上更丰满。积分流水表t_points_log单独建表非常关键。它的字段包括 user_id、change_type、change_value、balance_after、related_id。related_id 是业务关联字段记录这条积分变化是因为哪笔投放、哪次兑换产生的。这样用户查询积分明细时可以直接从这张表里拉出完整的业务轨迹。change_type 用字典值区分投放获得、兑换扣除、签到奖励、违规扣除、管理员调整。2.2 数据库设计的三个关键决策第一个关键决策是设备表和投放点表分开设计。投放点是一个物理位置可能在小区南门也在北门一个投放点可以有多台设备。如果合并成一张表设备更换时投放点的历史数据关联会变得非常麻烦。分开设计后用 device_id 关联设备可以停用、更换历史投放记录不受影响。第二个关键决策是整型枚举字段全部使用代码字典表管理。MySQL 没有原生的枚举类型扩展性好的方案Java 端用枚举类又不利于运营同学配置。我建了一张t_dict字典表维护所有枚举字段的取值和中文描述。以投放记录的 status 字段为例字典表里有对应记录0 待审核、1 已通过、2 已驳回、3 违规。后端提供字典查询接口前端拿到字典后渲染下拉框和标签改文案不用改代码非常方便。第三个决策是统一使用逻辑删除。所有业务表都加入deleted字段配合 MyBatis-Plus 的 TableLogic 注解。这个决策在遇到麻烦时才能体现出价值——比如误删了一个垃圾类别开发环境里可以直接从数据库捞回来不影响演示数据完整性。物理删除会把相关联的投放记录置成悬空引用排查问题的成本远高于多存一个字段的成本。2.3 索引设计与 SQL 层的性能考量系统上线初期可能只有几千条数据但毕业论文答辩时评审老师大概率会问数据量大了性能怎么保证。所以我在表设计阶段就提前准备了索引和慢查询优化方案这也是体现数据库设计功底的地方。常规的索引规则是查询频繁的字段建索引、联合查询的字段建联合索引、区分度低的字段不建索引。放在这个项目里t_delivery_record表的user_id、device_id、status一定要建索引t_points_log表的user_id和create_time要建联合索引支撑查某用户的积分流水并按时间排序这类高频查询。统计类 SQL 也要提前验证执行计划。比如按周统计各类垃圾投放量的语句如果直接在t_delivery_record上做 GROUP BY随着数据量增长会越来越慢。我在实际项目中预跑了一遍 EXPLAIN发现用不上索引时就改成了冗余每日汇总表策略定时任务每天晚上把当天的投放记录按 category_id 聚合后写入t_daily_statistics报表查询直接查汇总表性能问题从根上解决。3. 后端核心功能模块实现3.1 Spring Boot 项目初始化与公共配置项目搭建从 Spring Initializer 开始这个环节有几个容易踩坑的细节。Java 版本我选的 JDK 8因为 Spring Boot 2.7.x 对 JDK 8 的支持最稳定本地环境和服务器环境都不容易出幺蛾子。打包方式选择 jar部署时一条 java -jar 命令就搞定。依赖引入上除了基础的 web、validation还要显式引入 mysql-connector-j 和 redis 依赖。YAML 配置文件的拆分是专业项目和 demo 项目的差别。我把配置拆成application.yml总配置、application-dev.yml开发环境配置、application-prod.yml生产环境配置。总配置里放不变的内容比如应用名称、编码、Jackson 配置。环境配置文件里放数据库连接、Redis 连接、日志级别这类随环境变化的内容。启动时通过--spring.profiles.activedev指定使用哪个环境非常清爽。公共配置里有一个容易被忽略但很重要的点统一响应体。我定义了一个ApiResultT类包含 code、message、data 三个字段所有接口都返回这个结构。配合全局异常处理器RestControllerAdvice业务异常抛出后统一转成规范的响应格式前端 axios 拦截器统一处理错误码。这套东西定好之后后面写所有 Controller 都只需要关注业务逻辑本身。3.2 基于 JWT 的认证与权限控制认证方案我选的是 Spring Security JWT而不是简单的拦截器加 Token。Spring Security 虽然学习曲线陡峭但它提供的过滤器链、方法级权限注解、密码加密工具BCryptPasswordEncoder都是企业级项目的标配。用它对标简历上的技术描述含金量完全不一样。核心实现逻辑是这样的用户登录成功后后端用用户的 id、角色和过期时间生成 JWT Token 返回给前端。前端每次请求在 Authorization 头里带上Bearer token。后端过滤器链中注册一个JwtAuthenticationFilter继承 OncePerRequestFilter在 doFilterInternal 方法里解析 Token、校验签名、加载用户信息到 SecurityContextHolder。权限控制上用PreAuthorize(hasRole(ADMIN))注解做方法级控制。比如删除用户、修改积分规则这类敏感操作只允许管理员角色的用户调用。小程序端用户默认角色是 USER小区管理员是 REGION_ADMIN。角色设计成三档既不会太复杂又能让评审老师看到你考虑了权限层级划分。这里有一个特别容易踩的细节放行接口白名单必须在 SecurityConfig 里配置好同时 Swagger 相关接口也要放行。我在项目里配的过滤白名单包括/api/auth/auth/login、/api/auth/register、/doc/**Swagger 文档、/api/category/list分类列表不需要登录就能查。如果忘了放行 Swagger启动项目后访问文档页面永远报 401排查起来特别浪费时间。3.3 垃圾分类推荐功能的规则引擎实现这个模块是最能体现智能二字的也是答辩时最能讲的点。我的实现方案是三步走分词匹配、同义词扩展、规则兜底。用户在前端输入矿泉水瓶应该扔哪个桶后端先做文本预处理把输入内容切分成关键词。这一步我用的是轻量级的分词工具把句子按常见停用词表切分然后逐个匹配垃圾条目表里的 name 和 keywords 字段。匹配优先级从高到低依次是name 完全匹配、keywords 完全匹配、name 模糊匹配、keywords 模糊匹配。为了防止精确匹配失败导致用户得不到答案我设计了一个兜底机制。如果以上四层匹配都失败系统会检查输入文本中是否包含类别相关的特征词比如输入里有电池两个字就命中有害垃圾类别下的废电池条目。如果连特征词都匹配不到就返回一个友好提示引导用户查看完整分类指南。同义词库的维护是提升召回率的核心。我在管理后台做了一个关键词池子运营同学可以不断往垃圾条目里追加别名。比如废旧报纸这条数据初始设定 keywords 为报纸,旧报纸,废纸,报纸杂志运营发现用户常搜人民日报时可以手动添加进去推荐结果立即生效。这种基于运营反馈迭代的模式比训练一个深度学习模型要可控得多效果却一点不差。3.4 投放记录与积分体系的联动实现投放和积分是两个紧密关联的业务流转。用户在小程序端扫码或手动选择投放点填写垃圾类别和重量上传照片后提交。投放记录生成时的初始状态是待审核积分不变。小区管理员在小程序或管理后台审核通过后系统在一个事务里同时完成三件事更新投放记录状态为已通过、给用户积分余额加上对应分值、在积分流水表里插入一条记录。这个事务的一致性至关重要。我用了 Spring 的Transactional注解保证原子性同时在积分增加时选择先查余额、再算新余额、最后更新的方式避免并发情况下积分错乱。实际开发中还要考虑一个细节积分规则不是写死的比如可回收物每公斤积 10 分、有害垃圾每次投递积 5 分这些规则都存放在t_points_rule表里后台可以动态调整。这样系统运营一段时间后想调激励策略就不需要改代码重新发版了。有些同学可能觉得投递完成就该立刻加积分为什么要加一个审核环节我当时的考量是垃圾分类本身带有较强的公共属性如果全自动加积分用户随便乱传两张照片就能刷分积分商城整个体系就成了摆设。审核环节既保证了数据的真实性也让小区管理员这个角色有了实际工作内容系统功能层次更丰富。3.5 定时任务桶满提醒与数据汇总定时任务在项目里的应用场景主要有两个我采用了 Spring Boot 自带的Scheduled注解方案而不是引入 Quartz 或 XXL-Job。原因是这个项目里的定时任务逻辑都不复杂没有分布式调度、失败重试、分片执行这些高级需求自带的调度器完全够用还少引入一套依赖。第一个定时任务是每 30 分钟扫描一次设备表t_device和投放记录表找出满桶率超过 80% 且状态为正常使用的设备生成清运工单同时通知对应区域的管理员。满桶率怎么算设备表里有个capacity字段记录设备最大容量投放记录表里关联device_id的记录如果状态是已通过就认为这个容量的占用是真实的。实际项目中可以简化一点直接让设备上报剩余容量字段定时任务只做阈值判断和告警通知。第二个定时任务是每天凌晨 2 点执行前一天的投放数据聚合写入t_daily_statistics汇总表。这里我用了一个小技巧定时任务里加上幂等性校验先查询汇总表里当天日期是否已有数据如果存在则先删除再插入。这样做的好处是如果哪天凌晨服务器没开机导致任务没执行第二天管理员手动触发补偿任务时不会产生重复数据。4. 前后端接口设计与关键交互流程4.1 RESTful 接口规范与返回格式接口设计直接影响前端开发的效率。我在项目里定了一套规范化约定所有接口以/api作为统一前缀按模块划分二级路径/api/auth认证模块、/api/category分类模块、/api/delivery投放模块、/api/points积分模块、/api/device设备模块、/api/statistics统计模块。HTTP 方法的使用上也做了严格约定这是很多毕设容易忽略的细节。查询类操作全部用 GET新增操作用 POST修改操作用 PUT删除操作用 DELETE。有些同学喜欢所有操作都用 POST虽然 JWT 鉴权下不会出安全问题但接口语义混乱评审老师一眼就能看出没经过正规项目训练。分页查询的接口参数我也进行了统一。pageNum 代表页码从 1 开始pageSize 代表每页大小排序参数 sortBy 和 order 可选。返回结构统一为{ list, total, pageNum, pageSize }。这套规范和 Element Plus 的表格组件天然契合前端拿到 total 直接赋给分页组件不需要做任何转换。直白点说接口设计规范了前后端联调的时间能减少一半以上。4.2 管理后台的核心页面实现管理后台使用 Vue 3 Element Plus 构建用户登录后根据角色动态渲染左侧菜单。系统管理员看到完整菜单包括数据大屏、投放管理、分类管理、用户管理、积分管理、设备管理、系统设置。小区管理员只看到投放管理、设备管理、区域统计三个菜单。数据大屏是我花时间最多的页面。顶部一排展示今日投放量、今日新增用户、投放分类正确率、累计减碳量四个核心指标卡片中间是一个按小时维度展示投放趋势的折线图下面左侧展示各类垃圾占比的饼图右侧按小区展示投放量排名的柱状图。图表全部用 ECharts 实现数据接口是/api/statistics/overview一次性返回所有指标前端不用多次请求。分类管理页面维护t_category和t_garbage两张表。页面设计成左右结构左侧点选类别右侧展示该类别下所有垃圾条目支持搜索、新增、编辑、批量删除。新增垃圾条目时关键词输入框用逗号分隔多个别名提交后后端自动拆分存入 keywords 字段。这个页面的交互逻辑不复杂但它是分类推荐功能的数据基础细节上必须做到每一步操作都有及时的反馈提示。4.3 小程序端的关键实现细节用户端小程序我采用的是原生小程序语法加 ColorUI 组件库没有引入重量级的 uni-app。原生小程序上手快真机调试方便对毕业生来说学习成本最低。页面结构分成四个 Tab首页、投放、商城、我的。首页是最重要的流量入口设计成搜索框 分类图标 今日科普 投放热榜。搜索框就是分类推荐功能的入口用户输入垃圾名称点击搜索调用后端/api/category/recommend接口返回推荐分类结果和详细投放指南。分类图标用宫格布局展示四分类点击进入对应类别下的详细条目列表。投放页是小程序的高频使用页面。用户选择投放点、选择垃圾类别、填写估算重量、上传现场照片点击提交后生成待审核投放记录。定位功能使用小程序自带接口获取用户经纬度后端根据经纬度计算距离最近的投放点省去用户手动选择的麻烦。照片上传走小程序的 wx.uploadFile 接口后端返回图片访问 URL 后随表单一起提交。商城页面用于积分兑换。商品列表来自后台的t_product表用户用积分兑换后生成兑换记录状态初始为待领取管理人员线下发放后改为已完成。这个模块说实话业务逻辑很简单但它是积分体系的出口没有它积分就只是数字而没有真正的激励价值。在模块设计完整性上这是不可或缺的一环。5. 高频问题与调优经验5.1 部署与运行环境问题大部分同学部署项目是在自己的电脑上演示用 IDEA 按 Run 按钮启动浏览器访问 localhost:8080。但实际部署到云服务器时有几个坑值得提前排掉。Spring Boot 项目打包后是 jar 包启动命令建议加上内存参数java -jar -Xms256m -Xmx512m waste-classification.jar --spring.profiles.activeprod这个参数限制 JVM 最大堆内存为 512MB避免服务器内存不足时 OOM 导致进程被杀掉。使用nohup后台启动时记住把日志输出追加到文件里nohup java -jar xxx.jar app.log 21 数据库连接串上必须添加时区参数。MySQL 8.0 之后不指定 serverTimezone 会直接报错URL 后面拼上?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8前两个参数一个是关闭 SSL 避免警告刷屏一个是让时间显示正确。字符编码参数必须加不加的话存中文容易乱码。另一个非常常见的问题是 Linux 服务器上的权限限制。MySQL 在云服务器上监听地址默认是 127.0.0.1只允许本机访问。如果前端或应用不在同一台机器上连接 MySQL需要修改 MySQL 的 bind-address 配置为 0.0.0.0并创建允许远程访问的数据库账号CREATE USER app% IDENTIFIED BY password;然后授权。这个过程涉及的坑比较多我就简单提一下实际操作时建议单独查资料确认每个版本的差异。5.2 MyBatis-Plus 使用中常见的坑MyBatis-Plus 虽然好用但使用不当容易出隐蔽的 bug。我总结几个高频坑都是自己踩过或帮别人排查过的。第一个坑是分页插件没生效。很多同学导入 PaginationInnerInterceptor 的配置后发现分页查询返回的总数是 0或者根本没有执行 LIMIT 语句。原因多半是 Spring Boot 里配置类的包扫描范围有问题或者配置类没有加Configuration注解被 Spring 容器扫描到。检查思路是先确认配置类有没有被加载再确认版本兼容性。第二个坑是逻辑删除和唯一索引的冲突。比如垃圾条目表的 name 字段建了唯一索引删除一条数据后如果再次插入相同名称的数据会因为在逻辑上原记录并未物理删除而触发唯一索引冲突。解决方案有两个一是唯一索引改成联合索引把 deleted 字段加进去二是插入前先查询一下已删除的同名记录把 deleted 字段重置为 0 做恢复逻辑。第三个坑是字段自动填充失效。TableField(fill FieldFill.INSERT)标记的字段只有 MyBatis-Plus 执行插入操作时才会触发 MetaObjectHandler 的自动填充逻辑。但如果业务代码里用了Version乐观锁或者自带的 ActiveRecord 模式某些场景下自动填充可能不生效。建议所有公共字段的维护不要依赖数据库本身的 DEFAULT 值统一走 MetaObjectHandler保持行为一致性。5.3 部署演示前的环境准备清单答辩前两周就要开始准备演示环境这个准备过程是很多同学最容易忽视的。我在第一次完整演示前吃过亏当天早上才发现 Redis 连不上、MySQL 服务没启动、前端跨域配错手忙脚乱花了半小时才把环境理顺。环境准备清单建议包含以下内容本地开发环境验证完整启动 Spring Boot 项目确认控制台无红色报错Swagger 文档页面可以正常访问数据库数据初始化检查核心业务数据至少准备 200 条投放记录、20 个垃圾类别和 100 条垃圾条目避免演示时页面空空如也没有说服力Redis 服务状态检查用redis-cli ping确认 PONG 返回Redis 缓存了验证码和用户 TokenRedis 挂掉会导致登录功能直接失效前端环境检查npm run build 能正常打包后台静态资源能通过 Nginx 或 Spring Boot 静态资源映射正常访问跨域配置检查如果前后端分离部署在不同端口必须确认后端 CORS 配置正确或者通过 Nginx 反向代理统一端口另外强烈建议准备一份项目部署说明文档内容包括环境要求、数据库初始化脚本位置、配置文件修改说明、启动步骤。这份文档在自己恢复环境和日后答辩时都能起到很好的辅助作用。同时把数据库结构设计说明、核心接口文档整理出来答辩现场如果被提问到技术细节可以边展示文档边回答专业度直接上一个档次。6. 个人实操体会与进一步优化方向做这个项目最大的感受是一个看起来中规中矩的管理系统只要在某些点上比别人多想一步就能拉开差距。比如垃圾分类推荐功能在大多参考代码里可能就是一道 SQL 拼一个 LIKE 查询就完事但我花了两个晚上设计和实现了同义词库加多层匹配规则。不仅演示效果好自己在做这件事的过程中也真正理解了什么是把需求拆解成可落地的技术方案。再比如数据大屏很多毕业设计的数据统计就是给几个数字我用 ECharts 做了折线图、饼图、柱状图的多维度展示还设计了一个区域热力地图。用的技术都是很常见的前端图表库但组合在一起之后系统的整体观感和专业度完全不一样。答辩时我就指着大屏讲解数据流转的完整链路投放动作产生数据、数据入库、定时任务聚合、接口输出、前端可视化。这条链路把后端、数据库、前端三个层面串起来讲一遍比自己干巴巴介绍几张三表结构强太多。项目里还能继续扩展的方向其实非常多这里我把优先级较高的几个列出来后面时间充裕可以按顺序做增强。第一个方向是引入消息队列把投放记录和设备上报这类高频写操作做成异步解耦顺便在项目里展示 RocketMQ 或 RabbitMQ 的集成能力。第二个方向是接入真实的图像识别服务用户拍照上传垃圾图片后端调用识图接口自动判断垃圾类别并回填推荐结果这个功能如果做出来智能的含金量会直线上升但要注意选型时的成本和接口稳定性问题。第三个方向是管理后台集成工作流引擎把投放审核、积分调整申请这些流程建模成可配置的审批流我之前调研过 Flowable 的 Spring Boot 集成概念上是通的但工作流引擎的学习成本较高做之前要评估好投入产出比。最后再分享一个小技巧项目演示时准备两套数据。一套是测试用的脏数据用来演示边界情况和异常处理比如异常的垃圾名称、大文件图片上传、超长文本备注。另一套是精心准备的演示数据垃圾条目名称都改成日常生活中常见且容易混淆的物品分类推荐的结果一眼就能看出准确数据大屏的统计图表也足够饱满。这套细节准备到位演示过程中评委的注意力自然会被项目本身的亮点吸引过去。