Spring Boot+Android校园闲置物品交易App毕设完整实战指南

每年一到毕业设计季，校园闲置物品交易App这个题目就会大量出现在选题清单里，Spring Boot加Android这个组合更是经典得不能再经典。但说实话，我带过的学生里，真正能把这类项目做得像样、答辩时不心虚的，比例不算高。问题通常不在"不会写代码"，而在"不知道怎么把一个烂大街的选题做出完整度和区分度"。这篇博文我想围绕"基于Spring Boot的Android校园闲置物品交易App"这个选题，把从方案选型、数据库设计、核心功能实现到答辩准备的完整链路拆开讲一遍，重点放在那些文档里不会明说、但实际操作里一定会遇到的坎上。

1. 别急着写代码：这类毕设项目八成失败在方案选型上

1.1 为什么是"Spring Boot + Android原生"这个组合

很多同学选这个题目的第一反应是"Spring Boot做后端、Android做客户端"，但真要问一句"为什么这么选"，能说清楚的人不多。这个问题恰恰是答辩时最容易被打中的。

Spring Boot在毕设层级的技术选型里有不可替代的优势：内置Tomcat、自动配置、生态成熟，一个main方法就能跑起来，配合MyBatis Plus这种增强框架，CRUD的代码量能压到非常低。对毕设来说，它的学习成本曲线比SSH、SSM时代平缓太多，而且市面上参考资料极其丰富，遇到问题几乎都能搜到解决方案。Android原生则保证了客户端对硬件能力（相机、相册、定位、通知栏）的调用路径最短，不用像跨平台方案那样考虑桥接层的限制。

但这不意味着这个组合是唯一的解。这两年用Flutter或uni-app做客户端的毕设也不少，后端换成Node.js或Django的也有。我的建议很简单：如果给你3到4个月，目标是稳稳落地、答辩有理有据，Spring Boot加Android原生是最稳妥的路线。这不是因为它最先进，而是因为它的每一层都足够"清晰"——Controller层、Service层、Mapper层清清楚楚，Android端的Activity、Adapter、ViewHolder也足够经典，导师问任何一个细节你都能答出它的职责边界。这种"可解释性"对毕设来说，比技术时髦度重要得多。

1.2 前后端分离的职责边界：接口约定先于功能开发

既然选了前后端分离架构，就要先想清楚一件事：后端的Spring Boot项目不关心你Android端用什么设计模式，Android端也不关心后端用的MySQL还是PostgreSQL。两者之间唯一的桥梁就是RESTful API的约定。

我见过太多同学先埋头写后端，把用户表、商品表、订单表全部设计好了，接口也写完了，才开始建Android工程。结果联调的时候发现：登录接口返回的字段名和客户端需要的不一致、分页参数叫pageNum而客户端写成pageNo、时间字段传的是时间戳但客户端想要字符串……整个人都麻了。

正确做法是开工第一天就把接口文档定出来。不需要用Swagger或者Apifox这类工具搞得很复杂，一张共享表格就够了：接口路径、请求方式、请求参数、返回结构、字段含义、示例值，全列清楚。这个过程也是对你需求分析能力的一次实打实训练——等你写论文的时候，这套接口文档直接就是系统设计章节的核心素材。

前后端分离还有一层容易忽略的含义：职责边界。登录态校验放在哪里、数据校验放在哪里、金额计算放在哪里，这些必须在动手之前达成一致。最常见的原则是后端不信任前端传过来的任何数据，所有涉及业务逻辑的校验必须在Service层再做一遍。Android端只是展示和采集数据的终端，真正的交易状态流转和数据一致性必须由后端保证。

1.3 三类技术方案的对比，以及最终选择的理由

考虑到会有同学在"原生Android、混合开发、跨平台框架"之间纠结，我把三类的实际体验列出来：

如果目标是"做出一个能跑通全流程、代码自己完全能讲清楚、还能应付追问"的毕设，我坚定站原生。后面所有内容也都会围绕原生Android加Spring Boot展开。

2. 后端设计：表结构决定业务的"长宽高"

2.1 九张核心表的建模思路与字段细节

"校园闲置物品交易"听起来业务不算复杂，但真正建模的时候要考虑的点非常多。第一版我建议做这几张表，已经覆盖了核心业务闭环：用户表、商品表、商品图片表、收藏表、留言表、订单表、消息通知表、商品分类表、轮播图表。

