简介这是一套基于Java后端与微信小程序前端的二手物品交易系统完整源码面向毕业设计场景适合计算机相关专业学生用于课程设计、论文实现或项目二次开发。压缩文件共包含1154个文件整包约17MB其中既有js、wxml、wxss等小程序前端页面与逻辑文件也有java、class构成的后端工程代码同时收纳了xml配置、sql数据库脚本以及png、jpg等UI素材项目结构完整便于按模块查阅。源码已在本地编译通过下载后配置好JDK、小程序开发工具等环境即可运行功能模块经过指导老师确认完成度较高。数据库脚本可直接导入配合前端代码可快速跑通二手交易的前后端交互与核心流程适合作为理解微信小程序与Java后端联动机制的学习样本。当前已有408人学习下载对有毕业设计或新手练手需求的使用者具有不错的参考价值。1. 这个二手物品交易小程序源码包到底适合什么场景“微信小程序二手物品交易小程序源码数据库.zip”这个压缩包听名字就知道里面装的是什么一个二手物品交易的微信小程序完整工程外加它的后端接口和数据库脚本。我处理过的这类包不在少数标配一般是三部分——小程序前端、后端服务、SQL 文件合在一起就是一个典型的 C2C 二手交易闭环用户登录、发布闲置、分类检索、收藏、议价、下单成交。这类资源对两类人最有用。一类是毕设或课设学生需要短时间交付一个业务完整、能现场演示的系统另一类是刚开始学小程序开发的新手想在一个能跑通的项目里看懂前后端怎么配合。它最大的价值不是代码写得有多炫而是业务闭环和表结构完整可落地你可以直接在它上面改出自己的东西。但别指望解压就能跑下面就从拆包开始把每一步怎么走、坑在哪说清楚。2. 源码包拆解与技术选型目录、技术栈、数据库表设计2.1 技术栈组成为什么“小程序原生 Java 后端 MySQL”最常见拿到压缩包后第一步不是急着解压运行而是确认它是什么技术栈。这类二手交易小程序的源码前端部分几乎都是微信小程序原生开发目录里会有 pages、utils、images、app.js、app.json 这些标准文件后端则常见两派一派是 Java 的 Spring Boot 或 SSM 框架另一派是 Node.js 的 Express 或 PHP 的 ThinkPHP。判断方法很简单看根目录里有没有 pom.xml 或者 package.json有前者就是 Maven 管理的 Java 工程有后者就是 Node 工程。为什么“小程序原生 Java MySQL”会成为这类源码包的主流组合答案很现实教学和毕设生态里 Java 的资料最全MyBatis 操作 MySQL 的写法网上有大量现成代码答辩时讲“订单状态机”“用户鉴权”这些也能讲出深度。小程序原生开发则不需要引入 uni-app 或 Taro 这类跨端框架微信开发者工具打开就能编译对新手最友好。MySQL 更不用多说免费、装机量大几乎任何 SQL 文件都能直接导入。我拿到一个包后的习惯动作是先把目录结构过一遍再对照根目录的配置文件确认后端语言。这类包解压后最常见的结构长这样# 项目根目录解压后 ├── miniprogram/ # 小程序前端源码 │ ├── pages/ # 页面 │ │ ├── index/ # 首页商品列表 │ │ ├── publish/ # 发布商品 │ │ ├── detail/ # 商品详情 │ │ ├── order/ # 订单列表 │ │ └── mine/ # 个人中心 │ ├── utils/ │ │ └── request.js # 封装 wx.request │ ├── app.js │ ├── app.json │ └── app.wxss ├── server/ # 后端接口源码 │ ├── pom.xml # Java Maven 工程 │ └── src/main/resources/ │ ├── application.yml │ └── mapper/ # MyBatis XML ├── sql/ │ └── secondhand.sql # 数据库脚本 └── README.md这是二手交易源码包的典型目录形态实际项目会有细节差异但主干基本一致。看三点前端有没有独立的 pages 目录、后端有没有配置文件、sql 目录里有没有可执行脚本。三个都有说明包是完整的缺了哪个后面跑通就要自己补。我一般先看 sql 目录是否为空为空的话这包的价值直接打对折因为数据库脚本是整个项目的地基没有它光看代码很难还原表结构。核对完目录再看技术栈细节。Java 后端看 pom.xml 引了哪些依赖重点看有没有 mybatis-spring-boot-starter 和 spring-boot-starter-web有这两样说明是标准的 Spring Boot MyBatis 组合。Node 后端看 package.json 里的 express 或 koa。数据库基本锁定 MySQL少数包会用 SQLite但 SQLite 在小程序毕设里很少见。2.2 数据库核心表设计从二手交易需求反推表结构看懂目录后最重要的一件事是把数据库表结构读明白。我自己的经验是一个二手交易系统表设计能对上业务闭环项目就值得往下改对不上后面改代码全是坑。这类源码包的表设计大同小异核心是用户、商品、分类、收藏、订单、留言这六张表。先看用户表和商品表它们是整个业务的两大主体-- 用户表 CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT COMMENT 用户ID, openid VARCHAR(64) NOT NULL COMMENT 微信openid唯一标识, nickname VARCHAR(50) DEFAULT COMMENT 昵称, avatar VARCHAR(255) DEFAULT COMMENT 头像URL, phone VARCHAR(20) DEFAULT COMMENT 联系电话线下交易用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; -- 商品表 CREATE TABLE goods ( id INT NOT NULL AUTO_INCREMENT COMMENT 商品ID, user_id INT NOT NULL COMMENT 发布者ID关联user.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_id INT DEFAULT NULL COMMENT 分类ID, images VARCHAR(1024) DEFAULT NULL COMMENT 图片URL多张用逗号分隔, status TINYINT DEFAULT 0 COMMENT 0在售 1已售 2下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 发布时间, PRIMARY KEY (id), KEY idx_user (user_id), KEY idx_category (category_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT二手商品表;这里两个字段最容易理解错。第一个是 user 表里的 openid它来自微信登录接口是用户在小程序里的唯一标识不允许重复所以建了唯一索引。第二个是 goods 表的 images 字段类型是 VARCHAR(1024)说明它存的是图片 URL 列表多张图用逗号拼接而不是一张图一行记录这是毕设项目里最常见也最省事的做法。理解这一点对后面排查“图片裂图”很关键。订单表和收藏表是交易闭环的核心。订单表用来记录一次交易从下单到成交的状态变化收藏表记录用户和商品之间的“意向”关系-- 订单表 CREATE TABLE orders ( id INT NOT NULL AUTO_INCREMENT COMMENT 订单ID, order_no VARCHAR(32) NOT NULL COMMENT 订单编号, goods_id INT NOT NULL COMMENT 商品ID, buyer_id INT NOT NULL COMMENT 买家ID, seller_id INT NOT NULL COMMENT 卖家ID, price DECIMAL(10,2) NOT NULL COMMENT 成交价, status TINYINT DEFAULT 0 COMMENT 0待付款 1待发货 2待收货 3已完成 4已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, deal_time DATETIME DEFAULT NULL COMMENT 成交时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表; -- 收藏表 CREATE TABLE favorite ( id INT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL COMMENT 收藏用户, goods_id INT NOT NULL COMMENT 商品, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_goods (user_id, goods_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT收藏表;订单表里有个值得注意的细节它同时存了 buyer_id 和 seller_id 两份用户 ID。原因是二手交易的买卖双方都可能是平台上的任意用户如果不冗余存下卖家 ID查询“我卖出的订单”就需要先查商品再关联用户多一次 JOIN毕设里直接用冗余字段能省很多事。收藏表的联合唯一索引 uk_user_goods 保证同一用户对同一个商品只能收藏一次这是防止重复收藏的关键约束。分类表和留言表相对简单。分类表就是一组静态数据手机数码、家用电器、服饰鞋包、图书教材、运动户外、其他。留言表是买家对商品提问或议价的地方一个商品可以有多条留言所以外键指向 goods_id。留言表在演示环节很有用答辩时可以现场演示“提问-回复”的互动流程让系统看起来不是一个静态展示页。2.3 导入源码包前先做的三件事在动手导库和启动后端之前我会先花五分钟做三件事能避免后面一半以上的报错。第一件事是完整解压用文本编辑器打开 SQL 文件先看一眼里面有没有 CREATE DATABASE 语句。有的话说明脚本会自动建库你只需要在 MySQL 里执行它没有的话就要手动先建一个空的数据库再导入表结构。第二件事是确认本机环境。这类包一般要求 MySQL 5.7 或 8.0、JDK 1.8 或 11、微信开发者工具稳定版。我一般在命令行里快速确认版本# 检查本机 MySQL 版本 mysql --version # 检查 Java 版本 java -version # 检查 Node 版本如果是 Node 后端 node --version命令行输出的版本和你后面要用的框架版本越接近跑通的概率越高。第三件事是找到后端配置文件提前把数据库账号密码改成本机的。Java 项目在 application.yml 或 application.properties 里配置Node 项目通常在 config 目录或 .env 文件里。这一步不提前做后面启动后端一定报连接失败而且报错信息里只会说“Access denied”不会告诉你“密码错了”排查起来更费时间。3. 本地跑通全流程从建库到小程序里看到商品3.1 导入数据库执行 SQL 的两种方式与字符集注意点环境确认没问题就开始导库。这一步是整个流程里翻车率最高的一步绝大多数新手都在“执行 SQL”这个动作上出了问题。先明确一点SQL 文件只是个文本需要 MySQL 服务真正运行起来它才能被执行。如果你用集成的环境包先启动 MySQL 服务如果单独装的 MySQL确认 Windows 服务或 Linux 下的 mysqld 进程在跑。导入方式有两种我推荐新手用图形化数据库工具操作新建连接后右键数据库选择“运行 SQL 文件”选中 sql 目录下的脚本等待执行完成。如果脚本里没有 CREATE DATABASE就提前新建一个名为 secondhand名字以包内脚本为准的数据库再用。命令行方式其实也不难适合熟手快速操作# 登录 MySQL 并导入整个脚本 mysql -u root -p secondhand sql/secondhand.sql这条命令的意思是用 root 用户连接本机 MySQL把 secondhand.sql 文件里的 SQL 语句导入到名为 secondhand 的数据库里。-p 参数会提示你输入密码就是本机 MySQL 的 root 密码。执行完没有报错说明表和索引都建好了。注意这里有个隐性要求数据库 secondhand 必须已经存在否则命令会直接报错这就是前面说“先看脚本里有没有 CREATE DATABASE”的原因。导库完成后建议顺手验证一下别急着启动后端。在图形工具里展开数据库应该能看到 user、goods、orders、favorite、category、message 这些表另外可能还有几张辅助表。打开 goods 表看数据如果里面已经插入了示例商品小程序首页打开时就能立即看到商品列表这对后面排查问题非常有帮助。验证完表结构再看一眼字符集。表结构和数据都导入成功不代表没有隐患。检查每个表的排序规则是不是 utf8mb4_general_ci 或 utf8mb4_unicode_ci如果有个别表是 latin1后面中文查询可能出现乱码或查不出来。最简单粗暴的处理办法是在导入前把 SQL 文件里所有 DEFAULT CHARSET 统一替换成 utf8mb4再执行导入。3.2 启动后端接口Java 项目的启动方式与端口修改数据库就绪后后端接口是第二个要跑起来的模块。以最常见的 Spring Boot 工程为例前端小程序本身没有能力直接读数据库所有商品列表、登录、下单请求都要先发给后端后端再去查 MySQL最后把 JSON 返回给小程序。所以后端不启动小程序打开必然是空白或报“请求失败”。先改配置文件。打开 server 模块下的 application.yml找到 spring.datasource 这一段把 url、username、password 改成本机 MySQL 的实际连接信息spring: datasource: url: jdbc:mysql://localhost:3306/secondhand?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码这段配置有三个关键参数。jdbc:mysql://localhost:3306/secondhand 指数据库地址是本机的 3306 端口库名是 secondhandcharacterEncodingutf8 保证中文不乱码serverTimezoneAsia/Shanghai 解决 MySQL 8.0 和 Java 时区不一致导致的“时间相差 8 小时”问题。改完密码保存用 IDEA 打开 server 目录等待 Maven 依赖下载完成找到带 main 方法的启动类直接运行。后端启动成功的标志是控制台出现“Started Application in x.xxx seconds”的日志并且端口监听在 8080以实际配置为准。看到日志后先不要打开小程序用浏览器或命令行直接访问接口地址测试# 在命令行里测试商品列表接口 curl http://localhost:8080/api/goods/list如果返回的是 JSON 数组说明后端、数据库、网络三层都通了。如果返回 404先检查接口路径是不是 /api/goods/list如果返回 500去 IDE 控制台看异常堆栈最常见的是数据库连接失败和 SQL 语句语法错误。这一步用 curl 验证的意义在于把问题定位在后端而不是让小程序来背锅。后端还有个端口冲突的坑要提前说。如果你的本机已经跑过其他 Spring Boot 或 Tomcat 服务8080 端口可能被占用启动日志里会报“Port already in use”。解决办法是改端口在 application.yml 里加一行 server.port: 8081然后把小程序端请求地址里的端口也一起改成 8081。端口一致性是前后端联调最容易忽略的细节我接手过的项目里有一半的“接口不通”是端口没对上。3.3 小程序端配置测试号、请求地址、编译预览后端接口通了最后一步是把小程序前端在微信开发者工具里跑起来。打开微信开发者工具选择“导入项目”目录选解压后的 miniprogram 文件夹AppID 可以直接用工具自带的测试号不需要注册真实的小程序账号。这里要注意导入的是小程序前端目录不是整个项目根目录如果选错了工具会提示找不到 app.json。导入完成后第一件事是修改请求地址。小程序端所有网络请求都集中在 utils/request.js 里这类项目通常会在文件顶部定义 baseUrl// utils/request.js —— 统一请求封装 const baseUrl http://localhost:8080 // 后端接口地址 function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: baseUrl path, method: method, data: data, header: { Content-Type: application/json // 登录后可以在这里追加 token }, success(res) { // 后端约定返回 { code: 0, data: ... } 表示成功 if (res.data.code 0) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(res.data) } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) } module.exports { request, baseUrl }这段封装的逻辑是所有接口统一走 request 函数避免每个页面都写一遍 wx.request 的完整配置。参数说明里最重要的是 header 对象登录后后端会返回一个 token后续请求需要带上它来识别身份一般在登录成功的回调里把 token 写入本地缓存然后在 request 里用 wx.getStorageSync(token) 动态塞进 header。如果你发现某个接口返回“未登录”或 401先检查这里是否真的带了 token。改完 baseUrl直接点工具栏的“编译”。如果一切正常模拟器里会看到首页的商品列表点击商品能进详情底部导航能在首页、分类、发布、消息、我的之间切换。到这里“从数据库到小程序页面”的完整链路就打通了。注意真机预览有两个前置要求——后端地址不能是 localhost手机访问不到你的电脑且后端必须是 HTTPS或者你在开发者工具的本地设置里勾选了“不校验合法域名”。开发阶段用模拟器即可真机调试放到避坑章节细说。4. 核心业务逻辑走读商品发布、搜索、订单状态流转4.1 商品发布与图片上传从选择图片到 multipart 表单跑通之后读业务代码的顺序我建议从“商品发布”看起因为它是整个系统里唯一涉及文件上传的功能也是前后端配合最复杂的一条链路。发布页的流程是填标题、选分类、填价格、写描述、选图片然后点发布按钮。前端核心代码长这样// pages/publish/publish.js —— 发布商品 const { request, baseUrl } require(../../utils/request.js) Page({ data: { title: , price: , categoryId: 0, description: , images: [] }, chooseImage() { wx.chooseMedia({ count: 6, // 最多选6张 mediaType: [image], sourceType: [album, camera], success: (res) { const images res.tempFiles.map(item item.tempFilePath) this.setData({ images: this.data.images.concat(images) }) } }) }, uploadImages() { // 逐个上传图片全部成功后再提交表单 const tasks this.data.images.map(filePath { return new Promise((resolve, reject) { wx.uploadFile({ url: baseUrl /api/upload, filePath: filePath, name: file, success: (res) { const data JSON.parse(res.data) if (data.code 0) { resolve(data.url) // 收集后端返回的图片URL } else { reject(new Error(data.msg)) } }, fail: reject }) }) }) return Promise.all(tasks) }, submit() { if (!this.data.title || !this.data.price) { wx.showToast({ title: 标题和价格必填, icon: none }) return } this.uploadImages().then(urls { request(/api/goods/add, POST, { title: this.data.title, price: this.data.price, categoryId: this.data.categoryId, description: this.data.description, images: urls.join(,) // 后端存逗号分隔的URL }).then(() { wx.showToast({ title: 发布成功, icon: success }) }) }) } })上面代码里有几个容易被新手忽略的设计点。chooseMedia 返回的 tempFilePath 只是微信临时文件路径只在当前小程序会话有效所以必须立刻上传到后端不能直接拿来当商品图片存库。图片是逐个上传的Promise.all 等所有图片上传完成后再把 URL 拼接成逗号分隔字符串配合数据库里 images 字段的 VARCHAR 类型。count 参数控制最多选 6 张这是二手交易场景里比较合理的上限太多张会让详情页加载变慢。后端接收图片的接口用 Spring Boot 实现的话核心是一个接收 MultipartFile 的接口。常见做法是把上传的文件保存到服务器本地的一个 upload 目录然后返回一个可访问的 URL// UploadController.java —— 图片上传接口 RestController RequestMapping(/api) public class UploadController { // 配置文件里定义的上传路径例如 /usr/local/upload/ Value(${file.upload-path}) private String uploadPath; PostMapping(/upload) public MapString, Object upload(RequestParam(file) MultipartFile file) { // 用时间戳随机数生成文件名避免重名覆盖 String fileName System.currentTimeMillis() _ file.getOriginalFilename(); File dest new File(uploadPath, fileName); file.transferTo(dest); // 返回给前端的URL需要和静态资源映射配合 return Map.of(code, 0, url, /files/ fileName); } }这个接口的关键参数是 RequestParam(file)它的 name 必须和小程序端 wx.uploadFile 里的 name 字段一致都是 file对不上后端会直接报“Required request part file is not present”。文件名用时间戳拼接是为了防止多个用户上传同名文件互相覆盖这是开发阶段最容易踩的坑。返回的 /files/xxx 只是相对路径前端拿到后要拼上后端地址才能完整显示所以还要在 Spring Boot 里配置静态资源映射把 /files/** 指向本地的 upload 目录否则图片 404。4.2 搜索与分类筛选接口参数设计与分页边界商品列表页是用户进小程序后看到的第一个页面也是搜索和分类的入口。这类项目最典型的设计是首页顶部一个搜索框下面一排分类 tab再往下是商品瀑布流。对应的后端接口通常是一个支持多条件组合查询的列表接口参数设计基本固定为 keyword、categoryId、page、size 四个。keyword 来自搜索框categoryId 来自分类 tabpage 和 size 控制分页。后端 Service 层最常见的实现是用 MyBatis 动态 SQL 拼接查询条件!-- GoodsMapper.xml —— 搜索列表查询 -- select idsearchGoods resultTypemap SELECT g.id, g.title, g.price, g.original_price, g.images, g.status, g.create_time, u.nickname, u.avatar FROM goods g LEFT JOIN user u ON g.user_id u.id where g.status 0 if testkeyword ! null and keyword ! AND g.title LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null and categoryId ! 0 AND g.category_id #{categoryId} /if /where ORDER BY g.create_time DESC LIMIT #{offset}, #{size} /select这段 SQL 的核心在 标签它能让 MyBatis 根据是否传入了 keyword 和 categoryId 自动拼条件不传就只查 status0 的在售商品。注意 status0 是硬条件必须写在动态 if 之外否则下架和已售商品也会出现在搜索结果里。LIMIT 的两个参数offset 是偏移量size 是每页条数小程序端下拉加载时通过修改 page 来计算 offset。前端分页的写法我一般用一个统一的模式data 里维护 page、size、list、loading 四个字段onLoad 请求第一页触底事件请求下一页// pages/index/index.js —— 列表加载与分页 Page({ data: { list: [], page: 1, size: 10, total: 0, loading: false }, onLoad() { this.loadList(true) // 首次加载清空列表 }, loadList(isRefresh) { if (this.data.loading) return // 防止重复请求 this.setData({ loading: true }) request(/api/goods/list, GET, { page: this.data.page, size: this.data.size, keyword: this.data.keyword || , categoryId: this.data.categoryId || 0 }).then(res { const newList isRefresh ? res.list : this.data.list.concat(res.list) this.setData({ list: newList, total: res.total, loading: false }) }) }, onReachBottom() { if (this.data.list.length this.data.total) { wx.showToast({ title: 没有更多了, icon: none }) return } this.setData({ page: this.data.page 1 }) this.loadList(false) } })分页最大的坑在“没有更多了”的判断。total 是后端返回的总条数只有当已加载的 list.length 小于 total 时才允许加载下一页。很多新手忽略这个判断导致触底一直请求最后一页数据重复展示。还有一个细节loadList 开头用 loading 标志位拦截重复请求是因为 onReachBottom 触底事件触发频率很高不加这个标志位同一页会被请求两次。4.3 订单状态流转买家、卖家两个视角的状态机订单模块是二手交易系统里最值得讲清楚的部分。难点在于同一个订单买家和卖家看到的状态是不同的。比如买家点“确认收货”后订单状态变成已完成卖家那边要看到的是“交易完成”双方视角必须对得上。下表是这类项目最常用的状态设计状态值买家视角卖家视角触发动作0待付款等待买家付款买家提交订单1待发货待发货买家完成支付演示环境常用模拟支付2待收货已发货卖家点击发货3已完成已完成买家点击确认收货4已取消已取消任意一方取消仅限状态 0 和 1 时这张表的价值在于它明确了状态的唯一来源订单表里的 status 字段两个视角只是对这个字段的不同文字解释。写代码时不能给买家和卖家各维护一份状态那必然导致数据不一致。前端的订单列表页通过判断当前用户是买家还是卖家把 status 映射成不同的文字和操作按钮。状态流转的校验逻辑后端通常用一组 if 判断或者枚举配合转移表实现。判断的关键是每个状态只允许固定的几个动作不合法的一律拒绝// OrderService.java —— 状态流转核心逻辑简化 public void updateStatus(int orderId, int fromStatus, int toStatus, int userId) { // 1. 查订单判断用户是否为买家或卖家 Order order orderMapper.findById(orderId); boolean isBuyer order.getBuyerId() userId; boolean isSeller order.getSellerId() userId; // 2. 校验状态是否合法 if (isBuyer fromStatus 2 toStatus 3) { // 买家确认收货待收货 - 已完成 orderMapper.updateStatus(orderId, 3); } else if (isSeller fromStatus 1 toStatus 2) { // 卖家发货待发货 - 已发货 orderMapper.updateStatus(orderId, 2); } else { throw new RuntimeException(非法状态流转); } }这段代码的核心思想是“状态转移必须显式声明”。fromStatus 和 toStatus 都明确写出从哪到哪不允许出现待发货直接跳到已完成这种跳变。实际项目里还会加上时间记录比如发货时间、成交时间这些字段在订单表里都有对应的 DATETIME 列。如果你拿到手的源码把状态流转逻辑散落在各个页面里那是个危险信号说明改起来容易出并发问题。订单模块还有个绕不开的现实真实支付需要商户号和支付资质毕设和大多数演示项目都不会接真实支付。常见做法是用一个“模拟支付”按钮代替点击后直接调用后端把订单从 0 改成 1并弹出提示“演示环境未接入真实支付”。这个设计在答辩时一定要主动说明不然老师问“支付成功回调怎么处理的”会很尴尬。5. 二手交易小程序开发避坑指南5 个必踩的坑与排查路径5.1 数据库导入报错 1064MySQL 版本语法不匹配现象用图形工具或命令行导入 SQL 文件时报 ERROR 1064 (42000) You have an error in your SQL syntax报错位置在某个建表语句的结尾。原因大多数源码包的 SQL 文件是在 MySQL 8.0 环境下导出的里面可能带上了 8.0 特有的排序规则如 utf8mb4_0900_ai_ci在 MySQL 5.7 上执行就会语法报错。解决先确认本机 MySQL 版本如果本机是 5.7用文本编辑器打开 SQL 文件把所有 utf8mb4_0900_ai_ci 全局替换成 utf8mb4_general_ci再重新导入。如果替换后还报错定位到报错行号把那一行单独粘贴到查询窗口逐句执行通常能立刻看出是多了逗号还是少了分号。5.2 真机预览请求不到接口合法域名与本地回环问题现象在开发者工具模拟器里一切正常商品列表、登录都通一换成真机预览就全部请求失败控制台报 request:fail。原因两个问题叠加。第一开发阶段后端跑在你自己电脑上地址是 localhost手机访问 localhost 访问的是手机自己根本到不了电脑第二真机上微信要求所有请求域名必须在后台配置合法域名且必须是 HTTPSHTTP 的局域网地址必然被拦。解决如果是联调阶段最简单的办法是让手机和电脑连同一个局域网把后端请求地址从 localhost 改成电脑的局域网 IP比如 http://192.168.1.5:8080同时在微信开发者工具的“详情 → 本地设置”里勾选“不校验合法域名”。注意这个选项只在开发版和体验版里生效上线必须换成备案域名加 HTTPS。想省掉域名成本的话把后端迁到云开发是更干净的方案后面进阶章会讲。5.3 图片列表裂图本地路径与服务器路径的边界现象商品发布时图片上传成功数据库里也能看到图片 URL但首页和详情页的图片显示不出来全部裂图。原因最常见的是后端把图片存到了服务器本地数据库里存的是相对路径如 /files/xxx.jpg前端拿到后直接拼在请求域名后面。如果后端没有做静态资源映射或者前端拼的域名端口不对图片就访问不到。另一种情况是开发阶段数据库里残留了原作者机器上的绝对路径比如 C:/Users/某个用户/upload/xxx.jpg换到你机器上自然打不开。解决第一步确认后端是否配置了静态资源映射Spring Boot 里实现 WebMvcConfigurer 把 /files/** 指向本机 upload 目录第二步用浏览器直接访问数据库中存的完整 URL能打开说明后端没问题问题在前端拼地址打不开就检查映射路径。第三步把数据库里历史图片 URL 统一替换成你本机的访问地址或者干脆清掉旧数据重新发布。5.4 接口一直返回 401登录态过期与 token 丢失现象用户刚登录时一切正常过一会儿再点接口全部返回未登录或 401。重新登录又好了过一阵又失效。原因这类项目几乎都用微信登录获取 openid再用 openid 查询用户生成一个自定义 token 存在后端。token 通常设置了过期时间比如 2 小时。前端这边如果每次请求都从本地缓存里读 token 并放到 header那问题多半出在 token 过期后没有重新登录的机制。解决在 request.js 封装的响应处理里加一个 401 分支收到 401 后清空本地登录态跳回登录页或者静默调用 wx.login 重新登录换取新 token。后端的 token 过期时间也可以适当拉长比如改成 7 天但毕设项目够用就行。重点在“统一处理”不能在几十个页面里各写一遍判断不然漏掉一个就很难查。5.5 已售商品还在首页展示列表接口漏了状态过滤现象把某个商品标记为已售或下架后首页和搜索列表里还能看到它点进去却提示已被购买。原因列表接口的 SQL 里没有把 status0 作为强制条件或者前端列表页没有传任何状态参数。这类源码包的商品表里 status 字段是有设计的但接口层写漏了把下架和已售状态的商品也查出来了。解决找到后端商品列表查询的 Mapper 或 SQL在查询条件里加上 AND g.status 0并把商品详情接口也做同样处理——已售商品只能看详情不能触发购买。这个坑虽然小但它直接影响系统可信度答辩演示时被老师看到“已售商品还在首页”是很掉分的事。6. 进阶把跑通的 Demo 改造成能上线跑的版本6.1 三条低成本改造路径云开发、HTTPS、云存储项目跑通只是第一步如果目标是上线或者放到简历里展示三个改造点优先级最高。第一是把后端和数据库迁到微信云开发用云函数替代自建服务器用云数据库替代 MySQL这样免掉了域名备案和 HTTPS 证书配置是最省事的路径。改造工作量不小因为要把所有 wx.request 换成云函数调用方式但换完后不再有本地回环和合法域名的困扰真机随时能测。第二是图片存储迁到云存储。本地磁盘存图的方案在后端重启或换机器后经常丢图而云存储返回的 URL 是公网可访问的天然支持 HTTPS。改动范围很小只动上传接口那一块。第三是如果坚持用自建服务器那就在服务器上配 Nginx给后端接口挂上 HTTPS 证书再把小程序后台的合法域名填上正式域名。这三种路径按开发成本和长期收益排序云开发 云存储加自建后端 纯自建加 HTTPS。6.2 上线前必须自查的清单改造成能跑只是上线前的及格线。我把这类二手交易项目上线前要过一遍的清单列在这里照着查就行。功能层注册登录流程是否支持静默登录失败后的手动处理、商品发布是否校验了必填项和图片数量、订单取消和超时未支付是否有兜底、买家和卖家双方看到的状态文案是否一致。安全层后端接口有没有做登录鉴权所有需要登录才能调的接口是否都校验了 token不能只拦了前端页面。内容层是否做了敏感词过滤用户发布违规商品时有没有举报和下架通道。做完这些自查再回答两个问题我的代码里有没有把数据库密码写死在配置里并提交到公开仓库有没有在控制台打印用户手机号和 openid。这两个问题任何一个没处理好都比功能 bug 更致命。说一句我自己的习惯拿到任何源码包第一件事不是读业务代码而是先把数据库表结构画出来再对着表去看接口。表结构能和业务闭环对上这个项目就值得花时间往下读对不上后面改起来全是无底洞。这套二手交易项目的表设计六张表对应一个完整交易闭环已经算很规整的了。顺着这个思路去改造你会比那些直接解压跑通就交付的人走得远得多。希望这篇能帮到你。本文还有配套的精品资源点击获取 微信小程序二手物品交易系统源码解析与部署改造指南
简介这是一套基于Java后端与微信小程序前端的二手物品交易系统完整源码面向毕业设计场景适合计算机相关专业学生用于课程设计、论文实现或项目二次开发。压缩文件共包含1154个文件整包约17MB其中既有js、wxml、wxss等小程序前端页面与逻辑文件也有java、class构成的后端工程代码同时收纳了xml配置、sql数据库脚本以及png、jpg等UI素材项目结构完整便于按模块查阅。源码已在本地编译通过下载后配置好JDK、小程序开发工具等环境即可运行功能模块经过指导老师确认完成度较高。数据库脚本可直接导入配合前端代码可快速跑通二手交易的前后端交互与核心流程适合作为理解微信小程序与Java后端联动机制的学习样本。当前已有408人学习下载对有毕业设计或新手练手需求的使用者具有不错的参考价值。1. 这个二手物品交易小程序源码包到底适合什么场景“微信小程序二手物品交易小程序源码数据库.zip”这个压缩包听名字就知道里面装的是什么一个二手物品交易的微信小程序完整工程外加它的后端接口和数据库脚本。我处理过的这类包不在少数标配一般是三部分——小程序前端、后端服务、SQL 文件合在一起就是一个典型的 C2C 二手交易闭环用户登录、发布闲置、分类检索、收藏、议价、下单成交。这类资源对两类人最有用。一类是毕设或课设学生需要短时间交付一个业务完整、能现场演示的系统另一类是刚开始学小程序开发的新手想在一个能跑通的项目里看懂前后端怎么配合。它最大的价值不是代码写得有多炫而是业务闭环和表结构完整可落地你可以直接在它上面改出自己的东西。但别指望解压就能跑下面就从拆包开始把每一步怎么走、坑在哪说清楚。2. 源码包拆解与技术选型目录、技术栈、数据库表设计2.1 技术栈组成为什么“小程序原生 Java 后端 MySQL”最常见拿到压缩包后第一步不是急着解压运行而是确认它是什么技术栈。这类二手交易小程序的源码前端部分几乎都是微信小程序原生开发目录里会有 pages、utils、images、app.js、app.json 这些标准文件后端则常见两派一派是 Java 的 Spring Boot 或 SSM 框架另一派是 Node.js 的 Express 或 PHP 的 ThinkPHP。判断方法很简单看根目录里有没有 pom.xml 或者 package.json有前者就是 Maven 管理的 Java 工程有后者就是 Node 工程。为什么“小程序原生 Java MySQL”会成为这类源码包的主流组合答案很现实教学和毕设生态里 Java 的资料最全MyBatis 操作 MySQL 的写法网上有大量现成代码答辩时讲“订单状态机”“用户鉴权”这些也能讲出深度。小程序原生开发则不需要引入 uni-app 或 Taro 这类跨端框架微信开发者工具打开就能编译对新手最友好。MySQL 更不用多说免费、装机量大几乎任何 SQL 文件都能直接导入。我拿到一个包后的习惯动作是先把目录结构过一遍再对照根目录的配置文件确认后端语言。这类包解压后最常见的结构长这样# 项目根目录解压后 ├── miniprogram/ # 小程序前端源码 │ ├── pages/ # 页面 │ │ ├── index/ # 首页商品列表 │ │ ├── publish/ # 发布商品 │ │ ├── detail/ # 商品详情 │ │ ├── order/ # 订单列表 │ │ └── mine/ # 个人中心 │ ├── utils/ │ │ └── request.js # 封装 wx.request │ ├── app.js │ ├── app.json │ └── app.wxss ├── server/ # 后端接口源码 │ ├── pom.xml # Java Maven 工程 │ └── src/main/resources/ │ ├── application.yml │ └── mapper/ # MyBatis XML ├── sql/ │ └── secondhand.sql # 数据库脚本 └── README.md这是二手交易源码包的典型目录形态实际项目会有细节差异但主干基本一致。看三点前端有没有独立的 pages 目录、后端有没有配置文件、sql 目录里有没有可执行脚本。三个都有说明包是完整的缺了哪个后面跑通就要自己补。我一般先看 sql 目录是否为空为空的话这包的价值直接打对折因为数据库脚本是整个项目的地基没有它光看代码很难还原表结构。核对完目录再看技术栈细节。Java 后端看 pom.xml 引了哪些依赖重点看有没有 mybatis-spring-boot-starter 和 spring-boot-starter-web有这两样说明是标准的 Spring Boot MyBatis 组合。Node 后端看 package.json 里的 express 或 koa。数据库基本锁定 MySQL少数包会用 SQLite但 SQLite 在小程序毕设里很少见。2.2 数据库核心表设计从二手交易需求反推表结构看懂目录后最重要的一件事是把数据库表结构读明白。我自己的经验是一个二手交易系统表设计能对上业务闭环项目就值得往下改对不上后面改代码全是坑。这类源码包的表设计大同小异核心是用户、商品、分类、收藏、订单、留言这六张表。先看用户表和商品表它们是整个业务的两大主体-- 用户表 CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT COMMENT 用户ID, openid VARCHAR(64) NOT NULL COMMENT 微信openid唯一标识, nickname VARCHAR(50) DEFAULT COMMENT 昵称, avatar VARCHAR(255) DEFAULT COMMENT 头像URL, phone VARCHAR(20) DEFAULT COMMENT 联系电话线下交易用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; -- 商品表 CREATE TABLE goods ( id INT NOT NULL AUTO_INCREMENT COMMENT 商品ID, user_id INT NOT NULL COMMENT 发布者ID关联user.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_id INT DEFAULT NULL COMMENT 分类ID, images VARCHAR(1024) DEFAULT NULL COMMENT 图片URL多张用逗号分隔, status TINYINT DEFAULT 0 COMMENT 0在售 1已售 2下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 发布时间, PRIMARY KEY (id), KEY idx_user (user_id), KEY idx_category (category_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT二手商品表;这里两个字段最容易理解错。第一个是 user 表里的 openid它来自微信登录接口是用户在小程序里的唯一标识不允许重复所以建了唯一索引。第二个是 goods 表的 images 字段类型是 VARCHAR(1024)说明它存的是图片 URL 列表多张图用逗号拼接而不是一张图一行记录这是毕设项目里最常见也最省事的做法。理解这一点对后面排查“图片裂图”很关键。订单表和收藏表是交易闭环的核心。订单表用来记录一次交易从下单到成交的状态变化收藏表记录用户和商品之间的“意向”关系-- 订单表 CREATE TABLE orders ( id INT NOT NULL AUTO_INCREMENT COMMENT 订单ID, order_no VARCHAR(32) NOT NULL COMMENT 订单编号, goods_id INT NOT NULL COMMENT 商品ID, buyer_id INT NOT NULL COMMENT 买家ID, seller_id INT NOT NULL COMMENT 卖家ID, price DECIMAL(10,2) NOT NULL COMMENT 成交价, status TINYINT DEFAULT 0 COMMENT 0待付款 1待发货 2待收货 3已完成 4已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, deal_time DATETIME DEFAULT NULL COMMENT 成交时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表; -- 收藏表 CREATE TABLE favorite ( id INT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL COMMENT 收藏用户, goods_id INT NOT NULL COMMENT 商品, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_goods (user_id, goods_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT收藏表;订单表里有个值得注意的细节它同时存了 buyer_id 和 seller_id 两份用户 ID。原因是二手交易的买卖双方都可能是平台上的任意用户如果不冗余存下卖家 ID查询“我卖出的订单”就需要先查商品再关联用户多一次 JOIN毕设里直接用冗余字段能省很多事。收藏表的联合唯一索引 uk_user_goods 保证同一用户对同一个商品只能收藏一次这是防止重复收藏的关键约束。分类表和留言表相对简单。分类表就是一组静态数据手机数码、家用电器、服饰鞋包、图书教材、运动户外、其他。留言表是买家对商品提问或议价的地方一个商品可以有多条留言所以外键指向 goods_id。留言表在演示环节很有用答辩时可以现场演示“提问-回复”的互动流程让系统看起来不是一个静态展示页。2.3 导入源码包前先做的三件事在动手导库和启动后端之前我会先花五分钟做三件事能避免后面一半以上的报错。第一件事是完整解压用文本编辑器打开 SQL 文件先看一眼里面有没有 CREATE DATABASE 语句。有的话说明脚本会自动建库你只需要在 MySQL 里执行它没有的话就要手动先建一个空的数据库再导入表结构。第二件事是确认本机环境。这类包一般要求 MySQL 5.7 或 8.0、JDK 1.8 或 11、微信开发者工具稳定版。我一般在命令行里快速确认版本# 检查本机 MySQL 版本 mysql --version # 检查 Java 版本 java -version # 检查 Node 版本如果是 Node 后端 node --version命令行输出的版本和你后面要用的框架版本越接近跑通的概率越高。第三件事是找到后端配置文件提前把数据库账号密码改成本机的。Java 项目在 application.yml 或 application.properties 里配置Node 项目通常在 config 目录或 .env 文件里。这一步不提前做后面启动后端一定报连接失败而且报错信息里只会说“Access denied”不会告诉你“密码错了”排查起来更费时间。3. 本地跑通全流程从建库到小程序里看到商品3.1 导入数据库执行 SQL 的两种方式与字符集注意点环境确认没问题就开始导库。这一步是整个流程里翻车率最高的一步绝大多数新手都在“执行 SQL”这个动作上出了问题。先明确一点SQL 文件只是个文本需要 MySQL 服务真正运行起来它才能被执行。如果你用集成的环境包先启动 MySQL 服务如果单独装的 MySQL确认 Windows 服务或 Linux 下的 mysqld 进程在跑。导入方式有两种我推荐新手用图形化数据库工具操作新建连接后右键数据库选择“运行 SQL 文件”选中 sql 目录下的脚本等待执行完成。如果脚本里没有 CREATE DATABASE就提前新建一个名为 secondhand名字以包内脚本为准的数据库再用。命令行方式其实也不难适合熟手快速操作# 登录 MySQL 并导入整个脚本 mysql -u root -p secondhand sql/secondhand.sql这条命令的意思是用 root 用户连接本机 MySQL把 secondhand.sql 文件里的 SQL 语句导入到名为 secondhand 的数据库里。-p 参数会提示你输入密码就是本机 MySQL 的 root 密码。执行完没有报错说明表和索引都建好了。注意这里有个隐性要求数据库 secondhand 必须已经存在否则命令会直接报错这就是前面说“先看脚本里有没有 CREATE DATABASE”的原因。导库完成后建议顺手验证一下别急着启动后端。在图形工具里展开数据库应该能看到 user、goods、orders、favorite、category、message 这些表另外可能还有几张辅助表。打开 goods 表看数据如果里面已经插入了示例商品小程序首页打开时就能立即看到商品列表这对后面排查问题非常有帮助。验证完表结构再看一眼字符集。表结构和数据都导入成功不代表没有隐患。检查每个表的排序规则是不是 utf8mb4_general_ci 或 utf8mb4_unicode_ci如果有个别表是 latin1后面中文查询可能出现乱码或查不出来。最简单粗暴的处理办法是在导入前把 SQL 文件里所有 DEFAULT CHARSET 统一替换成 utf8mb4再执行导入。3.2 启动后端接口Java 项目的启动方式与端口修改数据库就绪后后端接口是第二个要跑起来的模块。以最常见的 Spring Boot 工程为例前端小程序本身没有能力直接读数据库所有商品列表、登录、下单请求都要先发给后端后端再去查 MySQL最后把 JSON 返回给小程序。所以后端不启动小程序打开必然是空白或报“请求失败”。先改配置文件。打开 server 模块下的 application.yml找到 spring.datasource 这一段把 url、username、password 改成本机 MySQL 的实际连接信息spring: datasource: url: jdbc:mysql://localhost:3306/secondhand?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码这段配置有三个关键参数。jdbc:mysql://localhost:3306/secondhand 指数据库地址是本机的 3306 端口库名是 secondhandcharacterEncodingutf8 保证中文不乱码serverTimezoneAsia/Shanghai 解决 MySQL 8.0 和 Java 时区不一致导致的“时间相差 8 小时”问题。改完密码保存用 IDEA 打开 server 目录等待 Maven 依赖下载完成找到带 main 方法的启动类直接运行。后端启动成功的标志是控制台出现“Started Application in x.xxx seconds”的日志并且端口监听在 8080以实际配置为准。看到日志后先不要打开小程序用浏览器或命令行直接访问接口地址测试# 在命令行里测试商品列表接口 curl http://localhost:8080/api/goods/list如果返回的是 JSON 数组说明后端、数据库、网络三层都通了。如果返回 404先检查接口路径是不是 /api/goods/list如果返回 500去 IDE 控制台看异常堆栈最常见的是数据库连接失败和 SQL 语句语法错误。这一步用 curl 验证的意义在于把问题定位在后端而不是让小程序来背锅。后端还有个端口冲突的坑要提前说。如果你的本机已经跑过其他 Spring Boot 或 Tomcat 服务8080 端口可能被占用启动日志里会报“Port already in use”。解决办法是改端口在 application.yml 里加一行 server.port: 8081然后把小程序端请求地址里的端口也一起改成 8081。端口一致性是前后端联调最容易忽略的细节我接手过的项目里有一半的“接口不通”是端口没对上。3.3 小程序端配置测试号、请求地址、编译预览后端接口通了最后一步是把小程序前端在微信开发者工具里跑起来。打开微信开发者工具选择“导入项目”目录选解压后的 miniprogram 文件夹AppID 可以直接用工具自带的测试号不需要注册真实的小程序账号。这里要注意导入的是小程序前端目录不是整个项目根目录如果选错了工具会提示找不到 app.json。导入完成后第一件事是修改请求地址。小程序端所有网络请求都集中在 utils/request.js 里这类项目通常会在文件顶部定义 baseUrl// utils/request.js —— 统一请求封装 const baseUrl http://localhost:8080 // 后端接口地址 function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: baseUrl path, method: method, data: data, header: { Content-Type: application/json // 登录后可以在这里追加 token }, success(res) { // 后端约定返回 { code: 0, data: ... } 表示成功 if (res.data.code 0) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(res.data) } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) } module.exports { request, baseUrl }这段封装的逻辑是所有接口统一走 request 函数避免每个页面都写一遍 wx.request 的完整配置。参数说明里最重要的是 header 对象登录后后端会返回一个 token后续请求需要带上它来识别身份一般在登录成功的回调里把 token 写入本地缓存然后在 request 里用 wx.getStorageSync(token) 动态塞进 header。如果你发现某个接口返回“未登录”或 401先检查这里是否真的带了 token。改完 baseUrl直接点工具栏的“编译”。如果一切正常模拟器里会看到首页的商品列表点击商品能进详情底部导航能在首页、分类、发布、消息、我的之间切换。到这里“从数据库到小程序页面”的完整链路就打通了。注意真机预览有两个前置要求——后端地址不能是 localhost手机访问不到你的电脑且后端必须是 HTTPS或者你在开发者工具的本地设置里勾选了“不校验合法域名”。开发阶段用模拟器即可真机调试放到避坑章节细说。4. 核心业务逻辑走读商品发布、搜索、订单状态流转4.1 商品发布与图片上传从选择图片到 multipart 表单跑通之后读业务代码的顺序我建议从“商品发布”看起因为它是整个系统里唯一涉及文件上传的功能也是前后端配合最复杂的一条链路。发布页的流程是填标题、选分类、填价格、写描述、选图片然后点发布按钮。前端核心代码长这样// pages/publish/publish.js —— 发布商品 const { request, baseUrl } require(../../utils/request.js) Page({ data: { title: , price: , categoryId: 0, description: , images: [] }, chooseImage() { wx.chooseMedia({ count: 6, // 最多选6张 mediaType: [image], sourceType: [album, camera], success: (res) { const images res.tempFiles.map(item item.tempFilePath) this.setData({ images: this.data.images.concat(images) }) } }) }, uploadImages() { // 逐个上传图片全部成功后再提交表单 const tasks this.data.images.map(filePath { return new Promise((resolve, reject) { wx.uploadFile({ url: baseUrl /api/upload, filePath: filePath, name: file, success: (res) { const data JSON.parse(res.data) if (data.code 0) { resolve(data.url) // 收集后端返回的图片URL } else { reject(new Error(data.msg)) } }, fail: reject }) }) }) return Promise.all(tasks) }, submit() { if (!this.data.title || !this.data.price) { wx.showToast({ title: 标题和价格必填, icon: none }) return } this.uploadImages().then(urls { request(/api/goods/add, POST, { title: this.data.title, price: this.data.price, categoryId: this.data.categoryId, description: this.data.description, images: urls.join(,) // 后端存逗号分隔的URL }).then(() { wx.showToast({ title: 发布成功, icon: success }) }) }) } })上面代码里有几个容易被新手忽略的设计点。chooseMedia 返回的 tempFilePath 只是微信临时文件路径只在当前小程序会话有效所以必须立刻上传到后端不能直接拿来当商品图片存库。图片是逐个上传的Promise.all 等所有图片上传完成后再把 URL 拼接成逗号分隔字符串配合数据库里 images 字段的 VARCHAR 类型。count 参数控制最多选 6 张这是二手交易场景里比较合理的上限太多张会让详情页加载变慢。后端接收图片的接口用 Spring Boot 实现的话核心是一个接收 MultipartFile 的接口。常见做法是把上传的文件保存到服务器本地的一个 upload 目录然后返回一个可访问的 URL// UploadController.java —— 图片上传接口 RestController RequestMapping(/api) public class UploadController { // 配置文件里定义的上传路径例如 /usr/local/upload/ Value(${file.upload-path}) private String uploadPath; PostMapping(/upload) public MapString, Object upload(RequestParam(file) MultipartFile file) { // 用时间戳随机数生成文件名避免重名覆盖 String fileName System.currentTimeMillis() _ file.getOriginalFilename(); File dest new File(uploadPath, fileName); file.transferTo(dest); // 返回给前端的URL需要和静态资源映射配合 return Map.of(code, 0, url, /files/ fileName); } }这个接口的关键参数是 RequestParam(file)它的 name 必须和小程序端 wx.uploadFile 里的 name 字段一致都是 file对不上后端会直接报“Required request part file is not present”。文件名用时间戳拼接是为了防止多个用户上传同名文件互相覆盖这是开发阶段最容易踩的坑。返回的 /files/xxx 只是相对路径前端拿到后要拼上后端地址才能完整显示所以还要在 Spring Boot 里配置静态资源映射把 /files/** 指向本地的 upload 目录否则图片 404。4.2 搜索与分类筛选接口参数设计与分页边界商品列表页是用户进小程序后看到的第一个页面也是搜索和分类的入口。这类项目最典型的设计是首页顶部一个搜索框下面一排分类 tab再往下是商品瀑布流。对应的后端接口通常是一个支持多条件组合查询的列表接口参数设计基本固定为 keyword、categoryId、page、size 四个。keyword 来自搜索框categoryId 来自分类 tabpage 和 size 控制分页。后端 Service 层最常见的实现是用 MyBatis 动态 SQL 拼接查询条件!-- GoodsMapper.xml —— 搜索列表查询 -- select idsearchGoods resultTypemap SELECT g.id, g.title, g.price, g.original_price, g.images, g.status, g.create_time, u.nickname, u.avatar FROM goods g LEFT JOIN user u ON g.user_id u.id where g.status 0 if testkeyword ! null and keyword ! AND g.title LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null and categoryId ! 0 AND g.category_id #{categoryId} /if /where ORDER BY g.create_time DESC LIMIT #{offset}, #{size} /select这段 SQL 的核心在 标签它能让 MyBatis 根据是否传入了 keyword 和 categoryId 自动拼条件不传就只查 status0 的在售商品。注意 status0 是硬条件必须写在动态 if 之外否则下架和已售商品也会出现在搜索结果里。LIMIT 的两个参数offset 是偏移量size 是每页条数小程序端下拉加载时通过修改 page 来计算 offset。前端分页的写法我一般用一个统一的模式data 里维护 page、size、list、loading 四个字段onLoad 请求第一页触底事件请求下一页// pages/index/index.js —— 列表加载与分页 Page({ data: { list: [], page: 1, size: 10, total: 0, loading: false }, onLoad() { this.loadList(true) // 首次加载清空列表 }, loadList(isRefresh) { if (this.data.loading) return // 防止重复请求 this.setData({ loading: true }) request(/api/goods/list, GET, { page: this.data.page, size: this.data.size, keyword: this.data.keyword || , categoryId: this.data.categoryId || 0 }).then(res { const newList isRefresh ? res.list : this.data.list.concat(res.list) this.setData({ list: newList, total: res.total, loading: false }) }) }, onReachBottom() { if (this.data.list.length this.data.total) { wx.showToast({ title: 没有更多了, icon: none }) return } this.setData({ page: this.data.page 1 }) this.loadList(false) } })分页最大的坑在“没有更多了”的判断。total 是后端返回的总条数只有当已加载的 list.length 小于 total 时才允许加载下一页。很多新手忽略这个判断导致触底一直请求最后一页数据重复展示。还有一个细节loadList 开头用 loading 标志位拦截重复请求是因为 onReachBottom 触底事件触发频率很高不加这个标志位同一页会被请求两次。4.3 订单状态流转买家、卖家两个视角的状态机订单模块是二手交易系统里最值得讲清楚的部分。难点在于同一个订单买家和卖家看到的状态是不同的。比如买家点“确认收货”后订单状态变成已完成卖家那边要看到的是“交易完成”双方视角必须对得上。下表是这类项目最常用的状态设计状态值买家视角卖家视角触发动作0待付款等待买家付款买家提交订单1待发货待发货买家完成支付演示环境常用模拟支付2待收货已发货卖家点击发货3已完成已完成买家点击确认收货4已取消已取消任意一方取消仅限状态 0 和 1 时这张表的价值在于它明确了状态的唯一来源订单表里的 status 字段两个视角只是对这个字段的不同文字解释。写代码时不能给买家和卖家各维护一份状态那必然导致数据不一致。前端的订单列表页通过判断当前用户是买家还是卖家把 status 映射成不同的文字和操作按钮。状态流转的校验逻辑后端通常用一组 if 判断或者枚举配合转移表实现。判断的关键是每个状态只允许固定的几个动作不合法的一律拒绝// OrderService.java —— 状态流转核心逻辑简化 public void updateStatus(int orderId, int fromStatus, int toStatus, int userId) { // 1. 查订单判断用户是否为买家或卖家 Order order orderMapper.findById(orderId); boolean isBuyer order.getBuyerId() userId; boolean isSeller order.getSellerId() userId; // 2. 校验状态是否合法 if (isBuyer fromStatus 2 toStatus 3) { // 买家确认收货待收货 - 已完成 orderMapper.updateStatus(orderId, 3); } else if (isSeller fromStatus 1 toStatus 2) { // 卖家发货待发货 - 已发货 orderMapper.updateStatus(orderId, 2); } else { throw new RuntimeException(非法状态流转); } }这段代码的核心思想是“状态转移必须显式声明”。fromStatus 和 toStatus 都明确写出从哪到哪不允许出现待发货直接跳到已完成这种跳变。实际项目里还会加上时间记录比如发货时间、成交时间这些字段在订单表里都有对应的 DATETIME 列。如果你拿到手的源码把状态流转逻辑散落在各个页面里那是个危险信号说明改起来容易出并发问题。订单模块还有个绕不开的现实真实支付需要商户号和支付资质毕设和大多数演示项目都不会接真实支付。常见做法是用一个“模拟支付”按钮代替点击后直接调用后端把订单从 0 改成 1并弹出提示“演示环境未接入真实支付”。这个设计在答辩时一定要主动说明不然老师问“支付成功回调怎么处理的”会很尴尬。5. 二手交易小程序开发避坑指南5 个必踩的坑与排查路径5.1 数据库导入报错 1064MySQL 版本语法不匹配现象用图形工具或命令行导入 SQL 文件时报 ERROR 1064 (42000) You have an error in your SQL syntax报错位置在某个建表语句的结尾。原因大多数源码包的 SQL 文件是在 MySQL 8.0 环境下导出的里面可能带上了 8.0 特有的排序规则如 utf8mb4_0900_ai_ci在 MySQL 5.7 上执行就会语法报错。解决先确认本机 MySQL 版本如果本机是 5.7用文本编辑器打开 SQL 文件把所有 utf8mb4_0900_ai_ci 全局替换成 utf8mb4_general_ci再重新导入。如果替换后还报错定位到报错行号把那一行单独粘贴到查询窗口逐句执行通常能立刻看出是多了逗号还是少了分号。5.2 真机预览请求不到接口合法域名与本地回环问题现象在开发者工具模拟器里一切正常商品列表、登录都通一换成真机预览就全部请求失败控制台报 request:fail。原因两个问题叠加。第一开发阶段后端跑在你自己电脑上地址是 localhost手机访问 localhost 访问的是手机自己根本到不了电脑第二真机上微信要求所有请求域名必须在后台配置合法域名且必须是 HTTPSHTTP 的局域网地址必然被拦。解决如果是联调阶段最简单的办法是让手机和电脑连同一个局域网把后端请求地址从 localhost 改成电脑的局域网 IP比如 http://192.168.1.5:8080同时在微信开发者工具的“详情 → 本地设置”里勾选“不校验合法域名”。注意这个选项只在开发版和体验版里生效上线必须换成备案域名加 HTTPS。想省掉域名成本的话把后端迁到云开发是更干净的方案后面进阶章会讲。5.3 图片列表裂图本地路径与服务器路径的边界现象商品发布时图片上传成功数据库里也能看到图片 URL但首页和详情页的图片显示不出来全部裂图。原因最常见的是后端把图片存到了服务器本地数据库里存的是相对路径如 /files/xxx.jpg前端拿到后直接拼在请求域名后面。如果后端没有做静态资源映射或者前端拼的域名端口不对图片就访问不到。另一种情况是开发阶段数据库里残留了原作者机器上的绝对路径比如 C:/Users/某个用户/upload/xxx.jpg换到你机器上自然打不开。解决第一步确认后端是否配置了静态资源映射Spring Boot 里实现 WebMvcConfigurer 把 /files/** 指向本机 upload 目录第二步用浏览器直接访问数据库中存的完整 URL能打开说明后端没问题问题在前端拼地址打不开就检查映射路径。第三步把数据库里历史图片 URL 统一替换成你本机的访问地址或者干脆清掉旧数据重新发布。5.4 接口一直返回 401登录态过期与 token 丢失现象用户刚登录时一切正常过一会儿再点接口全部返回未登录或 401。重新登录又好了过一阵又失效。原因这类项目几乎都用微信登录获取 openid再用 openid 查询用户生成一个自定义 token 存在后端。token 通常设置了过期时间比如 2 小时。前端这边如果每次请求都从本地缓存里读 token 并放到 header那问题多半出在 token 过期后没有重新登录的机制。解决在 request.js 封装的响应处理里加一个 401 分支收到 401 后清空本地登录态跳回登录页或者静默调用 wx.login 重新登录换取新 token。后端的 token 过期时间也可以适当拉长比如改成 7 天但毕设项目够用就行。重点在“统一处理”不能在几十个页面里各写一遍判断不然漏掉一个就很难查。5.5 已售商品还在首页展示列表接口漏了状态过滤现象把某个商品标记为已售或下架后首页和搜索列表里还能看到它点进去却提示已被购买。原因列表接口的 SQL 里没有把 status0 作为强制条件或者前端列表页没有传任何状态参数。这类源码包的商品表里 status 字段是有设计的但接口层写漏了把下架和已售状态的商品也查出来了。解决找到后端商品列表查询的 Mapper 或 SQL在查询条件里加上 AND g.status 0并把商品详情接口也做同样处理——已售商品只能看详情不能触发购买。这个坑虽然小但它直接影响系统可信度答辩演示时被老师看到“已售商品还在首页”是很掉分的事。6. 进阶把跑通的 Demo 改造成能上线跑的版本6.1 三条低成本改造路径云开发、HTTPS、云存储项目跑通只是第一步如果目标是上线或者放到简历里展示三个改造点优先级最高。第一是把后端和数据库迁到微信云开发用云函数替代自建服务器用云数据库替代 MySQL这样免掉了域名备案和 HTTPS 证书配置是最省事的路径。改造工作量不小因为要把所有 wx.request 换成云函数调用方式但换完后不再有本地回环和合法域名的困扰真机随时能测。第二是图片存储迁到云存储。本地磁盘存图的方案在后端重启或换机器后经常丢图而云存储返回的 URL 是公网可访问的天然支持 HTTPS。改动范围很小只动上传接口那一块。第三是如果坚持用自建服务器那就在服务器上配 Nginx给后端接口挂上 HTTPS 证书再把小程序后台的合法域名填上正式域名。这三种路径按开发成本和长期收益排序云开发 云存储加自建后端 纯自建加 HTTPS。6.2 上线前必须自查的清单改造成能跑只是上线前的及格线。我把这类二手交易项目上线前要过一遍的清单列在这里照着查就行。功能层注册登录流程是否支持静默登录失败后的手动处理、商品发布是否校验了必填项和图片数量、订单取消和超时未支付是否有兜底、买家和卖家双方看到的状态文案是否一致。安全层后端接口有没有做登录鉴权所有需要登录才能调的接口是否都校验了 token不能只拦了前端页面。内容层是否做了敏感词过滤用户发布违规商品时有没有举报和下架通道。做完这些自查再回答两个问题我的代码里有没有把数据库密码写死在配置里并提交到公开仓库有没有在控制台打印用户手机号和 openid。这两个问题任何一个没处理好都比功能 bug 更致命。说一句我自己的习惯拿到任何源码包第一件事不是读业务代码而是先把数据库表结构画出来再对着表去看接口。表结构能和业务闭环对上这个项目就值得花时间往下读对不上后面改起来全是无底洞。这套二手交易项目的表设计六张表对应一个完整交易闭环已经算很规整的了。顺着这个思路去改造你会比那些直接解压跑通就交付的人走得远得多。希望这篇能帮到你。本文还有配套的精品资源点击获取