基于Java的Android校园C2C二手交易平台开发实战与关键设计

做校园 C2C 这类项目，我一直觉得最难的不是写代码，而是想清楚“你到底要做一个什么东西”。如果你只是照着网上的电商项目把商品列表、购物车、下单流程抄一遍，那做出来的东西在校园场景里根本跑不动。

我在带课程设计、帮学弟学妹改毕设的过程中，见过太多“看起来功能很全，实际根本没人用”的校园二手交易 APP。问题几乎都出在同一个地方：把校园 C2C 当成普通电商做，忽略了“信任”和“本地化”这两个关键词。

所以这篇想跟你分享一下，基于 Java 实现 Android 校园 C2C 平台 APP 时，真正值得花时间的地方在哪。不是堆功能，而是把核心链路跑通、跑稳。这篇适合有 Java 基础、准备做 Android 项目实战、或者正在准备课设/毕设/作品集的同学，内容会从需求设计讲到关键代码实现，再讲我在真机调试和上架阶段踩过的坑，尽量做到你看完能直接动手。

1. 先想清楚校园 C2C 和普通电商的本质区别

很多人在动手写代码前，脑子里想的还是“用户—商品—订单”这套标准电商模型。但在校园场景里，这套模型有一个很大的问题：它假设买卖双方是完全陌生的，所以需要平台做担保、做售后、做物流跟踪。而校园 C2C 根本不是这个逻辑。

1.1 校园场景里的“信任”来自哪里

校园里买二手书、收一台学长退役的显示器、找一个同栋楼的代取快递，核心诉求是“当面交易、看到实物、便宜、方便”。信任不是靠平台信誉体系撑起来的，而是靠“同一个校园”这个身份天然产生的。所以我在设计时，把“学校认证”放在了整个 APP 的第一步，没有认证，商品只能看不能发布，也不能联系卖家，朋友推荐过来的用户第一步就是完善学生信息，这一步直接决定后续所有交易是否成立。

当时我的实现方案是：注册时要求填学校、学号/工号，再走邮箱验证，学校域名的邮箱能过就自动通过，否则进入人工审核列表。这个方案比上传学生证照片体验好，也比单纯的手机号验证码可信度高。实测下来，用户注册通过率接近 90%，而且审核后台几乎不用管，因为大多数学校邮箱域名就那么几个，维护成本很低。

1.2 交易模式到底是“在线支付”还是“线上约当面付”

这一点我纠结了很久。最初想接微信/支付宝支付，做成完全线上交易，但很快发现几个现实问题：一是大学生商户资质不好办，个人开发者的支付渠道审核极难通过；二是校园二手交易金额小、频次低，线上支付的体验优势不明显；三是最根本的——当面交易才是校园 C2C 的信任核心，强行做线上支付反而是画蛇添足。

最后我采用“平台不做资金托管，只做沟通桥梁”的模式：买家看到商品后，通过 APP 发起“我想要”，卖家收到意向通知后，双方用内置聊天确认见面时间地点，支持离线支付或当面扫码。为了保障安全性，我增加了一个“交易完成确认”按钮，买卖双方都点了之后，商品才从“交易中”变为“已完成”，这个动作是后续评价和纠纷的依据。

这个设计虽然看起来“功能少”了，但反而让整个项目在“上架审核—用户使用—售后纠纷”三个环节都轻了很多。做项目的时候，功能少但闭环完整，远比功能多但每个环节都半吊子要好。

1.3 功能边界怎么收敛

校园 C2C 平台如果什么都想做，最终一定什么都做不好。我当时列了一个“必须做/可以做/不做”的清单：

• 必须做：学校认证、商品发布与浏览、分类筛选、搜索、IM 沟通、订单状态流转、个人中心

• 可以做：收藏、举报、评价、公告、二手求购

• 不做：支付托管、物流跟踪、信用评分、社区内容、多商户入驻

把边界划清楚，写代码的时候心里才有谱。尤其是“不做”列表里的东西，如果你在初期就开始想支付回调、物流轨迹同步这类问题，整个项目的周期会瞬间膨胀。先把必须做的那一列做到 80 分，这个 APP 就已经具备完整的可用性了。

