简介：这一份基于微信小程序的校园二手物品交易平台设计源码，面向需要完成毕业设计、课程项目或小程序开发练手的计算机专业学生与开发者。系统采用Java与JavaScript技术栈，结合微信小程序前端、HTML/CSS以及SQL数据库，完整覆盖用户登录、商品发布、浏览检索、留言交易等典型校园交易场景，模块化结构便于二次扩展。资源压缩包共398个文件，约18.57MB，包含82个Java后端逻辑文件、59个JavaScript脚本、25个WXML页面结构及28个WXSS样式文件，同时提供27张PNG图片、75个GIF动图与SQL数据库脚本等，基本涵盖前端页面、后端接口、数据存储与演示素材。按文件类型分布可快速定位代码、样式与资源目录。已有412人学习下载。通过源码可直观了解小程序项目目录组织方式、前后端交互流程及交易平台核心功能实现思路，适合作为校园交易类项目的起步模板。

1. 为什么校园二手交易要绑在微信小程序上，而不是网页或 App

一到毕业季，宿舍楼下就会长出各种“X元自提”的纸条，教材、台灯、电动车、洗衣机全在等一个下家；把这种校园二手物品交易平台搬进微信小程序，相当于把纸条约谈变成可搜索、可预约、有状态的线上货架。这里的“设计源码”和普通网页源码不同，它不只是几个页面，而是包含登录、商品读写、图片存储、交易状态流转的完整前后端工程。用微信小程序做有三个现实理由：学生不用装应用，扫一扫就能用；微信身份能直接认证，省掉注册的繁琐；云开发的云函数、云数据库、云存储三件套刚好覆盖二手交易的核心动作。这篇文章会从一个可运行的源码结构出发，讲清楚选型、目录、前端实现、数据状态机和线上排查，让刚接触的人能照着把它跑起来，也让做过的人少走几个岔路。

2. 先把底牌看清：小程序 + 云开发的选型理由与源码骨架

在动任何代码之前，先回答两个问题：这套源码为什么长这样，改哪里不会把项目改死。校园二手平台通常用户量不大，但对“上线门槛”极度敏感。没有域名备案、没有服务器运维经验，往往是一个校内小项目卡壳的重灾区。微信小程序加云开发把这两件事变成了零成本动作：不需要备案，不需要买服务器，数据库和文件存储都在云端由平台托管。

2.1 为什么选微信小程序 + 云开发：三件套正好覆盖二手交易

微信小程序天然适合校园场景，学生不需要额外安装应用，打开微信扫码就能用；wx.login 拿到的 code 在云函数里可以直接换取 openid，自动获得稳定的用户身份标识。云开发提供云函数、云数据库、云存储三个基础能力，刚好对应二手平台的三类核心对象：云函数处理业务逻辑，云数据库存用户、商品与订单，云存储存商品图片和头像。

常见做法是把整个后端托管在微信云环境里，前端通过 wx.cloud.callFunction 调用云函数，云函数再操作数据库。如果你拿到的源码是自建 Node.js 或 Java 后端也不要紧，前端把调用层从云函数换成正向的 HTTP 请求，页面逻辑可以完全保留。对校园级并发来说，云开发的默认配额足够支撑几千人同时访问；真正限制你的往往不是云函数性能，而是索引有没有建、图片有没有压缩这些看起来不起眼的小事。

2.2 源码目录结构：代码放置方式和数据表设计

我处理过一份典型的二手交易小程序源码，目录结构大致如下：

miniprogram/ app.js # 小程序入口，初始化云环境 app.json # 页面注册与 tabBar pages/ index/ # 首页商品列表 detail/ # 商品详情 publish/ # 发布闲置 orders/ # 我买到的 sales/ # 我卖出的 profile/ # 个人中心 utils/ format.js # 时间、价格格式化 cloudfunctions/ login/ # 获取 openid，写入用户集合 productList/ # 分页查询在售商品 productDetail/ # 商品详情 createProduct/ # 新建商品 reserveProduct/ # “我想要”预约 updateProductStatus/ # 预约/成交/下架

