简介这是一套面向微信小程序开发学习者的二手交易平台完整源码覆盖商品发布、浏览、议价、支付及订单管理等核心流程适合希望快速上手小程序电商开发的初中级开发者。资源包为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冗余的卖家昵称和头像避免列表页每次都查用户表、statusonSale/sold/offline/trading、viewCount浏览量、createTime、updateTime。这里有两个容易被新手忽略的点。第一sellerInfo是冗余字段宁可商品发布时多存一份卖家信息也不要列表页每次循环去查数据库否则请求会被拖慢。第二status字段必须用英文字符串枚举不要用数字0/1/2因为后续做筛选时要传给前端做展示映射英文字符串可读性更强也更不容易在if判断里写错。订单集合 orders 是交易闭环的凭证字段这样设计比较稳。订单集合 orders 字段说明表_id、orderNo生成的业务单号给用户看的、goodsId、goodsTitle、goodsImage、price、sellerOpenid、buyerOpenid、statuspending/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}} modeaspectFill/imagelazy-load的原理是图片进入视口时才真正发起加载这对列表页的滑动流畅度帮助非常明显。modeaspectFill会让图片居中裁剪填满容器商品图在这种块状布局里比例比较统一不会出现拉伸变形的问题。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触发下一页请求并做数组拼接。图片全部换成压缩版本列表页只用第一张图且modeaspectFill固定显示尺寸。另外不要把响应里没用的字段比如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字段统计商品被收藏和咨询的次数这些数据后续可以做简单的热门排序和推荐。第三个是代码结构整理把云函数里的公共逻辑抽成一个公共模块比如校验卖家身份、格式化返回码这样后续加功能时不需要每个云函数里复制粘贴。我自己保持的习惯是每次发版前会把数据库里的所有集合导出备份一次因为二手交易的数据一旦丢失比如误删、被刷根本没有补救手段。这不是危言耸听我确实见过有团队为了省事不备份结果一个误操作导致所有商品数据全没了的案例。这套方案从时间成本上讲一个人从零开始大概两到三周能跑完。如果手里已经有源码重点工程量在于改权限、收口云函数、调整图片上传链路这三件事。做完这些你的二手交易小程序才算真正具备上线测试的底线质量。希望帮到你。本文还有配套的精品资源点击获取