企业官网建设流程全解析

校园里的二手交易，其实是个挺矛盾的市场。一届学生毕业，书、台灯、自行车、电风扇，扔了可惜，带走又沉；另一边新生入学，什么都得置办，全新的贵，二手的没处找。这种场景天然适合微信小程序：不用下载App，扫一扫就能进，同校认证一下身份就能买卖。但真动手做的时候你会发现，开发工作量不小，还要考虑以后上架安卓应用市场、接微信支付，这时候用 UniApp 做一套跨端代码，性价比就出来了。这篇文章把我从一个学生项目做到可实际交付的全过程、选型逻辑和各种坑，完整梳理一遍，给打算做类似校园交易平台的同学一个可以直接参考的底稿。

1. 校园场景是二手交易最尴尬的战场，也是微信小程序最对口的舞台

1.1 我看过的那些校园二手项目的死法

做这个项目之前，我特意去翻了一圈市面上的同类产品。闲鱼没有校园隔离，二手教材九成新五块钱包邮，买家还要担心是不是盗版；各种校园集市公众号，本质是个信息列表，点进去加微信线下聊，平台方完全管不住交易纠纷。这些产品最大的问题不是功能不行，而是"信任半径"没解决好。

大学校园是一个典型的封闭熟人网络，学生信任"本校同学"远高于信任"陌生网友"。但光有信任还不够，校园二手交易的频次极低——一个学生一学期可能就买卖三五次，这意味着用户不会天天打开App。微信小程序的"用完即走"在这里反而是优点，扫个码、搜一下就能进来，不需要下载，不会被卸载，下次要用再打开就是。所以这个赛道不是没有需求，而是以前的产品形态配不上这个需求。

1.2 为什么是微信小程序 + UniApp 而不是原生

如果你只做微信小程序，用原生语法写没问题。但校园二手平台几乎一定会遇到这两个扩展需求：一是学校或创业团队往往同时想要一个管理后台的H5版本，方便运营人员手机上审核商品；二是如果项目最后要参加比赛或向学校信息化办公室交付，安卓App版本几乎是被问得最多的东西。

UniApp 的价值就在这里。一套 Vue 语法的代码，编译到微信小程序、H5、安卓App三端，UI 层面用 uni-ui 或 uView 补齐组件，接口层统一封装 request。我这次的实际体感是：小程序端和H5端大概有 95% 的代码可以完全复用，安卓App端因为要处理原生插件和权限，复用率会降到 80% 左右，但这个性价比已经很值了。你多付出的代价是：一些微信特有的 API（比如wx.login的返回结构、订阅消息的templateId）需要做条件编译或单独封装，这属于一次性成本。

2. 平台核心模块与数据模型：先把买卖闭环画清楚

2.1 买家视角与卖家视角的信息架构

开发之前我花了很大精力梳理信息架构，因为二手交易不是简单的"发商品-浏览-下单"，买卖双方的行为路径差异很大。

卖家侧的核心动作是"发布"：拍照、填标题、选分类、定价格、写描述、选择交易地点。这里最容易被忽略的是"新旧程度"和"交易方式"，我在表单里加了这两个字段，后面发现对转化率影响很大。买家侧的核心动作是"发现"和"联系"：首页按分类浏览、搜索框按关键词搜、商品详情页看图和描述，然后点击"联系卖家"进入会话。校园二手交易基本没有线上的物流和支付闭环，绝大多数是当面交易，所以平台要做的是把"沟通效率"做到极致，而不是硬套电商的下单流程。

2.2 商品、订单、用户三张核心集合的设计

如果用云开发，数据库不需要建表，直接设计集合（Collection）就行。我最终沉淀下来三张核心集合，字段设计如下。

商品集合（goods）我重点加了这些字段：status用数字表示上架/下架/已售出/审核中/被举报，school存学校编码而不是学校名字符串，方便后续按学校维度做筛选，images用数组存云存储的文件ID而不是完整URL，这样迁移成本低而且云存储自带CDN加速。还有一个字段很多人会漏掉：viewCount浏览量，这在校园场景里是天然的排序权重，后续做推荐和置顶功能都依赖它。

用户集合（users）绑定微信的openid，另加studentId、realName、avatar、creditScore信用分。订单集合（orders）在二手平台里其实承担的是"交易凭证"角色，字段包括goodsId、sellerId、buyerId、status（待取件/已完成/已取消）、takeCode取件码。如果完全不做线上订单，交易纠纷时平台方没有任何数据依据，所以我的建议是哪怕流程简化，订单表一定要有。