云函数每个目录就是一个独立的功能单元，需要单独安装 wx-server-sdk 依赖。这个结构把读写入口全部收进云函数，客户端不直接操作数据库，是这套源码能安全上线的前提，也是后面第 5 章排查“数据被清空”问题的关键。

数据库一般建立四个集合：users 存 openid 和昵称头像，goods 存商品核心信息，orders 存预约和成交记录，messages 存站内通知。集合尽量精简，不要为“热度统计”“浏览记录”这些非核心功能提前建表。users 集合不需要预先创建记录，用户首次登录时由 login 云函数自动写入；goods 集合要基于 status 和 createTime 建组合索引，否则分页查询超过几十条后速度会明显下降；orders 集合只记录交易维度的变更，不要冗余整份商品快照，避免后续改商品信息还得同步修订单。

商品集合的字段建议按下面这张表设计，宁可写清楚些，也不要等上线后临时加字段。

2.3 把源码跑起来的最小步骤：环境、依赖、页面注册

先说一个跑源码时的通用经验：很多项目“跑不起来”不是代码问题，而是微信开发者工具里没有开通云开发，或 AppID 是测试号。测试号不支持云开发，第一步必须是注册小程序账号并拿到正式 AppID。

接着按顺序做三件事：第一，在开发者工具中选择云开发，创建环境并记录环境 ID；第二，把 miniprogram/app.js 里的 env 换成自己的环境 ID；第三，在每个云函数目录下执行依赖安装，然后右键上传并部署云端安装依赖。

cd cloudfunctions/login npm install wx-server-sdk --save

逻辑说明：部署时选择“云端安装依赖”，可以让云函数在云端自动拉取 wx-server-sdk，避免本地 node_modules 与云端依赖不一致。参数说明：wx-server-sdk 的版本尽量和开发者工具内置版本对齐，如果云函数返回“module not found”，删除本地 node_modules 重新安装通常能解决。所有云函数目录都执行一遍这个命令，再部署，之后才能进入页面开发。

3. 从零跑通小程序端：初始化、登录与发布闲置

这一章解决“打开小程序能不能看到货、能不能把货挂上去”。我会把最小可运行项目的三个关键操作拆开：启动时初始化云环境、登录时拿 openid、发布时传图和写库。这三步是后续所有页面共用的地基，也是新手最容易写错的地方。

3.1 启动入口：app.js 与 app.json 的环境对接

app.js 是每个页面前执行的地方，云开发相关初始化必须放在 onLaunch 里。我见过有人把 wx.cloud.init 写在某个页面的 onLoad 里，结果其他页面先请求云函数时报“Cloud API isn't enabled”，这就是初始化时机不对。

// app.js App({ onLaunch() { if (!wx.cloud) { console.error('当前微信基础库版本过低，请使用 2.2.3 及以上'); return; } wx.cloud.init({ env: 'your-env-id', // 替换为云开发控制台的环境 ID traceUser: true // 在控制台追踪用户访问，便于排查 }); } })

这段代码的逻辑不复杂，但 env 字段有三个容易踩的点。第一，不填 env 会使用默认环境，如果账号下有多个环境，很容易出现“集合查不到数据”；第二，env 填错后不会立即报错，而是所有接口都返回空或权限错误，排查时特别玄学；第三，traceUser 建议保持 true，否则云开发控制台的用户访问分析是空的。这里建议固定写死一个环境 ID，不要用默认值，尤其在多人协作时。

app.json 里需要注册所有页面并配置 tabBar，否则页面跳转会报“page not found”。常见配置是首页、订单、个人三个 tab，发布页用独立跳转不放 tab；页面注册列表写全，是避免白屏的首要检查点。tabBar 的文字和图标路径也要真实存在，否则工具会直接报编译错误而不是运行时错误，新手容易被“突然编译不过”吓到。

3.2 登录与 openid：不要让前端自己传身份