2. 技术选型和项目骨架：为什么我选了 MVP + Bmob

技术选型这件事，很多新手喜欢追新，看到 Kotlin 就抛开 Java，看到 Jetpack Compose 就觉得 XML 过时了。但你得清楚自己这个项目的定位：它要稳定、要可控、要方便答辩/演示、要能在别人电脑上快速跑起来。所以我选了 Java + XML + MVP，这套组合虽然“老”，但资料最多、问题最好查、试错成本最低。

2.1 Java 不是“老土”，是“稳”

我知道现在官方推荐 Kotlin，很多新项目也确实是 Kotlin 写的。但如果是为了学习、课设、毕设或者中小型作品集，Java 有几个 Kotlin 替代不了的优势：

• Java 上手门槛低，资料极其丰富，任何异常都能搜到现成解决方案

• MVP + Java 的组合在分层逻辑上非常清晰，适合代码量在 1-2 万行的项目

• 大部分公司面试时问的 Android 基础还是 Java 语境，做完这个项目后面试的时候你顺手就能答上一波

如果你已经在项目中期了，想从 Java 切 Kotlin，我建议别切。趁早做完比用什么语言重要得多。语言只是工具，能让你的项目在两个月内顺利收尾的，才是适合你的工具。

2.2 MVP 架构怎么在这类项目里落地

MVP 的核心思维是“界面只管显示和交互，业务逻辑和数据显示都分离出去”。以“商品列表页”为例，我当时的分层是这样的：

• View 层：MainActivity + RecyclerView 的 Adapter，只管展示列表、展示加载动画、展示错误提示

• Presenter 层：调用 Model 层拿数据，拿到后回调 View 层的刷新方法，同时处理“下拉刷新”“上拉加载更多”的请求逻辑

• Model 层：Bmob 云的增删改查、本地缓存的读写

也许有人会说 MVP 就是多写一堆接口，很繁琐。但实际在 C2C 项目里，你会有很多页面共用同一套业务逻辑（比如商品查询，首页在查、搜索页也在查、个人中心的“我发布的”也在查），MVP 把数据获取逻辑收敛到 Presenter 和 Model 之后，加一个新的 View 只需要几十行代码，不用重新写一遍业务逻辑。

我个人在写这个项目时，会刻意保持一个习惯：**Activity 里只放界面相关代码，凡是需要 Toast、弹窗或者刷新列表的地方，都通过接口回调到 Presenter 来实现。**这在一开始会让你的代码量多一点，但到后期改需求时，爽感是实打实的。

2.3 为什么用 Bmob 而不是自己搭后端

很多人一听到“平台 APP”，第一反应是“那我是不是得学 Spring Boot 写后端？”如果你的目标是“做出一款能完整运行的 Android APP”，那后端自己搭完全可以；但如果你的目标是快速跑通整个 C2C 业务闭环，我强烈建议用 Bmob 这种 BaaS 平台。

我当时的理由很实在：

• Bmob 提供现成的用户系统、数据表、文件存储、IM 能力，前端 SDK 直接调用，省去服务端开发和部署成本

• 有免费额度，课程设计和毕设阶段完全够用；即便后期要推广，付费档位的价格也比自建服务器便宜

• 数据管理后台是网页操作的，答辩演示时可以直接修改数据库状态给你演示“交易中”“已完成”的效果

唯一要注意的是，Bmob 的免费额度有每日请求次数限制，如果你在开发调试阶段频繁刷新列表、反复上传图片，很容易触发限额。我的经验是：在 Application 的 onCreate 里初始化 SDK 之后，再写一个全局的请求频率管理类，把无意义的重复请求过滤掉，能帮你省掉很多次“怎么突然请求失败”的困扰。

2.4 工程目录怎么组织，才能让后期维护不崩溃

这个项目涉及的页面大概是：启动页、登录注册、首页商品流、分类页、搜索页、商品详情、发布页、聊天列表、聊天窗口、个人中心、我的发布、我的收藏、设置页。如果全塞在一个包下面，后期找文件找到崩溃。

我用的包结构如下，可以参考：

