企业官网建设流程全解析

简介：基于微信小程序的社区垃圾回收管理系统，是一套面向计算机专业毕业设计、课程设计及项目实战练习的SSM后端源码案例。系统基于Spring、SpringMVC、MyBatis框架构建，完整覆盖用户管理、垃圾回收请求提交、垃圾分类指导、回收任务分配、进度跟踪与数据统计等功能，并借助微信小程序实现便捷的居民端交互。压缩包共916个文件，包括99个Java源文件、111个前端JS、大量SVG/PNG图片、Vue页面、JSON配置、WXML/WXSS小程序页面以及SQL数据库脚本等，总体积约58.9MB，目录结构清晰，便于按模块查阅。目前已有53人学习浏览，项目经严格调试，提供演示视频、使用说明和环境安装说明，能帮助学习者快速跑通环境并理解前后端交互逻辑；通过阅读源码和数据库文件，可深入掌握SSM框架落地方法及小程序与服务端的对接设计，是毕业设计或实战练手的实用资料。

1. 微信小程序 + SSM 做社区垃圾回收：为什么我建议直接拿这套源码改

社区垃圾回收这几年从“小区摆几个分类桶”快速转向“互联网+回收”的模式：居民在小程序里下单，回收员上门取件，废品称重后积分自动到账，积分再换日用品或现金。这套基于微信小程序的社区垃圾回收管理系统，后端用 SSM（Spring + SpringMVC + MyBatis）搭，前端是原生微信小程序，数据库带完整 SQL，属于典型的毕设级全栈案例。我拆完后的判断是：它不是一个只能跑通的 demo，而是一个把业务闭环切齐了的系统——用户端能下单、能查积分、能看回收记录，管理端能审核回收员、能处理订单、能管理商品和积分兑换，整个数据流是通着的。

适合谁？两类人最值。一类是做毕设的在校生，拿它当底子改业务逻辑、换皮肤、补测试，比自己从空项目搭省出两周时间。另一类是刚接触小程序 + SSM 联调的在职新人，想搞明白“小程序里登录态怎么跟后端 session 对上”“MyBatis 的分页跟小程序的分页怎么配合”这些具体问题。先说个反直觉的结论：这套项目里最容易翻车的不是后端接口，而是小程序端的登录态维护和图片上传路径，这两个坑不解决，功能全对上也会被老师或面试官一眼看穿。

2. 系统拆解：用户端、回收员端、管理端的权限模型与数据流

2.1 三种角色如何共用一套登录接口

这套系统没有做成三个独立应用，而是用一个微信小程序承载所有角色，后端通过角色字段区分权限。users 表里有一个 role 字段，取值是 1（普通用户）、2（回收员）、3（管理员），登录后后端把用户信息塞进 session，前端根据角色值渲染不同的 tabBar 和页面入口。这个设计很聪明，避免了维护三套小程序工程的成本，但也带来一个隐藏问题：小程序端切换角色时必须重新登录，否则 session 里的旧角色会污染新请求的权限判断。

用户端核心流程是：打开小程序 → 微信授权登录 → 后端生成 session → 前端存 openid 和 userId → 下单时传 userId + 地址 + 回收品类 → 回收员端接单 → 称重后更新订单状态和用户积分。管理员端则是一套典型的 CRUD 后台：管理回收员档案、管理用户列表、审核回收品类、维护积分商城商品和兑换记录。这里的业务价值点在于订单状态机：待接单 → 已接单 → 已回收 → 已完成，每个状态变更都要同时更新订单表和用户积分表，源码里的事务控制是在 Service 层用 Spring 声明式事务完成的。

2.2 数据库设计：核心表结构与字段边界

数据库里最核心的几张表设计得比较规矩，我给几个关键表和关键字段，方便你改的时候知道动哪里。

积分计算是这套系统里最值得看的逻辑：订单完成时，后端根据 category_id 找到 unit_price，再乘 weight，结果累加到 user 表的 points，同时往 points_record 插一条 positive 记录。兑换商品时反过来，扣 points 插 negative 记录。这种“总余额 + 流水表”双写结构，保证了后续对账和审计有据可依。如果你要扩展业务，建议优先动 points_record 的 type 字段，不要直接改 user.points，否则历史流水会断。

2.3 小程序端页面结构与 wx.request 封装

前端是原生微信小程序，没有用 uni-app 或 Taro，目录结构是标准的 pages / components / utils。utils 里有个 request.js 封装了 wx.request，统一处理 baseURL、请求头、token 注入和错误弹窗。这里有个代码习惯值得抄：它把 code 为 200 的响应才走 success 回调，后端返回的 data 里带的业务码，而不是看 HTTP 状态码判断业务成功与否。

// utils/request.js 核心片段 const BASE_URL = 'http://localhost:8080/api'; function request(url, method, data) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method: method, data: data, header: { 'Content-Type': 'application/json', 'Cookie': wx.getStorageSync('sessionId') // 维护后端 session }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); reject(res.data); } }, fail: (err) => reject(err) }); }); }