微信小程序里最常见的错误登录写法是把 wx.login 返回的 code 传到后端自己换 session_key，这在自建后端时是标准做法；但在云开发架构里，云函数上下文会直接给出 openid，不需要自己处理 code。更不要相信前端传过来的 userId 或 openid，因为任何人都能伪造请求参数。

登录云函数 login/index.js 的写法如下：

// cloudfunctions/login/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) exports.main = async () => { const { OPENID, APPID } = cloud.getWXContext() const db = cloud.database() const users = db.collection('users') const existed = await users.where({ openid: OPENID }).get() if (existed.data.length === 0) { await users.add({ data: { openid: OPENID, nickname: '', avatar: '', createTime: Date.now() } }) } return { openid: OPENID, appid: APPID } }

逻辑说明：cloud.getWXContext() 返回的是微信在云端解密的用户身份，openid 对每个小程序、每个用户唯一，用它当主键最安全。users 集合“先查再插”能保证同一用户不会重复建记录。参数说明：DYNAMIC_CURRENT_ENV 表示当前云函数所在环境，同一个代码部署到测试环境和生产环境不需要改 env，这是应该长期保持的习惯。

前端在首页 onLoad 里先调 login，等拿到 openid 再渲染列表。很多“真机偶发登录失败”其实不是代码问题，而是页面渲染速度太快，云函数结果还没回来用户已经开始操作。另一个细节是不要长期把 openid 缓存到本地，因为微信账号切换后缓存会让身份错乱；本地只存昵称头像，身份永远以云函数返回为准。

3.3 发布闲置：图片压缩、上传与写库的顺序

发布页是全平台情绪价值最高的页面，同时也是翻车率最高的页面。常见问题是用户选完图点发布，页面卡十秒，最后提示“上传失败”。这个问题的根源不是代码逻辑，而是没有先压缩图片、也没有控制并发上传数量。

发布流程我建议做成四步：表单校验、压缩图片、上传云存储、调用云函数写入商品集合。核心代码如下：

// pages/publish/publish.js async function uploadImages(filePaths) { const tasks = filePaths.map((filePath, index) => { const ext = filePath.match(/\.(\w+)$/)[1] || 'jpg' const cloudPath = `goods/${Date.now()}-${index}-${Math.random().toString(36).slice(2)}.${ext}` return wx.cloud.uploadFile({ cloudPath, filePath }) }) // Promise.all 会同时并发上传，图片数量多时建议分批 const results = await Promise.all(tasks) return results.map(res => res.fileID) } async function handlePublish(formData, images) { if (!formData.title || formData.price <= 0) { wx.showToast({ title: '标题和价格不能为空', icon: 'none' }) return } const compressed = await Promise.all( images.map(src => wx.compressImage({ src, quality: 70 })) ) const fileIDs = await uploadImages(compressed.map(item => item.tempFilePath)) const res = await wx.cloud.callFunction({ name: 'createProduct', data: { ...formData, images: fileIDs, cover: fileIDs[0] || '' } }) wx.showToast({ title: res.result.code === 'OK' ? '发布成功' : '发布失败', icon: 'none' }) }

参数说明：cloudPath 是云端存储路径，写成goods/时间戳-序号-随机串.jpg可以避免重名；注意 cloudPath 不能以斜杠开头。compressImage 返回的是临时文件路径，quality 设为 70 能让一张 3MB 的照片压到 300KB 以下。cover 字段取第一张图作为封面，列表页只用 cover，图片加载速度会好很多。Promise.all 适合 9 张以内的并发，超过建议改成每次 3 张，避免内存峰值。

这里还要提一个产品层面的选择：首版不要做内置聊天。校园二手交易基本都是线下见面，商品页直接展示发布者的微信或电话，反而比聊天窗口更能促成成交。联系方式在发布表单里作为必填项，在详情页只对登录用户展示，这个细节能挡住一部分爬虫。上传和发布是两件事，图片先传到云存储、商品写库失败会产生孤儿图片，兜底方案是发布失败后调用 wx.cloud.deleteFile 删除本次上传的 fileID，或者允许创建 status=0 的草稿，让用户重新编辑而不是重新上传。

