简介：这是一套面向微信小程序开发学习者的二手交易平台完整源码，覆盖商品发布、浏览、议价、支付及订单管理等核心流程，适合希望快速上手小程序电商开发的初中级开发者。资源包为zip压缩格式，共54个文件，包含wxml页面结构、wxss页面样式、js交互逻辑与json配置文件，另有png/jpg图片资源用于界面展示与商品占位图，整体大小约1.28MB，结构紧凑，便于导入微信开发者工具运行与二次修改。目前已有8813人学习下载，具备较高参考热度。开发者可从这套源码中系统学习小程序目录组织、数据绑定与事件处理、页面跳转及本地数据交互等实战技巧，并对照源码理解用户认证、商品发布、支付接口与交易流程等关键模块的实现思路，为自建商城或毕业设计提供可直接修改运行的代码范式。
1. 这个标题在讲什么：二手交易的完整闭环，不是套个商城模板那么简单
“微信小程序二手交易平台 源码 程序”这句话，我第一反应不是去评价代码质量，而是先看它解决什么问题。二手交易和普通电商最大的区别在于：商品是非标的、卖家是个人、交易撮合占主导。一套能跑的源码，至少要覆盖发布、浏览、沟通、下单、状态流转这几个环节，缺一个都会让买卖双方卡住。我做过一个模拟项目X，把某高校内部的教材和数码设备流转做成了小程序，跑通之后最深的体会是：真正花时间的不是页面UI，而是用户体系、商品状态和订单状态怎么设计得让两个陌生人都敢交易。
所以这篇笔记的目标很明确：让想做二手交易小程序的从业者，看完就能判断这个方向值不值得投入、源码拿回来怎么改、改的时候重点看哪几个模块。新手能照着把环境跑起来，熟手能直接看参数和边界。至于“源码程序”里的代码，我会拆成几个关键模块来讲，不糊弄你。
2. 选型与地基：云开发还是自建后端，登录和用户体系要怎么落
2.1 为什么先定后端方案再做页面
很多二手交易小程序的源码一拿到手，第一眼全是页面文件夹，容易让人以为前端是核心。实际上这类程序里最影响开发速度、部署成本、以及后续能不能通过审核的，是后端方案。
常见的做法有两种。第一种是自建服务器，用传统的REST接口加MySQL，小程序端用wx.request去请求。第二种是直接用微信云开发，数据库、云函数、存储都放在微信的云环境里。我一般会建议个人开发者、小团队、以及做校内或社区级二手交易的人直接选云开发。理由很简单：不需要买服务器、不需要备案、不需要自己维护HTTPS域名配置，云函数天然免鉴权地拿到用户的openid，这正好是二手交易里做用户身份隔离最需要的能力。
选型时看三个硬指标。第一，用户量预期是几千还是几十万，云开发的数据库并发和调用费用在初期基本可以忽略；第二，团队里有没有人扛得住Linux和MySQL运维，没有就别给自己挖坑；第三，审核周期，自建服务器需要配域名和HTTPS证书，云开发省掉这个环节。表格对比下来会更直观：
后端方案 | 部署成本 | 用户openid获取 | 数据库安全规则 | 适合谁 自建服务器 | 高，需域名备案 | 需自己调code2session接口 | 全靠接口自己写校验 | 有后端团队、要求完全自主可控 微信云开发 | 低，免域名免备案 | 云函数内一行代码获取 | 自带权限控制，按集合配置 | 个人、小团队、校园/社区项目
我们接下来的所有代码和踩坑，都围绕云开发这套方案展开，这是目前这类小程序最主流、最省力的路径。
2.2 数据库集合规划：用户、商品、订单三个集合怎么设计
二手交易小程序的数据模型，比普通电商要更重视“状态字段”。因为个人卖家的商品会有上架、下架、已售出、交易中这些状态，而订单又有待确认、待交易、已完成、已取消的状态。状态字段设计好了，后面写查询和状态流转就会很顺，设计不好，代码里到处都是一堆if判断。
用户集合里我常用的字段如下，注意openid是不能伪造的，它是微信侧的身份标识，整个程序里所有和“这是谁”有关的逻辑都依赖它。
用户集合 users：_id、openid、nickName、avatarUrl、phone、status、createTime。其中status用来标记用户是否被禁言或封禁，二手交易里遇到恶意买家或卖家时很有用。
商品集合 goods 是核心，字段设计直接影响列表页和详情页的查询效率。推荐用这种方式。
商品集合 goods 字段说明表：_id（商品唯一标识）、title（标题，建议限制30字以内）、description（详细描述）、price（价格，用数字类型，避免字符串比较出问题）、category（分类，用编码如book/electronics/daily）、images（图片fileID数组，最多9张）、sellerOpenid（卖家openid）、sellerInfo（冗余的卖家昵称和头像，避免列表页每次都查用户表）、status（onSale/sold/offline/trading）、viewCount（浏览量）、createTime、updateTime。
这里有两个容易被新手忽略的点。第一，sellerInfo是冗余字段，宁可商品发布时多存一份卖家信息，也不要列表页每次循环去查数据库，否则请求会被拖慢。第二，status字段必须用英文字符串枚举，不要用数字0/1/2，因为后续做筛选时要传给前端做展示映射，英文字符串可读性更强，也更不容易在if判断里写错。
订单集合 orders 是交易闭环的凭证，字段这样设计比较稳。
订单集合 orders 字段说明表：_id、orderNo（生成的业务单号，给用户看的）、goodsId、goodsTitle、goodsImage、price、sellerOpenid、buyerOpenid、status（pending/accepted/completed/cancelled）、contactInfo（买卖双方约定的交易方式，如线下地点或手机号）、createTime、updateTime。
2.3 登录云函数：三行代码拿到openid，正确姿势是封装成公共调用
很多初学者一上来就在前端用wx.login拿code，然后自己拼参数去调微信接口。真相是云开发环境里完全不需要这么麻烦。云函数可以直接从上下文里拿到用户的openid，连code都不需要传。这是一种把复杂留给云、把简单留给自己的方式。
先初始化云开发环境。在app.js里加这段：
// app.js App({ onLaunch() { wx.cloud.init({ env: 'cloud1-xxxxxxx', // 换成你自己的云环境ID traceUser: true }); } });这段代码的逻辑说明：env参数填的是云开发控制台里的环境ID，不是环境名称，注意别复制错了。traceUser设为true是为方便在云开发控制台里查看访问来源，上线时留着不影响性能。
然后写一个登录云函数，专门负责给前端返回当前的openid和用户数据。云函数目录结构是 cloudfunctions/login/index.js。
// cloudfunctions/login/index.js const cloud = require('wx-server-sdk'); cloud.init(); exports.main = async (event, context) => { const wxContext = cloud.getWXContext(); const openid = wxContext.OPENID; const db = cloud.database(); const users = db.collection('users'); // 查一下这个openid是否已经注册过 const res = await users.where({ openid }).get(); if (res.data.length === 0) { // 首次登录，用默认昵称创建用户 await users.add({ data: { openid, nickName: '微信用户', avatarUrl: '', createTime: Date.now(), status: 'normal' } }); } return { openid, isNewUser: res.data.length === 0 }; };参数说明：getWXContext()是云函数的特权，不需要传参数就能拿到OPENID和APPID。首次登录时自动在users集合里插一条记录，这样后面发布商品、下单时可以直接引用这条记录，不需要再判空。这段代码前端怎么调用呢？在页面的onLoad里加：
// pages/index/index.js const db = wx.cloud.database(); Page({ async onLoad() { const res = await wx.cloud.callFunction({ name: 'login' }); console.log(res.result.openid); // 当前用户的openid } });这里的调用不用传任何参数，云函数自己会识别用户身份。注意：不要在前端用wx.cloud.database()直接附加openid条件来伪造身份，因为云开发数据库在客户端侧的写入权限是可以被任意用户调用的，必须靠云函数或安全规则来兜底。这就是为什么登录、发布、下单这类关键动作要放在云函数里做，而不是直接在小程序端写库。
2.4 数据库权限：这步配错了，你的数据会被别人删空
云开发数据库在“仅创建者可写，所有人可读”这类预设规则之外，还支持自定义安全规则。二手交易程序的商品需要所有人可读，但只有卖家自己能改；订单则需要买卖双方都能读，且只有特定状态流转时能写。
在云开发控制台里，数据库集合的权限设置建议按这套来配：
users集合：仅创建者可读写。用户只能改自己的资料，别人无权查看openid之外的敏感信息。
goods集合：自定义安全规则，所有用户可读，仅创建者可写。云函数不受安全规则限制，所以下架、标记已售这类操作都走云函数。
orders集合：仅创建者可读写。但问题来了：订单涉及买卖双方两个人。如果直接把集合权限设为“仅创建者可读写”，买家创建的订单卖家就读不到。所以正确做法是：orders集合在客户端设为“所有用户不可读写”，然后在云函数里用管理端权限去读写订单表。云函数使用的是服务端特权，不受安全规则限制，由我们自己在代码里校验“当前用户是不是这笔订单的买家或卖家”。
这是整类小程序里最容易踩的暗坑。很多源码直接把集合设成“所有用户可读，仅创建者可写”，是图省事，结果就是用户可以用开发者工具直接改别人的订单状态。后面避坑章节会专门展开讲。
3. 商品发布闭环：图片压缩、上传与数据落库的完整链路
3.1 图片处理：为什么不能拿原图直接传到云存储
二手交易的商品图通常是手机拍的，一张图动辄3~5MB。如果发布时直接传给云存储，列表页加载时就会非常卡，而且云存储的下载流量是按量计费的，图片越大你的成本越高。这类程序的第一个性能瓶颈几乎都出在图片上。
我一般会在前端用wx.compressImage先压缩，再上传。它支持指定quality质量，压缩后的图通常能控制在200KB左右，对商品展示来说完全够用。有人问为什么不用画布canvas去裁剪，因为compressedImage简单且是官方接口，不用处理iOS和安卓上canvas的兼容性差异。
先看选择图片并压缩的代码：
// pages/publish/publish.js async chooseAndCompressImages() { const res = await wx.chooseMedia({ count: 9, mediaType: ['image'], sourceType: ['album', 'camera'], sizeType: ['compressed'] }); const compressedList = []; for (let i = 0; i < res.tempFiles.length; i++) { const file = res.tempFiles[i]; const compressRes = await wx.compressImage({ src: file.tempFilePath, quality: 80 }); compressedList.push(compressRes.tempFilePath); } this.setData({ tempImagePaths: compressedList }); }参数说明：count最多9张，与商品图片字段的数组长度对应。sizeType里的compressed表示系统相册优先选择压缩版本，但这并不保险，所以后面还要用compressImage再压一道。quality设为80是一个平衡点，太低图会糊，太高压缩效果不明显。
然后是把图片传到云存储并拿回fileID：
// 逐张上传，拿fileID async uploadImages() { const cloudPath = `goods/${Date.now()}-${Math.random().toString(36).slice(2)}.jpg`; const res = await wx.cloud.uploadFile({ cloudPath, // 云存储路径，必须唯一 filePath: this.data.tempImagePaths[0] }); return res.fileID; }注意：cloudPath一定要保证唯一，否则后上传的图片会覆盖之前的。常见做法是时间戳加随机字符串拼接。fileID是云存储返回的标识，它可以在小程序端直接赋值给image组件的src属性，不需要额外的下载转链接操作，这比自建服务器省了一道鉴权流程。
3.2 发布表单与数据落库：提交时统一走云函数
图片上传完成拿到fileID数组后，才轮到提交商品信息。页面里的表单字段对应goods集合的那几个字段，提交动作不要在客户端直接调db.collection('goods').add，因为客户端add会受到安全规则限制而且容易被篡改。正确姿势是再包一层云函数。
发布商品的云函数 protoType 如下：
// cloudfunctions/publishGoods/index.js const cloud = require('wx-server-sdk'); cloud.init(); const db = cloud.database(); exports.main = async (event, context) => { const { OPENID } = cloud.getWXContext(); const { title, description, price, category, images } = event; // 基本校验，不能在云函数里省 if (!title || title.length > 30) return { code: 400, msg: '标题不能为空且不超过30字' }; if (!price || typeof price !== 'number' || price <= 0) return { code: 400, msg: '价格必须是正数' }; if (!images || images.length === 0) return { code: 400, msg: '请至少上传一张图片' }; const res = await db.collection('goods').add({ data: { title, description, price, category, images, sellerOpenid: OPENID, sellerInfo: event.sellerInfo, status: 'onSale', viewCount: 0, createTime: Date.now(), updateTime: Date.now() } }); return { code: 0, id: res._id }; };这段发布代码里最重要的不是add，而是云函数里的入参校验。因为客户端发过来的price可能是字符串，也可能是负数，如果直接入库，后面做价格排序、范围筛选时会出各种玄学问题。所以在云函数里统一强制typeof校验，任何一个字段不合格就直接拒绝。sellerInfo建议前端从用户storage里读取后随手传过来，后端不校验这个字段，因为即便被篡改也只会影响他自己的展示，核心的数据归属始终以OPENID为准。
3.3 列表页与分页：为什么不能一次把所有商品都查出来
商品列表是访问量最大的接口，也是最容易因为写法不对被拖垮的。新手常见的翻车现场是：一次性把goods表里所有onSale状态的商品查出来，然后前端做分类筛选——数据量到几千条时页面白屏，云函数报超时。正确的做法是后端分页加条件查询。
// cloudfunctions/getGoodsList/index.js exports.main = async (event) => { const { page = 1, pageSize = 10, category } = event; const db = cloud.database(); const goods = db.collection('goods'); const where = { status: 'onSale' }; if (category) where.category = category; const res = await goods.where(where) .orderBy('createTime', 'desc') .skip((page - 1) * pageSize) .limit(pageSize) .get(); return { code: 0, data: res.data, hasMore: res.data.length === pageSize }; };这里有三个关键点。第一，where条件里必须带上status: 'onSale'，否则下架的和卖掉的商品会一起被查出来。第二，orderBy('createTime', 'desc')让最新发布的排前面，二手交易里商品的时效性很重要，用户都倾向于先看新发布的。第三，skip和limit配合做分页，hasMore用来判断前端是否还有下一页。有一个细节是limit上限是20还是100取决于云开发的环境版本，建议pageSize不要超过20，避免踩单次查询条数上限的坑。
前端拿到列表后，渲染时image组件有一个lazy-load属性可以优化加载体验，在wxml里加上就行：
<image src="{{item.images[0]}}" lazy-load="{{true}}" mode="aspectFill"></image>lazy-load的原理是图片进入视口时才真正发起加载，这对列表页的滑动流畅度帮助非常明显。mode="aspectFill"会让图片居中裁剪填满容器，商品图在这种块状布局里比例比较统一，不会出现拉伸变形的问题。
4. 交易闭环：订单状态机与买卖双方各自的边界
4.1 二手订单为什么不能做成“一键购买”
很多参考电商源码的人，上来就把购物车、下单、支付三件套做出来。但二手交易本质上是C2C，买家看中商品后，通常需要和卖家沟通（比如问成色、砍价、约线下见面）。如果直接做成微信支付一键购买，就踩坑了，因为个人主体的微信小程序类目根本开通不了微信支付，而且二手的非标品也不支持无脑购买。
所以这类程序的订单模块，核心是“状态机”，而不是支付流水。我常用的状态流转是这么一套五态模型：
订单状态表：pending（待卖家确认）、accepted（卖家已接单，待交易）、completed（交易完成）、cancelled（买家取消）、refused（卖家拒绝）。其中pending状态下买家可以取消，这很重要，否则如果卖家一直不处理，订单就卡死了。accepted状态下买卖双方可以互相看到联系方式，这时才进入真正的线下或平台担保交易。
这个状态机的设计，本质上是把“沟通”和“交易”两个动作解耦。用户先通过商品详情页联系卖家，双方达成一致后再下单，订单状态的意义是给这段交易一个可追溯的凭证，而不是像电商那样强制付款后自动进入发货流程。
4.2 下单与状态流转的代码实现
下单云函数的入参只有goodsId，因为商品信息和价格都已经存在商品表里了。这个设计有个好处：下单时的价格以商品当前售价为准，不允许买家传一个低价过来改库存。
// cloudfunctions/createOrder/index.js exports.main = async (event) => { const { OPENID: buyerOpenid } = cloud.getWXContext(); const { goodsId } = event; const db = cloud.database(); const goods = db.collection('goods'); const orders = db.collection('orders'); // 查询商品，确认还在售 const goodsRes = await goods.doc(goodsId).get(); const item = goodsRes.data; if (item.status !== 'onSale') return { code: 400, msg: '商品已下架或已售出' }; if (item.sellerOpenid === buyerOpenid) return { code: 400, msg: '不能购买自己的商品' }; // 创建订单 const orderRes = await orders.add({ data: { orderNo: 'R' + Date.now() + Math.floor(Math.random() * 1000), goodsId, goodsTitle: item.title, goodsImage: item.images[0], price: item.price, sellerOpenid: item.sellerOpenid, buyerOpenid, status: 'pending', createTime: Date.now(), updateTime: Date.now() } }); // 商品状态改为交易中，防止其他人重复下单 await goods.doc(goodsId).update({ data: { status: 'trading' } }); return { code: 0, orderId: orderRes._id }; };这一段里有一个容易忽略的关键点：下单成功后，商品状态要从onSale改成trading。不然的话，同一件商品会被多个买家同时下单，等卖家确认时才发现已经答应了别人，造成纠纷。trading状态下的商品不能再被下单，这就用最简单的方式实现了“并发下的库存锁”。
卖家端确认接单的云函数reverse操作类似，是update订单状态由pending改成accepted，同时把商品状态改成sold防止再流入列表。这里要注意：卖家的身份校验同样是通过getWXContext拿openid，然后和order.sellerOpenid比对，不一致直接拒绝。这个校验不能放在前端做，否则伪造一个订单ID就能把别人的订单状态改掉。
4.3 支付与担保交易的三种边缘方案
没有微信支付，交易怎么完成？这是二手交易小程序被问得最多的问题，也是很多源码demo里没有交代清楚的部分。我实际看过好几套源码，有的直接挂一个“货到付款”的假按钮，有的假装调起支付然后写死成功。这些做法要么无法上线，要么审核直接被拒。
业内比较稳妥的常见做法有三种，按推荐度排序：
第一种，线下当面交易：小程序承担信息撮合和信用背书功能，订单状态推进到accepted之后，双方通过预留的手机号或微信联系，线下见面验货付款，然后在线上点“确认完成”。这套模式在校园、同城社区场景里非常适用。
第二种，担保交易模版：平台方有自己的企业主体，接入第三方支付或微信支付商户号，买家付款到平台，卖家发货，买家确认后平台再结算给卖家。这是正规二手平台的做法，但对个人开发者不友好，需要企业资质和类目审核。
第三种，保证金模式：买家下单但不付款，双方沟通好之后线下交易，交易完成后平台退保证金。这种其实只是把“订单”当作信用凭证，不涉及真实资金流，审核的时候类目风险也更可控。
我在模拟项目X里用的就是线下当面交易模式，订单状态机在completed时记录一个交易完成时间，方便后面做用户信用分和交易统计。如果你接到的源码是第二种模式，那它的代码复杂度会高很多，需要考虑商户号配置、支付回调验签、退款流程，这些就不是一篇笔记能讲完的了。
5. 二手交易小程序的5个常见坑：权限、图片、列表与登录的排错记录
5.1 数据库权限“所有人可写”，商品被批量删除
现象：某团队的小程序刚上线测试，一晚上商品数据全部清空，后台看不到操作记录。
原因：goods集合的权限被设成了“所有用户可读写”，这意味着任何拿到小程序的人都能通过开发者工具或改包，直接调用数据库API把整张表删光。这类源码里最常见的默认权限，也是最危险的配置。
解决：把goods集合的权限改为“所有用户可读，仅创建者可写”，然后所有写操作（发布、下架、改价、标记售出）全部收口到云函数，云函数里再做一次卖家人校验。避免在前端直接用db.collection('goods').doc().update这种操作。
5.2 图片加载裂图，临时链接失效
现象：商品详情页图片正常，但分享给别人后，对方打开看到全部裂图，或者过一段时间自己再进详情页也是裂图。
原因：图片直接存的是wx.cloud.getTempFileURL生成的临时链接，这个链接时限默认是两小时。很多人把临时链接存进了数据库，结果分享或回访时全失效了。
解决：数据库里图片字段只存云存储的fileID，前端渲染时用image组件的cloud://协议直接赋值。也就是，云开发会自动处理临时链接的转换，不需要开发者手动去换取。不要图方便在发布时就把tempFileURL存库里。
5.3 列表页滑动卡顿，原因是setData塞了太多数据
现象：商品列表超过50个时，模拟器流畅但真机上明显掉帧，滑到后面甚至白屏报错。
原因：setData传输大数据时性能下降是主要原因。有的实现把整个商品列表数组全部setData进data，而且图片还都是高清原图，一次传输几MB，真机内存直接爆。另一个原因是列表滚动时没有使用lazy-load。
解决：分页一次只加载10到20条，前端用onReachBottom触发下一页请求并做数组拼接。图片全部换成压缩版本，列表页只用第一张图且mode="aspectFill"固定显示尺寸。另外，不要把响应里没用的字段（比如description全文）都塞进页面data，列表query的时候只取展示必需的字段。
5.4 登录偶发失败，openid拿的不是当前用户
现象：一个用户在小程序里看到的都是另一个人的商品信息，或者发布商品后商品显示在别人名下。
原因：登录云函数调用频繁时，前端有一个setTimeout后没有清除的隐患，或者某些页面在登录尚未结束时并发发起了多个云函数请求。云函数拿openid本身是准确的，问题大多出在发起请求的时机上——用户点击操作时login还没返回，前端用了一个全局的临时openid做后续请求。
解决：启动时在app.js的onLaunch里先调一次login云函数，把拿到的openid和用户信息缓存到wx.storage里。所有需要用户身份的操作，比如发布、下单、删除，都带上一个从storage里取出的本地身份标识，后端以云函数上下文OPENID为准。同时给关键页面加loading态，禁止用户在登录完成前点击操作。
5.5 订单重复创建，商品同时被多个人下单
现象：同一件商品，在极短时间窗口内被两个买家同时下单成功，卖家接到两笔订单非常困惑。
原因：下单云函数里虽然检查了商品status，但“检查”和“更新状态为trading”是两步操作，中间有时间差。一个请求检查时商品还是onSale，另一个请求紧跟着也检查还是onSale，两个请求都等过了检查再往下走，就都创建成功了。
解决：把两步操作包进数据库事务里，或用update条件限制来解决。补充说明一下条件更新，代码是goods.where({ _id: goodsId, status: 'onSale' }).update({ data: { status: 'trading' } })，如果update的返回结果中stats.updated为0，说明商品已经被改了状态，下单就应当终止。这个写法比事务简单，也是云开发单文档操作时的标准做法。
6. 进阶与验证：从能跑到能上线，我还会动这几个旋钮
到这个阶段，说明你的小程序已经把买卖双方的链路跑通了。下一步不是急着推广，而是先做一次全链路自测。我会在开发者工具里模拟两个账号（一个卖家一个买家），完整走一遍：发布商品、浏览列表、创建订单、卖家接单、确认完成、再上架新商品。在这个过程中，重点检查两个容易被忽略的地方：一是订单状态流转到completed之后，商品状态有没有同步改成sold；二是卖家下架商品后，已创建的pending订单是否还能正常被买家取消。
验证通过之后，进阶的方向有三个。第一个是性能优化，给列表页加一个缓存层，把首页前两页的商品数据缓存到storage，启动时先渲染缓存再拉新数据，体感速度能提升一大截。第二个是数据沉淀，给每个商品加一个likeCount或contactCount字段，统计商品被收藏和咨询的次数，这些数据后续可以做简单的热门排序和推荐。第三个是代码结构整理，把云函数里的公共逻辑抽成一个公共模块，比如校验卖家身份、格式化返回码，这样后续加功能时不需要每个云函数里复制粘贴。
我自己保持的习惯是，每次发版前会把数据库里的所有集合导出备份一次，因为二手交易的数据一旦丢失（比如误删、被刷）根本没有补救手段。这不是危言耸听，我确实见过有团队为了省事不备份，结果一个误操作导致所有商品数据全没了的案例。
这套方案从时间成本上讲，一个人从零开始大概两到三周能跑完。如果手里已经有源码，重点工程量在于改权限、收口云函数、调整图片上传链路这三件事。做完这些，你的二手交易小程序才算真正具备上线测试的底线质量。希望帮到你。
本文还有配套的精品资源，点击获取