java复制com.campus.c2c
├── base                    // BaseActivity、BaseFragment、MVP 接口定义
├── model                   // 数据模型（UserItem、GoodsItem、OrderItem）
├── net                     // Bmob 相关的网络请求封装、常量配置
├── ui
│   ├── login               // 登录注册
│   ├── home                // 首页、分类、搜索
│   ├── detail              // 商品详情
│   ├── publish             // 发布商品
│   ├── chat                // 消息列表、聊天窗口
│   └── mine                // 个人中心、我的发布、设置
├── adapter                 // 全部的 RecyclerView Adapter
├── utils                   // 图片压缩、时间格式化、版本检查等工具类
└── widget                 // 自定义 View，比如九宫格图片选择器

如果你做的是个人项目，前期不觉得这个结构有多重要，因为所有文件你都认识。但到后期，当你同时在改首页的数据加载和聊天列表的未读计数时，一个好的结构能让你少死很多脑细胞。

3. 核心数据结构设计与订单状态机：项目的“地基”在这里

做这类 APP，最重要的不是界面做得多炫，而是后端数据结构设计得够不够稳。因为一旦项目进入开发中期，数据结构想改就得连带着前端、云端、测试数据一起改，代价非常大。所以一开始就要把核心表和它们之间的关系想明白。

3.1 核心表设计：用户、商品、订单、收藏

基于 Bmob 云端，我建了四张核心表。你可以不用建太多表，但这四张是必须有的：

用户表（扩展 Bmob 自带的 User 表）

商品表（GoodsItem）

订单表（OrderItem）

收藏表（FavoriteItem）

3.2 商品状态流和订单状态流

商品状态和订单状态是两个容易混淆的东西。商品的 status 是为了给整个列表页展示用的，订单的 status 才是某个具体交易关系的状态。建议把两者分开处理，别想着合到一张表里。

订单状态流转我做了很明确的规则：

text复制0 待确认（买家发起意向） -> 1 交易中（卖家确认/买家确认） -> 2 已完成（双方确认）
                        \-> 3 已取消（任一方取消）

很多校园 C2C 项目把“买家发起意向”直接当成“订单已生成”，其实不对。这里有一个容易被忽略的细节：如果买家只是想问问“学长你这个显示器还在不在”，他发起的只是一个意向，这时候卖家手里可能有好几个意向。只有在卖家点击“接受”之后，订单才正式进入“交易中”，同时商品状态自动变成“交易中”，其他买家就看不到了。

这个“先意向，后确认”的流程，能有效解决一个场景：一个热门商品同时被 5 个人收藏，但只能卖一次。如果你不做“意向”和“交易中”的区分，就会出现多人同时付款成功、卖家不知道怎么处理、买家体验崩盘的问题。

3.3 跨表查询怎么处理才不乱

Bmob 的查询核心是 BmobQuery，我做得最多的一个操作是“查询首页商品列表，同时要把卖家的昵称和头像带出来”。如果不会用 Pointer 关联，你可能要先查商品，拿到 sellerId 再一个个查用户，这样前端性能会很差，代码也丑。用 Pointer 关联后，Bmob 提供 include 方法，一次查询就能把关联数据一起返回：

java复制BmobQuery<GoodsItem> query = new BmobQuery<>();
query.setLimit(10);
query.order("-createdAt");
query.include("seller"); // 重点：把 seller Pointer 指向的 User 完整查出来
query.findObjects(new FindListener<GoodsItem>() {
    @Override
    public void done(List<GoodsItem> list, BmobException e) {
        if (e == null) {
            // 直接用 list 里的 getSeller().getNickname() 等
        }
    }
});

include 一次只支持一层关联，如果你的订单表想同时拿到商品、卖家和买家，需要用两个 include 或者拆两次查询。我的建议是：列表页和详情页以“商品 + 卖家”为主，订单页再单独查一次订单关联，能省时省心不少。

3.4 关于本地缓存的一个小设计

移动端网络不稳定的情况太常见了。我在 Model 层加了一个轻量级的缓存方案：第一次请求成功时，把数据用 Gson 转成 JSON 字符串，存到 SharedPreferences 或小型 SQLite 表里；下次进入首页时先读缓存展示，同时后台请求新数据，再刷新界面。