4. 核心链路：商品列表、详情页与交易状态机

商品发出来了，接下来要解决“别人能不能看到、能不能买到、成交后状态怎么变”。这一章全是数据和后端逻辑，前端只是把云函数返回的数据渲染到页面上。

4.1 商品列表：分页、筛选和搜索的查询姿势

列表页最忌讳一次性把所有商品拉下来，几百条数据可以直接把渲染线程拖到白屏。正确姿势是分页配合条件查询，把这件事放在云函数 productList 里做：

// cloudfunctions/productList/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() const $ = db.command exports.main = async (event) => { const page = event.page || 1 const pageSize = event.pageSize || 10 const category = event.category || '' const keyword = event.keyword || '' let query = { status: 1 } if (category) query.category = category if (keyword) { const reg = db.RegExp({ regexp: keyword, options: 'i' }) query = $.or([{ title: reg }, { desc: reg }]) } const where = db.collection('goods').where(query) const countRes = await where.count() const listRes = await where .orderBy('createTime', 'desc') .skip((page - 1) * pageSize) .limit(pageSize) .get() return { list: listRes.data, total: countRes.total, hasMore: page * pageSize < countRes.total } }

逻辑说明：先构造查询条件，再用同一个 where 对象先后执行 count 和 get，能保证总数和当页数据来自同一批条件。状态过滤必须在服务端做，只返回 status=1 的在售商品，这样即使有人抓包改参数也看不到下架或已成交商品。参数说明：pageSize 建议限制在 10 到 20，超过 20 对移动端列表没有意义，反而增加云数据库读次数；keyword 用正则模糊匹配在小数据量下够用，数据量到上万条后要换正式搜索方案，但校园场景大概率到不了这个量级。

前端拿到返回结果后，用滚动到底部触发的分页加载追加数据，同时记录 page，避免重复请求。还需要处理下拉刷新：刷新时重置 page=1 并清空列表，再重新请求第一页，否则新商品会被挤到很后面。这里的 skip 分页在数据量到几千条后会变慢，因为数据库要跳过前面的行，但校园二手平台通常几年都攒不到这个量，暂时不需要换成游标分页。

4.2 详情页：区分“我的商品”和“别人的商品”

详情页要做的事有三件：展示图片和联系方式、判断当前用户是不是卖家、展示对应操作按钮。判断逻辑不能只靠前端比对 openid，因为详情接口返回的数据里不该包含完整 openid。更稳妥的做法是云函数返回一个 isOwner 布尔值。

// cloudfunctions/productDetail/index.js exports.main = async (event) => { const { OPENID } = cloud.getWXContext() const goods = await db.collection('goods').doc(event.id).get() const isOwner = goods.data.sellerOpenid === OPENID return { ...goods.data, isOwner, sellerOpenid: undefined } }

这段代码有两个必须养成的习惯。第一，所有返回字段先过一遍，把 openid、unionid 这类敏感字段摘掉；第二，isOwner 由后端计算而不是前端比对，前端拿不到完整数据后，天然就没有“越权改别人商品”的能力。详情页图片区用 swiper 展示，对应 goods.images 数组，首图就是列表页的 cover。如果商品已经下架，详情页仍应正常展示内容，但所有操作按钮都要禁用，让买家知道“来晚一步”。

4.3 交易状态机：从在售到已预约到已成交

校园二手交易不需要复杂的订单流程，线下见面交易居多，线上只需锁住状态避免一物多卖。我用四个状态管理一件闲置的一生：

状态迁移的规则是：1 才能变 2，2 只能由卖家变成 3，2 也可以被买家或卖家变回 1。这里最需要防的是两个人同时把 1 变成 2。云函数 reserveProduct 里我一般用事务：