这段封装的逻辑在于：把 sessionId 从 storage 里取出来放到 Cookie 头，解决小程序 request 默认不带 Cookie 的问题。后端 SSM 项目里，Spring MVC 的 HttpSession 依赖 Cookie 里的 JSESSIONID，如果前端不手动塞进去，每次请求后端都会创建一个新 session，登录态就彻底废了。你拿到源码后第一件事是全局搜 sessionId 和 JSESSIONID，把这两个名字对齐，否则小程序端登录后接口仍然报未授权。

3. 把项目跑起来：从环境准备到小程序联调

3.1 后端 SSM 环境搭建与参数配置

后端是标准的 Maven 工程，JDK 用 1.8 最稳，Tomcat 8.5 或 9 都行。项目导入 IDE 后先别急着启动，打开 jdbc.properties 改数据库连接。这里有个常见做法：数据库名、用户名、密码写成配置文件，不要硬编码在 Spring 的 XML 里，方便后面切换环境。

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/recycle_db?useUnicode=true&characterEncoding=utf8&useSSL=false jdbc.username=root jdbc.password=123456

MyBatis 的 mapper 文件里有几个动态 SQL，比如订单查询支持按状态和时间段过滤，用的都是 if + where 标签，改的时候注意参数名跟 @Param 注解保持一致。启动顺序是：先建库导入 sql 文件，再启动后端，看到 “SpringMVC 框架加载成功” 之类的日志后，再用 Postman 测一个登录接口，确认返回 JSON 结构再连小程序。我一般会先测/api/user/login，因为它不依赖业务数据，通了这个接口就说明 Spring 容器、MyBatis、数据库连接三层都正常了。

3.2 小程序端 appId 修改与本地联调

小程序端拿到源码后，要改三个地方：app.js 里的 globalData.baseURL 或 utils/request.js 的 BASE_URL、project.config.json 里的 appid、以及详情页里的图片前缀。本地联调时，baseURL 填http://localhost:8080/api只适用于开发者工具，真机预览必须换成局域网 IP，比如http://192.168.1.100:8080/api。这里有个坑：微信开发者工具默认不校验合法域名，但真机上必须勾选“不校验合法域名”才能访问 http 明文接口，否则会报url not in domain list。

登录流程走的是 wx.login 获取 code，然后传给后端的/api/user/login，后端用 code 换取 openid。注意 wx.login 的 code 有效期只有 5 分钟，而且每次调用都会生成新的，不要在页面 onLoad 里提前取好囤着。我见过有人把它存在全局变量里，等用户真正点登录时 code 已经过期，后端调微信接口换 openid 失败，直接返回 500。

3.3 图片上传的两个埋点：本地路径与线上路径

