校园里闲置物品的流转长期存在一个矛盾：毕业季、换宿舍、课程结束后，大量还能用的东西被丢掉，而低年级同学正需要这些东西，却不知道该找谁。需求本身不新，但一直没被服务好——问题不在没人愿意卖，而在信息没有沉淀：一条出闲置的消息在群里刷过去就沉底了，想买的人翻不到，想卖的人也不知道谁在找。
场景收窄到「同一所学校内、步行可达」的近距离交易：学期初买教材、学期末出教材，换宿舍和毕业离校前处理生活用品与数码，同校区、同宿舍楼之间的当面交易。收窄场景是为了直接抵消二手交易里最大的两个成本——物流成本和信任成本。当交易双方在同一栋楼，交易就退化成「下楼拿一下」。
对照现有方案：闲鱼、转转覆盖全国，卖家要发货、买家要等，对「毕业季清宿舍」这种批量、低价、就近的场景太重；微信群消息流式滚动，没有检索也没有分类，一天就沉底；校园墙这类人工代发，时效差、条数少。本作品要把校园闲置信息结构化地沉淀下来，让找的人能搜到、让卖的人能被找到。
共 6 个页面、4 个云函数、6 个数据库集合，分五个功能模块：
1. 商品墙（首页）——双列卡片流，支持分类筛选、校区筛选、关键词搜索（输入即搜，带 400ms 防抖）、按时间与价格排序、上拉分页加载；首屏用骨架屏占位，避免空白到内容的跳变。
2. 发布闲置——多图上传（客户端压缩后传云存储）、标题、描述、分类、成色、售价、原价、校区、楼栋；联系方式可选微信号 / 手机号 / QQ 号；接受换物开关。发布成功后若同类目下有在招的求购，会提示并一键跳到求购墙按该类目筛选。
3. 商品详情——图片轮播与点击预览、价格与成色标签、卖家信息、收藏、「TA 的其他闲置」与「同类闲置」横向推荐、复制联系方式 / 拨打电话、举报入口。
4. 求购墙——与商品墙对称的模块：想买的东西现在没人卖，就把需求挂出去，让有货的人主动来找你。发布时填预算区间、分类、校区。这一块是本作品与普通「二手信息展示页」最本质的区别。
5. 我的——我发布的商品（上架 / 下架 / 删除）、我的求购、我的收藏，以及发布数、收藏数、收到留言数三个实时统计。
技术栈：微信小程序原生（WXML / WXSS / JS）+ 微信云开发（云函数 / 云数据库 / 云存储）。不引入构建链与第三方 UI 库，源码可被直接审阅。
我负责：需求定义与功能取舍（保留求购模块；用「复制卖家联系方式」替代站内私信，以规避社交类目）、架构决策（把鉴权边界放到云函数、客户端不再直连数据库）、云开发环境搭建与 4 个云函数部署、数据库集合与索引设计、全部代码的审阅与运行验证、真机测试与材料整理。编码环节使用 AI 辅助（Codex），每轮的提示词、产出与我的判断都记录在 docs/ai-usage-log.md。
架构上的关键做法：
1. 鉴权边界放在服务端——客户端参数可以伪造，所以每个云函数入口用 cloud.getWXContext() 取 openid，写操作前用 where({ _id, ownerId }).count() 确认归属。判断下推给数据库，既少一次数据传输，也避免「读到别人的数据之后才拒绝」。
2. 所有写操作收进云函数，客户端不直接读写数据库，云函数统一返回 { code, data, msg }。
3. 内容安全分层——发布商品、发布求购、发留言三处都过微信内容安全接口（文本 msgSecCheck v2、图片 imgSecCheck）。图片官方限制 1M 且单次调用有耗时，所以服务端并行校验前 3 张（含封面）、超 1M 的跳过并记日志，把发布耗时压在 1 秒量级，而不是让用户等着 9 张图逐张送检。
4. 数据最小化——联系方式只在详情接口返回，列表接口拿不到，抵御批量抓取。
5. 价格在数据库和网络传输中一律用分（整数），只在展示层转成元。
踩到的难点：
- 云函数默认超时 3 秒，首次调用叠加冷启动会报 FUNCTIONS_TIME_LIMIT_EXCEEDED，改成 20 秒并把图片校验并行化才解决。
- 给纯逻辑层（价格换算、联系方式校验）补了 66 项断言的单元测试，第一次跑就抓到一个真 bug：价格留空时 Number('') === 0，校验会通过，商品以 0 元发出去。
评论