用户表的关键不是存用户名密码那么简单，而是要考虑微信登录、手机号登录、学号认证这类校园身份维度。毕设项目里我建议用手机号加密码的方式登录，再加一个"学号"字段做校园认证——不强制认证，但认证后发布的商品会打上"已认证"标签。别小看这个设计，它直接回应了"校园闲置交易"里最核心的信任问题，也是答辩时可以展开讲的一个点。用户表的核心字段：id、手机号、密码（BCrypt加密存储）、昵称、头像URL、学号、认证状态、学号认证时间、信用分、注册时间、最后登录时间。

商品表是核心中的核心。除了基本的商品名称、描述、价格、成色、原价、分类ID、发布者ID，一定要有这几项：商品状态（在售/已预订/已售出/下架）、浏览数、所在校区或楼栋位置、是否可小刀（议价）。这些字段决定了后续搜索和筛选功能能做得多细。价格字段用整数存"分"而不是浮点存"元"，这点自己心里要有数，省得后面算金额的时候出现0.1加0.2不等于0.3这种经典问题。

商品图片单独建表而不是在商品表里存一个逗号分隔的URL字段，是为了将来扩展时不用动主表结构。每张图片记录所属商品ID、图片URL、排序号，这条设计在写论文的时候也可以作为"数据库设计遵循第一范式"的例子。分类表用两级结构：大类下面挂小类，比如"数码电子"下面有"手机"、"平板"、"笔记本"，这样筛选页面做级联的时候非常方便，不用在代码里写死分类层级。

订单表是第二核心的表。一个完整的二手交易订单要记录：商品ID、买家ID、卖家ID、订单金额、状态（待付款/待发货/已发货/已完成/已取消/退款中）、创建时间、支付时间、完成时间、交易方式（校内自提/线下当面交易）、买家和卖家的备注、是否评价。订单表的状态流转是整个项目里最容易出bug的地方，后面单独说。

消息通知表容易被忽略但实际很重要。校园闲置交易App里用户和用户之间必然有沟通需求，买家要问"这个东西还在吗""能不能便宜点""什么时候方便见面"。这个表记录通知类型（系统通知/交易提醒/留言回复）、接收者ID、关联内容、已读状态、创建时间，是体现系统完整度的一个关键细节。

2.2 交易状态机：从"发布"到"成交"的状态流转设计

交易状态机是这个项目里最有技术含量的业务点之一。很多同学的实现方式是switch-case硬写，写完就完事了。但如果答辩老师追一句"用户拍下商品后卖家又取消了怎么办""商品在已预订状态时别的用户还能不能收藏"，很多人的代码就露馅了。

我建议把状态流转画成一张清晰的流转表，写进设计文档，同时代码里用常量类或枚举来管理：

这里最容易忽略的是并发问题：两个买家同时对同一件商品下单，都到了"已预订"状态，怎么办？后端必须在订单创建时用乐观锁或者UPDATE goods SET status = '已预订' WHERE id = ? AND status = '在售'这种CAS式更新来保证只有一个人能成功。这个点很小，但属于"有经验"和"没经验"的分水岭，答出来非常加分。

2.3 文件上传的两种姿势：本地存储 vs 对象存储

商品图片上传是每一个做这类项目的人都要面对的问题。毕设场景有两个选择：存本地磁盘和接入云对象存储。