回收品类和商品都需要图片，源码里图片上传是走小程序 wx.chooseImage + wx.uploadFile，后端用 MultipartFile 接收后存到服务器本地磁盘。这里最容易出的问题是你把图片传到了后端所在的磁盘路径，但小程序端访问图片时用的是相对路径或 localhost，真机上一访问就裂图。我一般会在后台上传接口里做个静态资源映射：/upload/**映射到磁盘目录，然后前端拼接的图片 URL 固定为http://服务器IP:8080/upload/xxx.jpg。如果图片显示不出来，先看 Network 面板里的图片请求是否 404，404 基本是路径映射问题，不是图片本身损坏。

4. 避坑指南：这套 SSM + 小程序项目最常见的五个翻车点

4.1 登录状态丢失：每次请求都像新用户

现象：小程序端能登录成功，但进入订单列表页后接口报“未登录”或“用户不存在”。

原因：小程序 wx.request 默认不会主动携带 Cookie，而后端 Spring Session 靠 JSESSIONID 识别用户。前端没有把登录后返回的 sessionId 存入 storage，后续请求自然不带。

解决：在登录接口返回后，把响应头里的 Set-Cookie 中的 JSESSIONID 取出来，存到 wx.setStorageSync。request.js 封装里已经在 header 手动加了 Cookie 字段，确认你取到的 sessionId 名称跟后端一致即可。后端如果设置了 context-path，Cookie 的 path 也要跟着调，否则浏览器或小程序端会丢弃。

4.2 MyBatis 分页查不出数据

现象：订单列表第一页有数据，翻到第二页就空白。

原因：分页参数 pageNum 和 pageSize 没有传到 SQL 的 limit 语句里，或者传的是字符串类型，MyBatis 在做 < 比较时类型不一致直接报错但被前端吞掉了。

解决：查看 mapper 里的 limit #{pageNum}, #{pageSize}，小程序端传参时用 parseInt 转成数字。如果项目里引入了 PageHelper，检查拦截器是否在 mybatis-config.xml 中正确注册，否则分页插件不生效，limit 参数也会失效。

4.3 积分累计与订单状态不同步

现象：订单显示已完成，但用户积分没变，或积分加了两次。

原因：Service 层更新订单状态和插入积分流水没有放在同一个事务里。或者前端在订单完成后同时调了两个接口，导致重复加积分。

解决：检查 OrderService 里完成订单的方法是否标注 @Transactional，这个注解只对 public 方法且通过代理调用时生效。如果方法在类内部被 this 调用，事务会失效。加积分前先查点数记录表，存在就跳过，用唯一索引兜底。

4.4 时间字段差 8 小时

现象：后台看到的订单时间比实际时间早 8 小时。

原因：数据库连接 URL 里没有配置 serverTimezone，MySQL 8 默认用服务器的 UTC 时区，而本机是东八区。另外 JSON 序列化时 Jackson 也可能把 Date 转成时间戳格式，前端拿到后没做时区转换。

解决：jdbc.url 加serverTimezone=Asia/Shanghai，实体类里的日期字段用@JsonFormat(pattern="yyyy-MM-dd HH:mm:ss", timezone="GMT+8")。这两种都改完，前后端时间才能对齐。

4.5 回收员端看不到新订单

现象：用户下单成功，但回收员刷新列表没看到这条订单。

原因：订单查询接口按 recycler_id 过滤，新订单的 recycler_id 还是空值，SQL 用等值匹配查不到。这是典型的权限过滤把业务数据过滤掉了。

解决：查看订单列表接口的查询条件，回收员端查询时改成“recycler_id = 当前用户 OR recycler_id IS NULL”，或者引入 status 字段先查“待接单”状态。这个逻辑如果不动，回收员永远只能看到自己处理过的历史订单。

提示：以上五个问题是我照着这套源码走一遍时实际踩过的点，每一个都能从源码里找到对应位置。如果你跑的过程没遇到，说明你的环境或修改路径绕过了这些分支，但面试或答辩时大概率会被追问，提前想好答案。

5. 二次开发的四个技巧：让这套毕设源码真正变成你的东西

很多同学拿到源码后只会改个颜色和标题，答辩时一问业务细节就卡壳。我建议你照着下面四个方向做二次开发，改动量不大，但能明显提升项目的完成度和答辩说服力。

第一个技巧是给订单模块加“取消订单”的幂等控制。现在常见的做法是用户取消订单直接改状态为已取消，但如果在回收员接单后取消，需要同时释放回收员的待处理任务。你可以加一个操作标记，前端传 cancel_reason，后端在 Service 里判断当前状态是“待接单”才允许取消。这个小功能能引出分布式事务和幂等设计的话题，是答辩时的加分点。

第二个技巧是把积分流水做成“可追溯”。现有 points_record 表里有 create_time 和 type 字段，但缺少关联业务单号。你可以加一个 biz_id 字段，把订单号或兑换单号写进去，这样前端就能在积分明细页展示“来自回收订单 #20240601XXX”。改动就是加一列，再在写入流水时多传一个参数，但整个数据链路会显得专业很多。

第三个技巧是给回收员端加“今日统计”仪表盘。用小程序端自带的 echarts-for-weixin 组件，后端加一个聚合查询接口，返回今日接单数、回收总重量、累计积分三个数字。SQL 就是三个 count 和 sum，配合 group by 日期，前端用几个卡片展示。这种可视化小功能最容易给老师和面试官留下“这人有工程意识”的印象。

第四个技巧是把小程序端的 request.js 封装升级成支持文件上传和下载进度。现在源码里的路径上传用的是 wx.uploadFile，没有跟 request.js 统一。你可以封装一个 upload 方法，把 token、错误码处理和业务码判断做成跟 request 一致，以后加图片上传功能就不需要到处复制粘贴了。

// 聚合统计接口示例：回收员今日数据 @GetMapping("/api/recycler/stats") @ResponseBody public Map<String, Object> stats(@RequestParam Integer recyclerId) { Map<String, Object> result = new HashMap<>(); result.put("orderCount", orderMapper.countTodayByRecyclerId(recyclerId)); result.put("totalWeight", orderMapper.sumTodayWeightByRecyclerId(recyclerId)); result.put("totalPoints", pointsRecordMapper.sumTodayPointsByRecyclerId(recyclerId)); return result; }

这段代码是我给的扩展方向，接口挂在回收员控制器里，三个查询分别对应订单表、积分流水表的聚合。实际写的时候不要在一个接口里塞太多逻辑，拆成三个 mapper 方法更清晰。二次开发的度要把握好：改太多的风险是数据库结构跟着变，后端 mapper 和管理端页面同步改的时间成本会失控；只做展示层和少量接口扩展，收益最划算。

最后一次跑这套项目时，我在小程序端把每个接口的耗时都打印了一遍，发现有购物车数量查询的那次请求在真机上要 1.6 秒，比本地调试时慢了一倍多。查了下是后端频繁 new SimpleDateFormat，改成全局静态实例后降到 400 毫秒。从那以后我每次改完代码除了看功能通不通，还强制走一遍 Network 面板检查耗时和数据包大小。这套源码虽然老，但胜在结构干净、改动空间大，希望你拿过去以后不只是为了交差，而是真正在里面长一点实战经验，希望帮到你。

本文还有配套的精品资源，点击获取