2.3 学号认证是校园平台的第一道护城河

校园二手平台和闲鱼最大的区别就是"校园认证"。没有认证，校外人员混进来发广告、做诈骗，平台很快就废了。

认证方案我建议做两级：第一级是学号+姓名匹配，调用学校教务系统或统一身份认证接口，这个需要学校信息化办公室配合；如果拿不到接口，就做第二级——学生证/一卡通照片人工审核。在 UniApp 里用uni.chooseImage选图然后传给后端，管理员在管理端逐条审核。实测一个运营人员一天能审几百条，完全够用。

同时，发帖权限必须和认证状态挂钩：未认证用户可以浏览、搜索，但不能发布商品和留言，这样能有效拦掉垃圾内容。认证的过程嵌入到首次发布商品时触发，让用户不是因为"要注册"而完成认证，而是因为"想卖东西"而认证，转化率会高很多。

3. 开发链路里绕不开的十个细节

3.1 页面跳转与路由参数：onLoad 里那点事

UniApp 页面跳转最常见的写法是uni.navigateTo({ url: '/pages/goods/detail?id=' + id })，然后在详情页的onLoad(options)里拿options.id。这个逻辑很简单，但实际开发中我踩过一个隐藏很深的坑：当商品ID里含有特殊字符时，options.id会被 URL 编码，取出来是%E6%...这种字符串，直接去数据库查会查不到。解决方案是传参前用encodeURIComponent包一层，接收后用decodeURIComponent解回来。

还有一个场景：从首页的"我发布的商品"进入详情，同时又要显示"编辑"按钮，这时候需要用参数区分来源。我是加了一个from参数，取值home或mine，详情页根据这个值决定是否渲染底部按钮。注意不要在onLoad里做过重的初始化逻辑，因为页面从列表页跳过来时，有时需要先在onShow里刷新数据，否则返回上一页再进来，数据不会更新。

3.2 自定义分享被全局覆盖，怎么解

这是一个很隐蔽的坑。我在App.vue里写了一个全局的onShareAppMessage方法处理友盟统计和默认分享文案，结果发现所有页面的自定义分享都失效了。原因是页面级onShareAppMessage的优先级高于全局，但我在全局方法里用了return { title, path }，只要页面自己没有定义这个生命周期，微信就会调用全局的，看起来一切正常，一旦某个页面定义了自定义分享，两个方法之间不会做合并，全局配置就被"静默覆盖"了。

解决方案是：在全局分享方法里做一次判断，如果this.$options或自定义属性里标记了"本页使用默认分享"，就走统一逻辑；否则放行页面自定义。实际落地时我是给每个页面组件加了一个customShare的 option，在全局方法里读不到就返回统一文案，读到了就return空对象让微信走系统默认，再配合页面的自定义onShareAppMessage使用。这里逻辑不难，但如果不熟悉 Vue 组件的 option 合并机制，排查起来会比较痛苦。

3.3 视频列表限播与滑出可视区自动暂停

二手商品描述里经常要放一段使用视频，比如自行车链条是否顺滑、电子琴按键是否灵敏。商品列表页如果使用video组件一次性渲染所有视频，性能会直接崩掉，而且多个视频同时加载会互相抢占带宽。我最终的实现方案是：列表页只显示第一帧封面图，点击封面后才动态创建video组件并播放；同时监听页面滚动，当前播放的视频滑出可视区就立即暂停。

这里用到了IntersectionObserver或者小程序里的createIntersectionObserver，核心逻辑是拿到视频组件实例后，监听它的boundingClientRect与视口底部的相交状态。配合 UniApp 的onPageScroll，每滚动一次计算当前视频是否还在可视范围内，不在就调用videoContext.stop()。实测在 iOS 上video组件全屏时会覆盖其他元素，这是官方已知问题，解决方案是不要在全屏模式下做复杂的层级覆盖，尽量引导用户用非全屏播放。

3.4 popup 弹层背后的滚动穿透

选择交易地点、筛选分类时我用到了uni-popup，弹层打开后，底层的商品列表仍然能滚动，这种"滚动穿透"在移动端体验非常差。uni-popup本身有@close事件，但只关闭弹层不会自动锁住页面滚动。