这样做的直接好处是用户点开 APP 时不会盯着白屏发呆，对于校园场景里经常在教室、食堂、图书馆到处走的用户来说，这个体验提升是实打实的。注意缓存是有时效的，我设置的是 10 分钟过期，超过时间就必须走网络请求，避免数据太旧影响买卖决策。

4. 核心功能模块实现：商品发布、双列表信息流、IM 沟通链路的代码细节

这一部分挑三个最有代表性的模块讲一下实现细节。这三个模块覆盖了校园 C2C 的主干线：发商品、看商品、聊商品。

4.1 商品发布页：图片选择和压缩是个容易被忽视的魔鬼

商品发布页的核心是表单数据收集与图片上传。界面上的控件无非是 EditText、价格输入框、分类 Spinner、九宫格图片选择器。真正麻烦的是图片处理和上传。

相册选图在 Android 6.0+ 要用运行时权限，在 Android 10+ 要用分区存储，在 Android 13+ 有新的 photo picker API。如果在真机调试时忽略这些，就等着看 FileUriExposedException 或者图片不显示的问题。我在发布页统一用系统 Photo Picker 解决：

java复制// 适配 Android 13 及以上的系统图片选择器
Intent intent = new Intent(MediaStore.ACTION_PICK_IMAGES);
intent.putExtra(MediaStore.EXTRA_PICK_IMAGES_MAX, 6);
startActivityForResult(intent, REQUEST_IMAGE_PICK);

拿到 Uri 之后，不能直接把原图传到云端，不然一两张图就可能让上传请求超时。我写了一个基于 BitmapFactory 的图片压缩工具类，先通过 inSampleSize 降低采样率，再用 JPEG 质量压缩到 60%，确保每张图压到 200KB 以内再走上传。实测一张 12MB 的照片，压缩后大概 150KB，清晰度在手机上看完全够用。

压缩代码核心思路是这样的：

java复制BitmapFactory.Options opts = new BitmapFactory.Options();
opts.inJustDecodeBounds = true;
BitmapFactory.decodeStream(input, null, opts);
int sample = 1;
while (opts.outWidth / sample > 1080 || opts.outHeight / sample > 1920) {
    sample *= 2;
}
opts.inJustDecodeBounds = false;
opts.inSampleSize = sample;
Bitmap bitmap = BitmapFactory.decodeStream(input, null, opts);
// 输出 JPEG 质量压缩后写入临时文件，再走 Bmob 文件上传

图片上传到 Bmob 是异步的，一个商品最多 6 张图，逐张上传用户体验太差。我的做法是：先把 6 张图并行上传（用一个线程池），全部上传成功后回传图片 URL 列表，再调用保存商品接口。上传过程中界面显示进度条和“正在上传图片（3/6）”文案，用户能直观看到进度。

4.2 首页商品信息流：下拉刷新、上拉加载、列表复用

首页是项目的门面，也是大多数用户第一次接触 APP 的地方。我的首页是三级结构：顶部搜索栏、中部分类 Tab、底部商品列表 RecyclerView。

商品列表用的是 LinearLayoutManager，数据来源是 BmobQuery 的 limit + skip 分页。每次请求 10 条，翻页时 skip 加 10。这个方案在数据量几千条的时候完全没问题。

这里有一个初学者容易踩的坑：RecyclerView 的 item 复用时，图片加载库要用 Glide，而且要在 Adapter 的 onBindViewHolder 里每次都给 ImageView 设置新的 url。如果复用时不重置图片，会出现“滚到后面看见的是前面商品的图”这种错位问题。我之前写过一版没有处理这个问题的代码，评测用户直接截了图给我，“学长，为什么这个显示器出现在手机分类里？”

Glide 加载有一个细节值得注意：

java复制Glide.with(context)
    .load(url)
    .placeholder(R.drawable.ic_placeholder)
    .error(R.drawable.ic_placeholder)
    .into(holder.imageView);

placeholder 和 error 一定要设，不然网络差时图片区域会显示一片空白或黑块，看起来像 bug。这种做法可以让你在不改代码的情况下，在网络图加载失败时给用户一个还算体面的兜底页。