// cloudfunctions/reserveProduct/index.js exports.main = async (event) => { const { OPENID } = cloud.getWXContext() const transaction = await db.startTransaction() try { const goods = await transaction.collection('goods').doc(event.goodsId).get() if (!goods.data || goods.data.status !== 1 || goods.data.sellerOpenid === OPENID) { await transaction.rollback() return { code: 'FORBIDDEN' } } await transaction.collection('goods').doc(event.goodsId).update({ data: { status: 2, buyerOpenid: OPENID, reserveTime: Date.now() } }) await transaction.collection('orders').add({ data: { goodsId: event.goodsId, sellerOpenid: goods.data.sellerOpenid, buyerOpenid: OPENID, status: 'reserved', createTime: Date.now() } }) await transaction.commit() return { code: 'OK' } } catch (e) { await transaction.rollback() return { code: 'ERROR', message: e.message } } }

逻辑说明：事务会锁定这条商品记录的读取，保证检查状态和更新状态之间没有其他请求插入，从根上杜绝超卖。同时还要拦截“卖家预约自己的商品”，判断 sellerOpenid 和当前 openid 是否相等。参数说明：orders 集合的 status 是字符串，暂用 reserved、done、closed；goods.status 是数字，两边的状态字段不要混用。不要在客户端写这段逻辑，因为它依赖后端身份和事务能力；如果云开发环境不支持事务，退化方案是用where({_id: goodsId, status: 1}).update(...)，通过返回的 updated 数量判断是否抢成功。

4.4 “我买到的”和“我卖出的”：两张列表一张表

很多源码会为“我买到的”单独建一张表，这是冗余。orders 集合已经记录了 goodsId、sellerOpenid、buyerOpenid，查询时按当前 openid 匹配对应角色即可。

// 云函数 getMyOrders const openid = cloud.getWXContext().OPENID const list = await db.collection('orders') .where({ buyerOpenid: openid }) .orderBy('createTime', 'desc') .get()

从代码能看出来，这套设计不需要额外维护“我的收藏”或“浏览记录”，校园二手平台首版功能越少越稳。后续如果要加收藏，单独建 favorites 集合即可，别把字段全堆在 goods 里。列表页展示订单时还需要关联商品标题和封面，常见做法是在返回订单列表后，用 Promise.all 逐个查询商品详情，虽然多几次读操作，但在订单量不大的情况下完全够用。

5. 踩坑与排查：校园二手小程序最容易翻车的五个位置

以下五条不是在网络上看来的建议，而是这类源码跑起来后大概率会踩一遍的真实问题，我按现象、原因、解决的顺序写，遇到问题可以直接按顺序查。

5.1 列表页越来越慢，首屏图半天出不来

现象：商品数据超过 100 条后，首页进入要转圈 2 秒以上，下拉刷新更明显。原因有两个：列表接口把 images 数组里所有图片 fileID 全部返回，上传时也没有压缩，原图一张可能 5MB。解决：列表接口只返回 cover 字段，详情页才返回完整 images 数组；上传前用 wx.compressImage 把 quality 压到 70。这样列表页每个商品只加载一张小图，速度提升立竿见影。如果还想再压缩，可以在换取临时链接后拼接图片处理参数，但那依赖具体的云存储服务，最稳妥的做法是发布时把第一张图单独压成缩略图存到 cover。

5.2 多人同时预约，同一个商品被预约两次

现象：一台热门电动车一发布，三个人几乎同时点“我想要”，结果三人都看到了预约成功。原因：客户端代码是“先查 status 是否为 1，再 update”，两个请求都查到 1，自然都更新成功，这就是典型的先查后改竞态。解决：必须用事务，或者用条件更新。推荐下面这种不需要事务的写法：

const res = await db.collection('goods') .where({ _id: event.goodsId, status: 1 }) .update({ data: { status: 2, buyerOpenid: OPENID } }) if (res.stats.updated === 0) { return { code: 'SOLD_OUT' } }

逻辑说明：update 前的 where 条件把 status=1 作为原子条件带上，数据库只会更新一条匹配记录，没被更新就说明已被别人抢先。这个方案的缺点是难同步写 orders，所以只适合抢单；订单表需要在更新成功后再次写入，如果担心写订单失败，就回到事务方案。

5.3 登录态“一会好一会坏”，真机尤其明显