我的处理方式是在弹层打开时给页面根节点加一个overflow: hidden的 class，关闭时移除。但在小程序里直接操作document.body.style.overflow是不生效的，得用页面级配置：通过uni.pageScrollTo({ scrollTop: 0 })把页面滚回顶部，然后配合遮罩层的catchtouchmove阻止触屏滚动事件向下传递。更彻底的做法是使用官方page-meta组件的page-style属性，动态切换overflow: hidden。如果你用的是 Vue3 版本的 UniApp，page-meta的兼容性会更好，可以优先试这个方案。

3.5 软键盘把查询内容顶没了？调整位置也要分场景

搜索页面里输入关键词时，iOS 上软键盘会直接把搜索框顶到屏幕上方，看起来搜索框还在但下面的搜索历史被遮住，这种问题在 H5 端特别常见。我试过adjust-position="false"，结果治标不治本：键盘不顶了，但输入框本身也被键盘挡住，用户看不到自己打的内容。

最终方案是结合uni.onKeyboardHeightChange监听键盘高度，动态给搜索列表容器加padding-bottom。安卓上部分国产 ROM 的键盘高度变化事件不会连续触发，需要在键盘弹出后延迟 100ms 再读取一次高度。另外，在 iOS 的 Safari 里，输入框聚焦时页面会被强制上顶，这时候给输入框的父容器设position: fixed能缓解，但要注意和自定义导航栏的高度计算配合，否则固定定位会偏移。

3.6 扫码取件：从"扫出一串数字"到真的能用

我做了扫码取件功能：买家当面交易时扫卖家出示的取件码，确认收货。但uni.scanCode扫出来的默认是一段字符串，如果直接用result字段里的数字去匹配，可能出现前导零被吞掉的问题。业务上取件码我都用字符串存储而不是数字，同时用String(result).trim()去空格再比对。更重要的一点：扫码结果第一次可能回调成功但用户在回调里做了异步请求，要防止重复扫码触发多次回调，我用了一个isProcessing的布尔锁，请求期间直接 return。

4. 支付与合规：比功能开发更头疼的两座山

4.1 微信支付 v3 对接的关键链路

很多同学做到支付环节就卡住了，因为微信支付 v3 的文档写得比较绕，而且新版要求必须用证书和平台公钥做签名验证。我的经验是：小程序端千万不要自己拼支付参数，全部交给后端，后端负责调用「统一下单」接口拿到payment参数，前端只负责接收并调用uni.requestPayment。

UniApp 里uni.requestPayment的provider字段在微信小程序端不需要传，但在 App 端必须传wxpay。后端对接 v3 时，注意请求头的Authorization要按要求生成，使用商户私钥对HTTP方法 + 换行 + URL + 换行 + 时间戳 + 换行 + 随机串 + 换行 + 请求体做 SHA256-RSA2048 签名。我第一次对接时验签不通过，排查了半天发现是待签名字符串里把 URL 的 query 部分也带上了，v3 规范只要求路径部分。

4.2 隐私政策与用户协议的合规处理

这个属于平台上线前必须处理的问题。微信小程序在提审时要配置用户隐私保护指引，涉及获取用户信息、位置、相册等都要逐个声明。我在 UniApp 里做了一个隐私弹窗，首次启动时弹出用户协议和隐私政策，用户点击"同意"后才会调用uni.login和uni.getUserProfile，这个顺序不能反，否则会被判定为违规。

App 端更狠，iOS 上如果用户点了"不同意"，应用必须退出，否则审核直接打回。从热搜词里就能看到，很多人在问"uniapp ios app 当用户不同意隐私政策及用户协议时退出 app 的代码如何实现"。我的做法是：弹窗拒绝按钮触发plus.runtime.quit()退出 App。这个 API 在 android 端也能用，但要注意调用时机，最好在用户点击拒绝且确认弹窗后再执行，避免误触。小程序端没有退出机制，拒绝后只能停留在引导页，这时要隐藏所有需要登录授权的入口，避免用户在没有同意协议的情况下触发敏感 API。

5. 运行调试与打包上架：从 HBuilderX 到各应用市场

5.1 "运行到微信开发者工具没反应"的排查顺序