4.3 IM 模块：用 Bmob 的即时通讯能力实现买卖沟通

消息是校园 C2C 的灵魂。看中商品之后怎么沟通？留电话太暴露隐私，不如内置 IM。Bmob 的 IM SDK 支持单聊、会话列表和离线消息推送。我之前用过第三方云 IM，也用自己的 WebSocket 写过聊天，对比下来 Bmob 的 IM 在这类中小型项目里是最省事的。

聊天的核心逻辑其实就三步：创建会话、发送消息、接收消息。

创建会话时，如果当前用户和对方还没有会话，就创建一个新的 BmobIMConversation；如果已有，直接打开。为了判断“是否已存在”，我用一个约定俗成的规则：双方用户 id 按字典序拼接成 contentKey，用 contentKey 作为会话的查询条件。

发送消息的逻辑是这样的：

java复制BmobIMConversation conversation = BmobIM.getInstance()
        .startPrivateConversation(user, true);
BmobIMTextMessage msg = BmobIMTextMessage.createMessage("你好，请问这本书还在吗？");
conversation.sendMessage(msg, new MessageSendListener() {
    @Override
    public void done(BmobIMMessage message, BmobException e) {
        if (e == null) {
            // 发送成功，更新列表
        } else {
            // 发送失败，提示重试
        }
    }
});

这里有个特别需要注意的坑：BmobIM 初始化要在 Application 里做，在 MainActivity 里初始化会出现连接成功但收到消息的监听不生效的情况，也就是“时好时坏”的玄学问题。我当时花了整整一个晚上排查这个问题，最后发现就是生命周期的问题——初始化太晚了。

聊天列表页还需要显示会话的未读计数。Bmob 的 IM SDK 提供了 IMConversation 的 getUnReadCount() 方法，我直接在会话列表的 Adapter 里判断，大于 0 就显示红点数字，用户点进会话后调用 conversation.updateLocalCache() 更新已读状态，返回列表时数字就清零了。这个逻辑虽然简单，但特别影响用户的“安全感”，建议别省略。

4.4 订单确认与“双方确认完成”的交互细节

订单在“交易中”状态时，我的 UI 上会显示两个按钮：一个是“我已完成交易”，一个是“取消交易”。“我已完成交易”点击后，订单状态不会直接变成已完成，而是记录该方已确认，同时给对方发送一条系统消息提醒确认。

只有当买卖双方都点了确认后，订单状态才从“交易中”变为“已完成”，商品状态也随之变为“已完成”，同时自动给卖家加一条可信记录。这样做的原因很简单：如果单方点一下就完成，卖家和买家的体验都会很糟——卖家可能还没收到钱就被系统提示交易完成，买家可能东西没拿到就被要求评价。

这块用 Bmob 的云端逻辑来实现时，我选用的是云函数，也就是 Bmob 的云方法。把“确认完成”的操作放到云端，能避免前端绕过校验直接修改状态。云方法在 Bmob 后台用 JavaScript 写，或者直接用 Java 端调用 BmobCloud 方法，这个随意，但思路是一样的——核心业务状态不能只依赖客户端代码保护。

5. 优化完核心链路之后，要处理的两大隐藏工程：数据安全与打包上架

很多项目死在“功能写完了，却发布不出去”这一步。所以这一章讲两个你代码写完之后必须面对的硬骨头。

5.1 内容安全与违规信息过滤

校园 C2C 类 APP 在上架时，应用市场会特别关注“用户发布内容”这一块。如果你的商品描述里有人发布了违规信息而你没有任何处理机制，审核直接打回。

我的方案是三层过滤：

• 发布前过滤：客户端在提交商品前，用本地敏感词表做一次基础过滤，命中就提示修改，不加说明具体哪个词，避免被恶意绕过

• 云端二次过滤：Bmob 云函数在保存商品时再执行一次过滤，防止有人用修改过的客户端跳过前端校验

• 举报机制：每个商品详情页和聊天窗口都有举报按钮，点击后生成一条举报记录到后台，管理员在 Bmob 后台看到后可以强制下架商品或封禁账号