现象：模拟器上运行一切正常，真机上偶尔出现 openid 为空、云函数报“invalid openid”，或者切换微信号后变成另一个新用户。原因：onLaunch 里 wx.cloud.init 是异步的，页面 onLoad 还没等初始化完成就去调云函数；另外有的代码把 openid 存在本地缓存，但微信切换账号、删小程序重进后缓存还在，身份就会错乱。解决：云函数里始终用 cloud.getWXContext() 取 openid，不要用前端传来的 openid；前端在调用任何云函数前先确保 login 完成，比如首页 onLoad 里 async 等待 login 返回后再渲染。本地缓存可以存用户昵称头像，不能把 openid 当永久身份。

5.4 九张图传上去，发布按钮一点就消失

现象：用户花了两分钟选图上传，最后发布失败，云存储里却多出一堆文件。原因：发布流程是“先传图后写库”，上传全部成功不代表 createProduct 云函数一定成功，任何一步冲突都会留下孤儿文件。解决：把上传结果成功回传后，先写一条状态为 0 的草稿商品记录，等用户确认发布后再改成 1；失败时也能通过 status=0 找到草稿继续编辑，不用重新传图。如果没有草稿表，就在 catch 里调用 wx.cloud.deleteFile 删除本次上传的 fileID。云存储上传的并发建议不要超过 9，Promise.all 传 9 张没有出过问题；如果上传函数里还做压缩，建议改成每次 3 张，避免内存峰值。

5.5 数据库被“热心同学”清空，权限配错是原罪

现象：上线没两天，发现 goods 集合里的数据少了一半，控制台访问记录显示是某个登录用户删的。原因：为了调试方便，把集合权限设成“所有用户可读，所有用户可写”，微信客户端的数据库操作就变成了公共入口，谁都能删。解决：所有集合权限统一设成“仅管理端可读写”，客户端任何直接操作数据库的调用都会失败，业务数据全部走云函数。这是这套源码能长期稳定运行的核心：云函数是唯一数据库入口，权限再多也只在服务端手里。第 2.2 节的目录结构就是为这个目的设计的，如果你拿到一份允许客户端直接读库的源码，建议上线前全部改成云函数中转。

6. 从“能跑”到“有人用”：订阅消息与上线前验证法

前面把功能链路跑通、把数据库权限锁死，这离一个真正的校园二手平台还差一步：交易双方都是懒的，卖家不会一直开着小程序等消息，所以“有人想要”必须主动通知卖家。

6.1 用一次性订阅消息把“我想要”变成通知

常见做法是买家点击“我想要”前触发 wx.requestSubscribeMessage，让用户同意接收订阅消息；同意后调用 reserveProduct 云函数，在成功预约的同时给卖家发送一条订阅消息。订阅消息是一次性的，买家每次操作都要重新授权，这是微信的限制，不要试图绕过。发送消息放在云函数里：

await cloud.openapi.subscribeMessage.send({ touser: sellerOpenid, templateId: '模板ID', page: 'pages/detail/index?id=' + event.goodsId, data: { thing1: { value: '有人想要你的商品' }, thing2: { value: goodsTitle.slice(0, 20) } } })

参数说明：templateId 需要在微信公众平台申请，字段名如 thing1、thing2 必须和模板内容一致，value 超长会被拒绝。页面跳转路径要带 goodsId，方便卖家点进详情直接处理。别把这条消息发在买家预约成功之前，否则会报用户未授权。

6.2 上线前过一遍验证清单

6.3 上线前我的固定动作

每次改完权限或状态机，我都会先用脚本往 goods 集合造 200 条测试数据，把列表分页、搜索、详情全部压一遍，再拿两台真机走完全程：发布、浏览、预约、成交、取消。最后检查一件事：卖家的 openid 不会出现在买家页面的任何返回字段里。这个细节决定源码能不能真正上线，而不是只能演示。校园二手平台不是功能越多越好，它最讲究干净和确定，状态不乱、权限不松，其他都可以慢慢迭代。希望帮到你。

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