简介基于Spring Boot和uniapp的校园二手交易微信小程序完整源码面向计算机专业学生、毕业设计者及小程序开发入门者覆盖用户浏览购物、商家发布管理、后台管理员统一管控三大核心流程。压缩包共1444个文件约25.24MB包含266个vue前端页面、174个js逻辑脚本、145个java后台接口以及58个wxss/wxml微信小程序页面并附png/jpg图片素材、sql数据库脚本、md说明文档和bat启动脚本目录结构清晰便于按模块定位学习。目前已有111人学习浏览可作为前后端分离开发、小程序与Spring Boot接口联调、交易订单状态流转的实战参考。资源中提供application.yml数据库连接配置示例及1-install、2-run、3-build等一键运行脚本可帮助读者快速搭建环境从用户端选购、商家端上下架到管理员审核能完整理解校园二手交易系统的业务闭环与权限设计。1. 校园二手交易微信小程序源码先别急着找 demo先想清楚它到底能给你什么在校园里收一台九成新平板、出一本只用过一学期的教材靠微信群接龙和朋友圈刷屏都能成交但成交之后的信任、定价、跑单问题全靠运气。校园二手交易微信小程序源码打包了 Spring Boot 后端和 uniapp 前端解决的就是在一个封闭校园环境里让买卖双方有地方展示商品、有规则完成交易这件事。对正在做毕设、想接外包单、或者公司内部要做闲置流转系统的从业者来说这套源码的真正价值不是能跑而是它把账号体系、商品上架、下单支付、订单状态管理这一整条业务闭环用一套典型技术栈完整落地了。新手可以顺着它把前后端联调摸一遍熟手则能直接拿它当二次开发的底座省掉从零搭脚手架的时间。2. Spring Boot 后端拆解围绕用户、商品、订单、留言把表结构和接口立住拿到任何一份 Spring Boot 源码我第一步不是看 Controller 写得有多花哨而是先打开 SQL 脚本和实体类。校园二手交易的核心对象就四个用户、商品、订单、留言。这四个对象的关系理清楚了整个后端就没什么黑匣子了。2.1 先看表结构用户、商品、订单、留言四张核心表常见的表设计是这样的以 MySQL 为例字段命名上尽量用下划线风格和 Java 实体的驼峰转换靠 MyBatis-Plus 自动映射省去一堆 resultMapCREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) DEFAULT NULL COMMENT 微信openid, nickname varchar(50) DEFAULT NULL COMMENT 昵称, avatar varchar(255) DEFAULT NULL COMMENT 头像地址, phone varchar(20) DEFAULT NULL COMMENT 绑定手机号, status tinyint(4) DEFAULT 1 COMMENT 1正常 0封禁, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE product ( id bigint(20) NOT NULL AUTO_INCREMENT, seller_id bigint(20) NOT NULL COMMENT 卖家用户ID, title varchar(100) NOT NULL COMMENT 商品标题, description text COMMENT 商品描述, price decimal(10,2) NOT NULL COMMENT 价格, original_price decimal(10,2) DEFAULT NULL COMMENT 原价用于显示折扣, category varchar(20) DEFAULT NULL COMMENT 分类教材/数码/生活用品等, images varchar(2000) DEFAULT NULL COMMENT 图片URL逗号分隔, status tinyint(4) DEFAULT 0 COMMENT 0在售 1已售 2下架, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_seller (seller_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单表和留言表的结构类似订单表要关注的关键字段是product_id、buyer_id、seller_id、order_no业务订单号、status待付款/已付款/已完成/已取消。为什么推荐在订单表里冗余一个seller_id因为列表页要展示我卖出的和我买到的如果不冗余每次都要 join 商品表再反查卖家性能和维护成本都不划算。这套表结构里最容易忽略的是images字段用逗号分隔存储多张图片。在校园二手场景里商品通常只有三四张图用 JSON 或者单独建图片表都显得重逗号分隔是最务实的做法。后端拿到这个字段后 split 一下转成数组返回给前端即可。2.2 MyBatis-Plus 的选型理由和三个常用配置校园二手交易这种 CRUD 密集型的项目MyBatis-Plus 是比原生 MyBatis 更常见的选择。理由很简单单表操作基本不用写 XML分页有现成插件代码生成器能一键把实体、Mapper、Service 全生成了。源码里通常会在application.yml做这么三件事mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml type-aliases-package: com.campus.secondhand.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0第一行指定 XML 位置复杂查询比如商品列表的多条件筛选仍然走 XMLmap-underscore-to-camel-case必须开启否则seller_id映射不到sellerIdStdOutImpl是开发期必备能把每条 SQL 打到控制台排查为什么查出来的数据不对时全靠它。逻辑删除配置意味着删除商品时执行的是 UPDATE 而不是 DELETE这样买家还能看到历史订单里的商品快照遇到纠纷有据可查。2.3 发布商品与下单接口Controller 到 Service 的正确姿势看这份源码时重点看两个接口发布商品和创建订单。这两个接口能体现作者对事务和状态机的理解。我在改造这类项目时习惯用的是这种结构RestController RequestMapping(/api/product) public class ProductController { PostMapping(/publish) public ResultLong publish(RequestBody Valid ProductPublishDTO dto) { // 1. 从当前登录用户上下文取出 userId而不是信任前端传的 sellerId Long userId UserContext.getUserId(); // 2. Service 内部完成图片校验、字段补全 return Result.success(productService.publish(userId, dto)); } }这段代码表达了两层意思第一seller_id永远从后端会话里取绝不能从请求体里拿否则任何人都能冒充别人上架商品第二DTO 上加了Valid像价格非负、标题长度这类基础校验放在入口处挡掉Service 里只做业务校验。下单接口的 Service 层逻辑要重点看有没有加Transactional因为下单动作包含创建订单 商品状态改为已售 扣减库存三步必须同生共死否则就会出现订单创建成功但商品还是在售的灵异事件。2.4 Token 鉴权为什么校园二手不能裸奔用 session微信小程序的请求天然无状态用 Session 需要小程序端维护 cookie而这套源码普遍采用 Token 方案用户登录后后端签发 JWT小程序端把 token 存在 storage 里每次请求塞进Authorization头。拦截器里解析 token 的典型写法如下public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BizException(401, 未登录); } // 解析 token把 userId 塞进 ThreadLocal Long userId JwtUtil.parse(token.substring(7)); UserContext.setUserId(userId); return true; } }这里有几个参数细节需要留意JWT 的过期时间校园二手场景建议 7 天太短会导致用户频繁重新登录太长又不安全UserContext是个 ThreadLocal 工具类用完必须在拦截器的afterCompletion里 remove否则线程池复用时会串号。如果你发现源码里没有这步清理操作这属于一个典型的待优化点改造时优先补上。3. uniapp 端为什么能一套代码搞定微信小程序pages.json 与 request 封装uniapp 在这类源码里基本是标准答案原因不是它比原生小程序更高级而是它用 Vue 语法写一遍能同时编译到微信小程序和 App。对校园二手这种既要快速上线又要覆盖多端的业务来说这是性价比最高的路线。但代价是你必须理解 uniapp 的适配规则否则踩坑能踩到怀疑人生。3.1 为什么是 uniapp一套代码两处发布我之前接手过一个用原生小程序写的二手交易项目后来要出 App 版几乎重写了一套。换成 uniapp 重新做之后业务代码的复用率大概在 85% 以上剩下 15% 的差异主要在条件编译和原生 API 调用上。这份源码的前端目录结构通常是pages/下面按业务分目录static/放静态资源utils/放请求封装和工具函数。小程序端不支持 DOM 操作所以源码里所有操作 DOM的写法比如document.getElementById一律看不到全部走ref和 Vue 响应式数据驱动这是判断一份 uniapp 代码是否专业的第一眼标准。3.2 manifest.json 与 pages.json 的必填配置uniapp 项目有两个配置文件新手的困惑往往在于分不清它们的职责。manifest.json管的是这个应用是谁pages.json管的是这个应用长什么样。以小程序运行为例manifest.json里最核心的是mp-weixin配置块{ mp-weixin: { appid: 你的小程序AppID, setting: { urlCheck: false, es6: true, minified: true }, usingComponents: true, permission: { scope.userLocation: { desc: 用于展示附近可交易的闲置物品 } } } }urlCheck在开发期必须设为 false否则本地调试时所有请求都会被微信拦下来报url not in domain listminified建议开启压缩后的代码体积能小一截这在后面讲到 2MB 限制时是救命稻草。pages.json里则是注册页面路由和配置 tabBar注意 pages 数组的第一个元素就是小程序的首页调整顺序就能换启动页。还有一个容易被忽略的配置是globalStyle里的navigationBarTextStyle必须设为black或white设成别的值在 iOS 上会直接显示异常。3.3 uni.request 封装与登录态注入在 uniapp 里不能用 axios因为底层没有 XMLHttpRequest得用uni.request。一份可复用的请求封装至少要处理三件事统一 baseURL、自动注入 token、集中处理 401。以下是我在改造这类源码时常用的精简版// utils/request.js const BASE_URL http://localhost:8080/api export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: Bearer uni.getStorageSync(token) }, success: (res) { // 业务约定code 为 0 表示成功 if (res.data.code 0) { resolve(res.data.data) } else if (res.data.code 401) { // token 过期跳转登录页 uni.removeStorageSync(token) uni.navigateTo({ url: /pages/login/login }) reject(new Error(登录已过期)) } else { uni.showToast({ title: res.data.message, icon: none }) reject(new Error(res.data.message)) } }, fail: (err) reject(err) }) }) }这里的关键设计在于 token 的注入是在请求发起前统一处理的业务页面只需要写request({ url: /product/list })就行不需要在每个页面里重复写 header。后端返回结构约定为{ code, message, data }也是这套源码里比较通用的规范code 用 0 表示成功负数和 401 各有含义前端判断起来清晰。3.4 首页商品卡片与发布表单的实现要点首页商品列表用uni.createSelectorQuery做滚动加载的时机判断在 uniapp 里是错的正确做法是用页面自带的onReachBottom生命周期。列表数据驱动用 Vue 的v-for渲染商品卡片上拉触底时把页码加一再请求一次注意要把loading状态挡住否则用户快速上拉会重复请求产生重复数据。发布表单这个页面值得仔细看因为它是表单校验和图片上传的集合体。图片上传走uni.chooseImage拿到本地路径再通过uni.uploadFile传到后端或云存储返回 URL 后拼进images字段。这里我建议不要只上传一张图校园二手商品通常需要拍实物图加细节图至少开放三张上传位。表单里价格输入框用typedigit调起数字键盘分类选择用picker组件这些基础交互在 uniapp 里都有对应组件源码里如果用了什么奇怪的input typenumber处理小数价格属于细节瑕疵可以顺手改掉。4. 微信小程序环境的 5 个高频坑从打包超限到登录态这部分内容是真正的血泪经验。无论 Spring Boot 后端写得多干净uniapp 前端逻辑多漂亮只要小程序端卡在环境问题上用户看到的就是一个打不开的白色屏幕。以下五个坑是我在跑这类项目时高频遇到且每个都有明确的排查路径。4.1 打包体积超限 2MB不是删代码是拆包现象HBuilderX 编译到微信开发者工具时直接报错类似source size 2612kb exceed max limit 2mb整个项目卡死在编译阶段。原因微信小程序主包大小限制是 2MB。超过这个数不是因为你的代码量大而往往是因为把图片、字体、第三方 UI 组件库一股脑全塞进了主包里。uniapp 编译后static目录下的图片资源会原样打包进去一张高清商品占位图就可能几百 KB。解决先开分包加载。在pages.json里配置subPackages把发布商品、订单详情、个人中心这类二级页面全挪进分包主包只保留 TabBar 页面和公共资源。其次static目录里超过 50KB 的图片全部换成远程 URL 或者压缩到 WebP 格式。最后HBuilderX 发行菜单里勾选小程序-压缩选项能把 JS 代码进一步压缩。一般做完这三步主包能压到 1.5MB 以内。4.2 手机号登录只有 button 组件才是正确入口现象用uni.getPhoneNumber或者直接调微信 API 获取手机号回调里拿到的不是手机号而是一串code解析后还不知道怎么用。原因微信从基础库 2.21.2 开始收紧了手机号获取能力必须用button open-typegetPhoneNumber组件让用户主动点击授权返回的是一个动态令牌code后端拿着这个 code 再去调用微信接口换手机号。源码事件绑定时如果你去event.detail里找encryptedData会发现根本没有这个字段。解决button open-typegetPhoneNumber getphonenumberhandlePhoneNumber 微信一键登录 /buttonhandlePhoneNumber(e) { if (e.detail.code) { // 把 code 发给后端后端用 code openid 换手机号 request({ url: /auth/bindPhone, method: POST, data: { code: e.detail.code } }) } }后端拿到这个 code 之后调用微信接口code2Session 的扩展接口换取手机号再把手机号更新到用户表。如果你发现源码里还是旧的encryptedData解密逻辑可以直接删掉重写否则在真机上一定翻车。4.3 顶部导航栏高度自定义导航栏的刘海适配现象在小程序里自定义了顶部导航栏navigationStyle: custom结果在 iPhone 上导航栏被刘海遮住一部分在安卓机上又偏上偏下不一致。原因不同机型的状态栏高度不一致而自定义导航栏时页面内容会从屏幕最顶部开始布局系统状态栏的高度需要你自己算出来并做 padding 补偿。解决用uni.getMenuButtonBoundingClientRect()获取微信胶囊按钮的位置信息这是唯一准确获取顶部安全区域的可靠途径const menu uni.getMenuButtonBoundingClientRect() const systemInfo uni.getSystemInfoSync() // 导航栏高度 胶囊按钮 top 到状态栏底部的距离 胶囊高度 底部留白 this.navBarHeight menu.bottom menu.top - systemInfo.statusBarHeight this.statusBarHeight systemInfo.statusBarHeight拿到这两个值之后动态绑定到自定义导航栏的样式上。如果你是新手最简单的方案是放弃自定义导航栏直接用微信默认的只是没法做好看的渐变效果但在校园二手这种工具型应用里默认导航栏完全够用。4.4 真机预览请求失败域名校验与 HTTPS现象开发工具里接口全部通点击真机预览后手机上打开小程序所有请求全部失败报request:fail或者url not in domain list。原因微信小程序真机环境强制校验request合法域名。开发工具里能跑是因为设置了不校验合法域名但真机上没有这个豁免。解决开发调试期可以用真机调试模式代替真机预览真机调试会带上开发工具的免校验能力。正式上线前必须把后端接口域名配置到微信公众平台后台的服务器域名里而且要求 HTTPS 且证书有效。如果你用的是 IP 加端口比如http://192.168.1.100:8080微信直接拒绝没有任何商量余地。这一步其实和代码无关纯粹是配置问题但确实卡住了大量第一次接触小程序的人。另外测试时注意手机和电脑必须处于同一局域网否则localhost指向的是手机自己。4.5 token 静默过期401 拦截器统一刷新现象用户用着用着突然所有操作都失败提示登录过期点登录页重新登录后又正常了但过一会儿又复发。原因JWT token 有一个固定过期时间过期后所有请求都返回 401。如果前端只在启动时检查 token 是否过期就无法感知运行中的过期状态导致用户在一个伪装正常的界面里操作半天点提交时才报错。解决在请求封装的响应拦截器里统一处理 401跳转登录页并清掉本地缓存。如果你的源码里还有刷新 token机制返回一个新的 token 并自动覆盖本地那更好用户无感知完成续期。如果没有我建议至少做到 401 时给出明确提示登录已过期请重新登录而不是让请求静默失败。另一个常见优化是快到期时主动刷新解析 token 里的exp字段提前五分钟拉一次刷新接口这样用户完全感知不到过期这件事。5. 把源码跑通从 IDEA 到微信开发者工具的完整步骤看源码和跑源码是两码事。把这份 Spring Boot uniapp 的项目在本地完整跑起来涉及的环节不少任何一个依赖版本不匹配都会让人卡住。按下面的顺序走一遍整个过程大概需要四十分钟。5.1 环境清单与版本选型先确认你本机装好了这些软件版本是常见稳定组合组件推荐版本说明JDK1.8 或 11Spring Boot 2.x 对 JDK8 支持最稳不要用 JDK17 跑旧项目Maven3.6IDEA 自带也可以MySQL5.7 或 8.0注意 8.0 的驱动配置和 5.7 不同Redis3.x 以上很多项目用它做缓存或 token 存储HBuilderX最新稳定版用于运行 uniapp 工程微信开发者工具最新稳定版用于预览小程序这里要特别提醒的是 JDK 版本。这份源码如果基于 Spring Boot 2.7.x用 JDK8 编译最省事如果基于 Spring Boot 3.x必须用 JDK17。启动报UnsupportedClassVersionError就说明版本不匹配。打开源码的pom.xml看java.version标签是最快的确认方法。5.2 后端启动SQL 导入与三处必改配置后端工程用 IDEA 打开为 Maven 项目等待依赖下载完成后先做三件事。第一步在 MySQL 中创建数据库并导入工程根目录下的.sql文件通常叫campus_second_hand.sql之类mysql -u root -p -e CREATE DATABASE campus_second_hand DEFAULT CHARACTER SET utf8mb4; mysql -u root -p campus_second_hand campus_second_hand.sql第二步修改application.yml。钢需改的是数据库用户名密码、端口号、Redis 连接信息。端口号如果被占用改成 8081 即可。这里有个很容易忽略的点如果你本机没装 Redis 或者 Redis 设置了密码启动时就会报Unable to connect to Redis而很多表格数据缓存、登录状态都依赖 Redis跳过它项目是起不来的。第三步启动主启动类看到运行日志输出Started Application in xx seconds才算成功。如果控制台疯狂打印红色报错优先看第一条报错不要盯着堆栈底部看。5.3 前端导入HBuilderX 与 AppID 配置打开 HBuilderX选择文件-导入-从本地目录导入选中源码里的 uniapp 工程目录通常是frontend或uniapp目录。导入之后右键项目名打开manifest.json在mp-weixin配置块里填入你的小程序 AppID。没有 AppID 的话可以在微信公众平台注册个人小程序也可以先用测试号。这一步最容易出的问题是没有 AppID 就点运行微信开发者工具会报invalid appid。测试号在微信公众平台-开发-开发设置里能看到但它不支持手机号登录等部分高级能力。5.4 联调验证从注册到下单走一遍在 HBuilderX 顶部菜单选择运行-运行到小程序模拟器-微信开发者工具第一次运行会自动拉起微信开发者工具并打开项目。此时打开控制台 Network 面板小程序里的每一次请求都会出现。先测试注册登录点击小程序里的登录按钮观察 Network 里是否发起了/auth/login请求后端控制台是否打印对应 SQL。如果请求 URL 是http://localhost:8080而手机模拟器里访问不到把utils/request.js里的 BASE_URL 改成电脑的局域网 IP保证手机模拟器和电脑在同一网络环境下。接着走一遍商品发布流程填写标题、价格、上传图片、点击发布。此时去 MySQL 的product表查一下是否新增了记录再回到小程序首页确认商品出现在列表里。最后找一个账号模拟买家进行下单确认订单表里生成了新记录且商品的status从 0在售变为 1已售。这一套流程走完前后端联调基本就没问题了。6. 跑通之后验收链路、三个改造方向和一个检查习惯项目跑起来只是开始真正把这份源码变成自己手里的东西需要做一次完整的链路验收。我的建议是列一张验证表格验证链路操作路径预期结果登录注册点击微信一键登录用户表新增记录token 写入本地商品发布填写信息并上传图片商品出现在首页列表数据库状态为0下单购买买家点击立即购买订单创建商品状态变已售我的订单查看我买到的/我卖出的订单列表展示正确状态准确售后流程卖家标记已发货或买家取消订单订单状态流转正常库存/商品状态回滚验收过程中如果发现商品状态没有回滚到在售大概率是下单 Service 里没加事务或状态更新逻辑遗漏优先去看这个位置。在此基础上如果你打算把这份源码改造成自己的项目我建议优先考虑三个方向。第一个是接入真实支付能力校园二手交易如果涉及定金或担保交易可以接入微信支付小程序支付的 JSAPI 方式下单时拉起wx.requestPayment回调里验证支付结果再更新订单状态。第二个是增加搜索功能当前商品列表多为分类筛选可以引入 Elasticsearch 或者至少用 MySQL 的全文索引做标题搜索提升找货效率。第三个是补一个管理后台用 Vue Element Plus 或直接从这份后端扩展 admin 接口用来审核商品、管理用户封禁否则平台方对内容完全没有控制力出问题了只能直接改数据库。最后分享一个我每次处理这类源码都会保持的习惯把 README 里的数据库脚本删了重跑一遍再从零走一遍注册到下单流程。这个过程不是为了验证功能而是为了确认这份源码不依赖任何隐形的初始化步骤。后端接口返回 500 时先看日志里的 SQL 和异常栈而不是急着问别人前端白屏时先打开开发者工具的 Console 看报错80% 的问题在那一行红色提示里已经写明白了。排查问题的顺序往往比解决问题的速度更能看出一个工程师的成熟度。希望这份源码的学习路径能帮你少走几段弯路。本文还有配套的精品资源点击获取