很多教程不会提到这一个点，但如果你想上架到应用商店，这个功能几乎是“不做不行”的。就算暂时不上架，答辩时老师问“你如何处理违规内容”，你也能抛出一套完整的方案，这就是加分项。

5.2 应用签名、加固与多渠道打包

Android 上架前，你需要有一个正式签名文件，这个文件决定了你的 APP 身份，后续升级必须用同一个签名。我建议在项目一开始就生成 keystore，并写进 app/build.gradle 的 signingConfigs，后面调试和上架都保持一致，不要到最后一刻才想起签名的事。

签名文件生成命令：

bash复制keytool -genkey -alias campusc2c -keyalg RSA -validity 36500 -keystore campusc2c.jks

上架前还建议做一次加固。现在主流市场都有免费加固工具，可以防破解、防二次打包。课程设计项目可能觉得没必要，但如果你要投简历或者作品集，最好做一下，这体现的是工程素养。

多渠道打包方面，只面向国内市场的写一个通用版即可，不需要真的配太多渠道，但 build.gradle 里用 productFlavors 预留渠道位置是个好习惯，以后想上不同市场，打不同包名/不同 adb 配置时就直接用。

6. 真机实测阶段最容易翻车的几个场景

代码写完了，你以为可以收工了？还早。真机测试阶段会出现一堆模拟器上发现不了的问题。我把最影响体验的几个列出来，给还没踩过坑的同学打个预防针。

6.1 图片加载不出来或加载错乱的排查链路

如果在测试中发现图片时好时坏，不要急着怀疑代码逻辑，按这个顺序排查：

1. 检查图片 URL 是否能直接访问：把 Bmob 返回的 URL 复制到浏览器或 Postman 里请求一下，如果不能直接访问，可能是文件名有多余字符或域名不对

2. 检查网络权限：Android 9.0（API 28）开始默认禁止明文 HTTP 流量，如果你的图片 URL 是 http:// 开头，必须在 AndroidManifest 里加上 android:usesCleartextTraffic="true"，或者配置网络安全配置文件

3. 检查 Glide 缓存：开发时反复改图片、反复上传同一个路径，可能会出现旧图缓存。清缓存后如果正常，就把 Glide 的缓存 key 加上版本号解决

4. 检查是否 onBindViewHolder 里没绑定对的 item：这是最典型的 Adapter 抽风问题，解决方案就是给 ImageView 每次都设置新 URL，必要时调用 clear() 重置

6.2 聊天消息丢、延迟、服务端收不到的问题排查

IM 消息如果丢，先别怀疑 SDK，顺着生命周期排查：

• 确认 BmobIM 初始化是否在 Application 的 onCreate 里，且是全局唯一

• 确认聊天页面 onResume 里注册消息监听，onPause 里注销。不要在 onCreate 里注册一个就再也不动，那样页面销毁重建后会有多个监听，消息回调执行多次，表现为消息重复

• 确认前后台切换时，消息推送有没有走 Bmob 的推送服务。Bmob IM 的标准做法是集成厂商推送或轮询，如果你没有集成推送，APP 在后台时收不到消息是正常的，用户切回前台时会收到离线消息，这个体验要靠聊天列表的“刷新”按钮兜底

6.3 多机型适配的坑：状态栏、刘海屏、全面屏

这个项目在低端机和高分屏上的表现会差很多。我的做法是：用 AutoSize 屏幕适配库做基础适配，同时针对状态栏与底部导航栏做沉浸式处理。具体的坑有两个：

• 小米和华为的“全面屏手势”会让底部导航栏和你的发布按钮重叠，需要在布局里预留导航栏高度

• 刘海屏顶部不要放关键操作按钮，因为不同厂商的挖孔大小不一样，一旦遮挡，操作体验直接归零

我之前在一台 Redmi 上测试，发布按钮的文字“发布”两个字被小米手势条遮住了下半截，看起来像是胶囊按钮变形了，非常掉价。后来统一用 View 的 fitsSystemWindows 属性解决大部分问题。

6.4 弱网环境的兜底策略