本地存储的思路是：Spring Boot项目里配置一个虚拟路径映射，把/upload/**映射到本机某个目录，图片上传后把相对路径存到数据库，访问时通过虚拟路径拼接完整的URL。好处是不依赖第三方服务、离线也能跑、不用备案注册；坏处是服务器重启后如果配置不当图片会丢，而且答辩现场如果用的局域网演示，手机通过IP访问图片需要把端口和路径暴露出去。

云对象存储的思路是：接OSS或者腾讯云COS，上传成功后拿回一个公网URL。好处是稳定、访问快、"生产级"；坏处是注册、实名、配置Bucket这些前置工作比较消耗时间，而且如果答辩现场网络不稳定反而翻车。

我的建议是：毕设阶段用本地存储就够了，但代码架构上把存储逻辑抽象成一个FileStorage接口。这样论文里你可以写"基于策略模式的存储方案设计"，答辩时如果老师问"为什么不用OSS"，你可以回答"预留了接口扩展，生产环境可直接切换到云存储，只需要替换一个实现类"。这种回答既诚实又体现架构意识。

实现上，后端上传接口记得做三件事：限制单个文件大小（比如单张不超过5MB）、校验文件类型（只接受jpg/png/webp）、给文件重命名。文件名千万不要用用户上传的原文件名——包含中文和特殊字符的文件名会带来一堆乱码和路径问题，用UUID或时间戳加重命名更稳妥。

3. Android端核心模块：网络、列表、图片与登录态

3.1 网络层封装：Retrofit + OkHttp 的拦截器与统一返回

Android端和后端通信，主流方案就是Retrofit加OkHttp，这个组合在毕设里足够经典也足够好用。Retrofit负责把接口定义转换成可执行的HTTP请求，OkHttp在底层处理连接、超时、缓存这些事。

我建议的封装方式是三层结构。第一层定义统一返回体，后端所有接口都返回{code: 200, message: "success", data: {...}}这样的结构，客户端用泛型类BaseResponse<T>去解析。第二层定义ApiService接口，每个方法用注解声明对应的HTTP请求和参数。第三层是Repository或者Model层，把ApiService的能力再包一层，给ViewModel或Presenter调用。

OkHttp的拦截器有两个必须加。第一个是日志拦截器，开发时能看到每个请求的完整信息，联调阶段几乎全靠它定位问题。等答辩前记得把日志级别调低或者关掉，不然演示时Logcat里全是数据。第二个是Token拦截器，从本地存储取出登录后保存的Token，加到每个请求的Header里，统一处理"需要登录才能访问"的接口鉴权。

还有一个细节：超时时间要设置合理。默认的10秒连接超时在某些校园网环境下可能不够，建议connectTimeout设15秒，readTimeout设20秒。读取超时太短的话，上传图片的时候很容易抛SocketTimeoutException，这种问题排查起来非常迷。

3.2 商品列表的加载与分页、刷新的具体实现

商品列表是App的门面，实现得好不好直接决定演示效果。核心是两个交互：下拉刷新和上拉加载更多。后端接口设计为分页参数pageNum和pageSize，返回total和records。

Android端用RecyclerView加SwipeRefreshLayout是最经典的组合。有几个从实战里踩出来的建议：

• 下拉刷新时重新请求第一页数据，成功后清空列表再填充；
• 上拉加载更多时页码加1，请求成功后将新数据追加到列表尾部；
• 用一个isLoading标志位防止重复触发加载请求；
• 当返回的数据条数小于pageSize时，标记"没有更多了"，停止继续请求。

列表完成之前先把Adapter的ViewHolder写好。商品卡片建议展示：主图、标题、价格、成色标签、发布者头像昵称、发布时间。主图用Glide加载，同时设置占位图和错误图，否则弱网环境下刷出来的列表全是灰块，对演示体验的影响是致命的。

3.3 图片选择与上传压缩：实测坑点

Android图片上传这块，坑是真的多，每年都有同学在答辩现场翻车。我总结几个最容易踩的：

第一个坑是相册选择返回的Uri权限问题。如果在AndroidManifest里没配置FileProvider，或者代码里没有对Uri做持久化授权，App重启之后再访问这个Uri会直接崩掉。解决方案是使用系统Photo Picker（ActivityResultContracts.PickVisualMedia）来选图，这个API从Android 13回退兼容到Android 4.4，既免去了权限申请，也不用处理FileProvider的复杂配置，是目前最省心的方案。

第二个坑是Bitmap内存溢出。相册里的图片动辄就几MB到十几MB，直接加载原图到内存，低端手机上必然OOM。一定要先通过BitmapFactory.Options的inJustDecodeBounds读宽高，按需计算采样率压缩后再加载。建议把图片最长边压缩到1080或1280像素，质量压缩到80%，单张体积控制在300KB以内，这样上传快、显示也不糊。

第三个坑是上传进度的用户体验。如果图片是一次性放进List然后循环上传，最好给用户一个进度提示，比如"正在上传第2/5张"。实现上可以用一个队列加倒计数的方式更新UI，不用上什么EventBus，直接在回调里更新TextView就行。

3.4 登录态保持：Token 的存储与失效处理

登录功能人人都会写，但登录态保持这个细节能看出水平。后端登录成功后返回一个Token（这里用JWT就够了，不用折腾OAuth2那些），客户端需要把这个Token保存下来，下次打开App就不用重新登录。

存储方式首选SharedPreferences或DataStore，不要用第三方数据库存一个单字段的东西，那是杀鸡用牛刀。密钥建议存放在应用的BuildConfig字段里。需要知道的一个细节是：SharedPreferences是明文存储，不适合放密码这类敏感信息，但放Token是业界可接受的做法，只要注意不要把这个文件备份到云端即可，可以在manifest里给这个预置文件设置allowBackup="false"。

Token失效处理也很关键。后端的过滤器或拦截器在Token过期或非法时，返回401状态码。客户端网络层拦截到401时，应该清理本地登录状态并跳转登录页，并给出"登录已过期，请重新登录"的提示。如果不做这一层，用户用着用着，所有需要登录的接口全部报错，排查起来一头雾水。实现上在OkHttp拦截器里判断response.code() == 401，通过回调通知UI层做跳转操作就行。

4. 从"能跑"到"能答辩"：联调、演示与盲区

4.1 真机联调中必须解决的三件事

写代码阶段用模拟器跑得飞起，但真机联调才是毕设演示的重头戏。有三件事必须提前解决。

第一件：手机和电脑必须处于同一局域网。Spring Boot服务默认监听的是localhost，Android模拟器可以用10.0.2.2访问宿主机的localhost，但真机不行。真机要访问后端，URL里的IP必须是电脑在局域网里的实际IP，例如http://192.168.1.100:8080。同时要保证Spring Boot的启动配置里没有绑定死localhost，也没有关闭跨域——虽然Android原生App不像浏览器那样受CORS限制，但有的同学后端口里如果加了跨域配置且写得不严谨，也可能造成奇怪的问题。

第二件：Android 9及以上的明文HTTP流量默认被禁止。如果你的后端接口是http://而不是https://，直接在真机上请求会报CLEARTEXT communication to xxx not permitted by network security policy。解决办法是在AndroidManifest.xml的application标签里加android:usesCleartextTraffic="true"。这个也算是老问题了，但我几乎每年都看到有同学在这卡半天。

第三件：如果是Windows系统，记得检查防火墙。很多时候代码完全没问题，但市面上免费的个人版防火墙默认阻止了外部设备访问8080端口，导致手机一直连不上。把入站规则放行一下就好了，这个细节特别容易被忽略。

4.2 演示数据的构造与演示环境的稳定性

答辩现场不仅是代码的检验，更是"演示环境的稳定性"的检验。见过太多人因为现场网络状况不佳、或者临时数据没准备好导致整个演示效果崩盘的场景。

建议提前做三件事。第一，后端数据库里准备一批"拟真数据"：商品要覆盖数码、书籍、生活用品、运动器材几个热门分类，价格要有高有低，成色要有全新有九成新有八成新，商品标题和描述要模拟真实的"学姐出二手iPad，考研结束回血""毕业季出自行车，骑了两年，无暗病"。这些细节看起来不起眼，但对展示效果的影响是直接的，评委看到的数据越真实，对系统的完成度感知就越高。第二，准备两到三个测试账号，一个用于演示发布商品的卖家视角，另一个用于演示购买下单的买家视角，切换时不用临时注册。第三，如果答辩教室有网络风险，建议准备一个"演示兜底方案"——比如提前录制好功能演示视频作为备用，万一现场无线网络抽风，直接放视频加口头讲解，总比对着Loading转圈强。

4.3 扩展功能怎么选取：优先做这几个高性价比方向

如果核心功能都完成了、还有时间富余，扩展功能的选择直接决定你项目的上限。但扩展方向的选择要遵守一条原则：优先选那些能体现业务思考、又不会引入太多不稳定因素的功能。

推荐的扩展方向排序如下：

第一个是搜索与筛选。按关键词模糊搜索、按分类筛选、按价格区间筛选、按"仅看认证用户"筛选。搜索功能实现上就是后端的SQL条件拼接，注意MyBatis Plus用LambdaQueryWrapper来动态拼条件非常方便，工作量并不大，但展示时非常直观。

第二个是消息通知。买家对商品留言后，卖家能收到站内通知；订单状态变化时，买卖双方都能收到推送通知。这块不需要真的接第三方推送SDK（那个还要申请厂商账号，太费劲），做站内通知就够了，在通知列表页展示未读数。答辩时讲清楚"基于观察者模式的消息机制设计"，就很有东西讲了。

第三个是个人信用分。可以设计一套简单的规则：完成一笔交易加5分、收到差评扣10分、连续30天活跃加2分。这个扩展示意了"平台治理"的思路，也能引导答辩评委往你准备好的方向问。

不太建议做的扩展是：接入支付宝或微信支付。这个方向牵涉到商户号申请和资质审核，个人身份根本办不下来，做不了真实支付；做个假的支付流程又容易被追问"支付安全问题怎么解决"，把自己绕进去。校园场景的线下当面交易本身就有"避坑"逻辑，也站得住脚。

4.4 时间投入怎么分配才能不熬夜

说点实在的。很多同学前期慢悠悠看视频、摸鱼，等到中期检查前一周突然开肝，结果就是复制粘贴一大堆自己都看不懂的代码，最后答辩时一问三不知。要想从容完成这个项目，我给你一份时间比例参考：需求分析和数据库设计占20%，后端接口开发占30%，Android端开发占35%，联调和论文撰写占15%。

重点提醒是：数据库设计和接口文档这两件事，值得花一个月时间慢慢磨。前期设计多想清楚一点，后期开发就少返工一点。最怕的是数据库表设计好了，写着写着发现少字段，然后直接在运行中的表上改结构——表里的测试数据全废还是小事，代码里各种查询逻辑跟着改才真要命。

5. 复盘：这个项目里最容易翻车的几个隐蔽问题

5.1 图片上传的兼容性问题

前面提到图片上传的方案，这里单独拿出来说，是因为翻车概率太高。除了Bitmap压缩，还有一个很多人忽略的点：不同手机相册返回的图片格式有差异。有些手机拍的照片是HEIC格式，Web端浏览器看不了，但Android App里用Glide加载是没问题的，因为Glide内部做了格式适配。可是如果你想在图片上传前做裁剪或者旋转校正，用普通的JPEG解码方式去处理HEIC图片就会出问题。

做这块的时候，我的建议是：不要在Android端做过度复杂的图片处理。选择图片后，让系统帮你做一次压缩，然后原样上传到后端。需要缩略图时直接用Glide的override()方法按需加载，它能帮你做内存缓存和磁盘缓存，效率比自己手动做高得多。如果确实有旋转问题（现在很多手机拍的照片带EXIF旋转信息），用Glide加载时它默认会处理正，所以也不用自己去读EXIF。

5.2 会话保持里跨域与Header的小坑

有些同学的Spring Boot后端为了省事，给所有接口加了一个极其宽松的跨域配置，allowedOriginPatterns("*")加allowCredentials(true)。结果安卓这边一直请求失败。原理是：虽然Android原生HTTP客户端不受浏览器同源策略限制，但如果你在Web端调试时用了一个带Cookie的请求，跨域配置和Credentials的问题就会暴露出来。另外，如果你的Token是通过自定义Header传的，那必须在跨域配置里把Authorization这个Header名加到allowedHeaders里，否则Web端联调时会看到"Request header field Authorization is not allowed by Access-Control-Allow-Headers"这个经典报错。

5.3 MyBatis Plus分页插件的版本兼容

后端如果用MyBatis Plus，要注意分页插件的配置方式。旧版本是PaginationInterceptor，新版本改成了MybatisPlusInterceptor加PaginationInnerInterceptor。很多人从网上抄了一段旧配置，跑起来分页查询不生效，所有数据一次性返回，表面上看起来没什么问题，但问题出在"查出来的total永远等于当前查询的总数"而不是总数，而且数据量一大就非常影响性能。这个坑不致命，但容易被忽略，联调时建议打印SQL日志，看看有没有LIMIT关键字。

5.4 Android的包名与签名信息不要随便动

最后一个非常隐蔽、但一旦触发就很麻烦的问题：Android应用的包名在创建项目之后不要更改。如果你中途改了applicationId，导致的直接后果就是：本地保存在SharedPreferences里的登录状态、在文件目录中保存的图片缓存、以及你在AndroidManifest里声明的FileProvider的authorities，全部错乱。很多人的真实经历是：项目做到一半，发现应用图标包名带的是默认的com.example...，觉得不好看，想改成一个更"体面"的包名。改完一运行，日志里全是权限访问被拒绝的错，半天时间就耗在排查这个上面了。包名的建议是：项目创建第一天就定好一个正式包名，例如com.campus.secondhand，从第一天开始就住在里面，中途绝不动。

5.5 时间显示与格式化的一致性问题

还有一个看起来低级但实际经常犯的错：数据库里时间用的是datetime，Java实体类里用的是LocalDateTime，返回给Android端的时候变成了一串类似2026-04-12T15:30:00的字符串，然后你在App里直接把这个带T的字符串显示出来，丑得不行。正确做法是在Spring Boot的application.yml里统一配置spring.jackson.date-format和time-zone，实体字段加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")，前后端约定好格式后再也不折腾。如果要做"3分钟前"这类人性化显示，可以在Android端用SimpleDateFormat解析后自己计算差值，这个逻辑不难，但注意别把解析的Locale写错了，否则某些系统语言环境下会出现月份或者星期的乱码。

最后聊一点个人体会。做毕设这件事，最常见的误区是把"完成项目"等同于"写完代码"，但真正的目标其实是"证明你具备独立完成一个系统设计的能力"。所以哪怕技术栈再普通、业务规模再小，只要你能把"为什么这样设计表结构""为什么这个状态流转是安全的""这个并发问题是怎么解决的"讲得清清楚楚，项目的质量自然就立起来了。希望这篇基于Spring Boot和Android的校园闲置物品交易App的拆解，能帮你少走一些我当年走过的弯路。