这是 UniApp 开发里被问得最多的问题，通常表现为 HBuilderX 点运行后，微信开发者工具没有自动打开，或者打开了但没有加载项目。我的排查顺序是这样：先在 HBuilderX 的控制台看编译输出，确认项目是否成功编译到dist/dev/mp-weixin目录；然后再看微信开发者工具是否开启了服务端口（设置-安全设置-服务端口），这步漏掉会导致外部调用被拦截；最后确认项目路径是否包含中文字符，这个问题我遇到过两次，微信开发者工具对中文路径的支持一直不算稳定。

如果你在微信开发者工具里编译报错，看到module不存在之类的提示，大概率是项目依赖没有安装完整，先删掉node_modules和package-lock.json再重新npm install。另外，微信开发者工具的调试基础库版本也要注意，如果基础库版本太低，uni-popup等组件可能白屏，最好设置为最新的稳定版本。

5.2 manifest 配置与 App 上架注意事项

UniApp 的manifest.json是整个项目的"门面"，微信小程序端的appid、App 端的包名、版本号、图标、启动图都在这配。实际打包 App 时，图标和启动图必须按官方要求各尺寸都提供，否则打包工具会提示缺少资源。我在做安卓应用市场上架时踩得最深的是签名问题：市场要求必须用正式签名文件打正式包，cloud打包时填写的证书指纹必须和签名文件一致，否则提交审核会被判"包名不一致"。

用 HBuilderX 云打包时，首次需要自己在本地生成 keystore 签名文件，这个文件一定要备份好，丢了就只能换包名重新上架。上架后各市场会要求你补充「软件著作权」「ICP 备案」等资质，校园项目如果是用学校名义申请，可以走学校的信息化流程，个人名义的话需要提前办好个体工商户或公司资质，这块提前准备能省很多时间。

6. 运营阶段被问到最多的四个问题

6.1 商品审核是自动还是人工

我的建议是做"关键词过滤 + 人工抽审"的组合。关键词过滤用正则匹配色情、赌博、代写、兼职诈骗等高风险词，命中后商品直接进入待审核状态；其他正常商品先上架显示，管理员每天花半小时在后台抽审。完全依赖人工审核会拖慢发帖效率，完全依赖自动过滤又拦不住图片里的违规信息，所以双轨制最稳妥。

6.2 "消息未读"和"会话列表"是怎么实现的

校园二手交易本质上是"人与人沟通"的平台，IM 是最容易被低估的功能。我没有自研即时通讯，而是用了微信客服消息 + 模板消息的轻量方案：买家点击商品详情页的"联系卖家"，后台调用客服消息接口把卖家的openid带上，买家用客服消息和卖家聊天，卖家如果在 48 小时内有回复，就可以持续对话。消息通知用订阅消息，需要用户主动订阅"交易提醒"，注意订阅消息的一次性限制，下单成功后引导用户订阅「卖家发货通知」和「买家确认收货通知」两条，不能贪多。

6.3 管理后台看什么数据

我当时做了三个维度：基础数据（新增用户、活跃数、商品发布量）、交易数据（订单数、成交额、转化率）、内容数据（举报量、违规量、审核通过率）。用 ECharts 做可视化，UniApp 里可以直接用lime-echart这个插件封装，图表性能在小程序端表现不错。运营一段时间后你会发现，最需要盯的是"商品动销率"，也就是上架商品里多少比例能在一个月内成交，这个数字低于 20% 说明商品质量或定价引导有问题。

6.4 举报和信用分怎么落地

用户在商品详情页可以一键举报，后台收到举报后把商品下架，并给卖家记一次违规。违规累计三次，账号锁定发布功能一个月。信用分则是一个 0-100 的加权值：完成一单交易加 2 分，被举报核实扣 10 分，实名认证加 5 分。信用分显示在商品卡片和卖家主页，作为买家判断是否交易的参考依据。实际上这个机制对交易纠纷的缓解作用有限，但它给了用户一个"平台在管理"的心理暗示，这个心理暗示本身就能劝退一部分随意违约的人。

说了这么多，最后给你一个比较实在的建议：校园二手交易平台这类项目，功能开发最多只占一半工作量，另一半在认证设计、内容审核、合规配置和上架流程上。如果你是用它来做毕业设计，优先把核心交易闭环做得干净漂亮，把 UniApp 的多端复用能力展示出来，会比堆一堆花哨功能更容易拿高分；如果你是想真正在校内运营起来，那就先找一个规模小的学院试点，把商品审核和交易纠纷的处理流程跑顺了再扩大范围，这样整个平台的氛围和信任感才立得住。