校园网好是好，但宿舍、阶梯教室、图书馆地下层都有弱网死角。我在这类场景下遇到的表现是：商品列表转圈圈不出数据、图片加载一半卡住、聊天消息发出去但没回调成功。

我的兜底策略是：

• 列表页请求超时时间设为 15 秒，超时后展示重试按钮 + “当前网络不给力，请检查网络”提示

• 发布商品时，先把商品信息和图片本地暂存，用户点击发布后先进“发布中”，失败时提示“保存在草稿箱”，之后从个人中心可以恢复继续发布

• Glide 的图片加载设置 skipMemoryCache(false)，内存缓存开着，弱网时已看过的图片能秒开

这些优化投入不大，但对用户体验的提升非常明显。你可以简单想想，如果一个学生在地下自习室看到喜欢的商品，结果图片加载不出来，他大概率直接关掉 APP，不会再打开第二次。

7. 扩展思路：这个项目还能怎么“长”出额外价值

核心功能做完之后，如果你还有余力，我建议在以下三个方向做延展。它们不会改变项目的主干逻辑，但能让作品在展示时多几个亮点。

7.1 基于校园位置的“附近好物”推荐

校园 C2C 天然带位置属性。你可以用定位 SDK 获取用户当前经纬度，发布商品时记录宿舍楼或教学楼的定位，然后把“首页推荐”改成“附近 500 米/1 公里内的好物”。

这个功能技术实现上并不复杂：给商品表加 latitude/longitude 字段，发布时从定位 SDK 拿，查询时用 BmobQuery 的 addWhereWithinKilometers 方法过滤。但从产品角度看，这个功能非常符合校园二手交易“近就是方便”的心理，用户更愿意和一个 300 米内、能五分钟下楼交易的人成交，而不是跨校区坐二十分钟校车。

7.2 交易完成后的轻量评价体系

前面讲到订单双方确认完成，此时可以顺势加一个互相评价的入口。评价不需要太复杂，三个维度：交易顺利程度、卖家描述相符程度、推荐指数，用星级打分加一条 30 字内的评论即可。

由于你已经把订单状态机做得很干净，评价表可以挂在订单 ID 下，每个订单最多产生两条评价（买家评卖家一条，卖家评买家一条），不会出现重复评价或刷评价的问题。这个功能一旦加上，你的项目就从“交易工具”变成了“社区工具”，产品厚度完全不一样。

7.3 二手“求购墙”或悬赏功能

校园里很多需求不是“我有东西要卖”，而是“我想找一样东西”。你可以增加一个求购发布功能，用户发布“求购一台 500 元以内的电动车”，其他用户看到后可以点击“我有”，直接发起聊天。

这个功能在代码层面跟发布商品、搜索浏览是高度复用的，只是把商品表改成一个有“类型”字段的表（卖/求），查询时多一个条件。但它拓展了平台的场景边界，尤其是开学季和毕业季，求购墙的活跃度可能比商品发布还高。

8. 写在项目之后：我的一些个人体会

这个项目做到最后，我最大的感悟是：**Android 校园 C2C APP 的成败，七个字——信任、闭环、不贪多。**我见过不少同学把一个二手交易平台做成大杂烩，既有商城，又有社区，还要搞积分系统，结果每一条链路都断在了半路。而我当时把核心精力聚焦在“认证、商品、IM、订单”这四个环上，每一个闭环都打磨到看起来“笨拙但可靠”，最终项目的完整度和答辩效果反而远好于那些功能清单更长的人。

最后再分享一个小技巧：如果你是为了面试展示这个项目，建议把项目 Gitee/GitHub 仓库整理好，README 里放上项目截图、真机运行演示录屏和部署说明。面试官问项目时，不要只讲你写了什么功能，直接打开真机演示或录屏跑一遍“注册→发布→搜索→聊天→确认完成”这条完整链路，比你说十页 PPT 都管用。

做项目，把它做完、跑通，比把它做好看重要得多。校园 C2C 这个选题非常适合作为自己的第一个独立完成的全栈 Android 项目，哪怕只做到订单确认完成这一步，你收获的也不只是一份作品，而是对移动端业务闭环的完整认知。希望这篇分享能让你少走我已经走过的弯路。