1. 项目概述：为什么说这是最适合做毕设的Android选题之一
校园信息论坛这个题目，几乎是每年计算机毕业设计里“常青树”级别的存在。我见过太多人选电商系统、选点餐App、选运动打卡，最后做到中期答辩才发现业务逻辑复杂到失控——订单状态机、支付回调、优惠券叠加规则，每一个都是一整章的论文工作量。而校园论坛系统的业务模型足够清晰，但又不至于单薄到一两张表就能糊弄过去，正好卡在“能体现工作量”和“一个人能完成”的最佳平衡点上。
这个题目本质上要解决的是校园内信息分散的问题：课程通知发在微信群、二手交易挂在表白墙、社团活动贴在公告栏、失物招领靠朋友圈转发。做一个统一的移动端论坛，把日常信息聚合到一个入口，从产品逻辑上天然站得住脚。对于毕设而言，这个场景有一个极大的优势——答辩的时候，评审老师本身就是校园场景的参与者，他们能直观理解这个系统的价值，不需要你花大量篇幅去解释业务背景。
从技术覆盖面上看，这个题目也相当划算。Android客户端 + 后端接口 + 数据库设计，一套做下来，移动开发、网络通信、数据持久化、服务器部署全涉及到了，无论你的论文方向偏应用还是偏工程，都有足够的素材可以写。而且论难度，它不会像即时通讯那样要求长连接和消息推送的高可靠设计，也不像地图类应用那样依赖第三方SDK调优，属于投入产出比非常高的选择。
我当时帮一位学弟做这个项目的时候，最大的感受是：这个题目难不在“做出来”，难在“做出体系感”。很多同学拿着Android Studio新建一个项目就往里堆代码，Activity写了两千行，接口地址硬编码在工具类里，数据库只用SQLite存个本地缓存——这样做出来虽然能跑，但论文根本没法写，因为毫无架构可言。这篇博文我就把自己实际做这套系统时踩过的坑、验证过的方案、以及最终采用的完整思路整理出来，你照着这个框架走，不仅能顺利通过答辩，更重要的是能真正搞清楚一个App从零到一的全过程。
2. 技术选型与架构设计
2.1 客户端与后端的方案权衡：我为什么放弃纯本地方案
先解决一个方向性的问题：论坛的数据到底放哪。早期我看到不少毕设选题做的是“单机版论坛”，所有用户数据、帖子数据都存在手机本地SQLite里，根本没有真正的用户登录和多用户交互，只是做了个帖子增删改查的界面。这种方案乍一看省掉了服务器部署的麻烦，但有几个硬伤：第一，毕设答辩时老师大概率会问“A同学的手机怎么看到B同学发的帖子”，你很难自圆其说；第二，论文里“系统架构”那一章基本没法写，因为不存在分布式或前后端分离的架构可谈。
我最终选择的是标准的Client-Server架构：Android客户端负责界面展示和用户交互，后端使用轻量级框架提供RESTful API，数据统一存储在关系型数据库中。这个方案的好处在于每一层都能在论文中独立成章，而且当你熟练掌握之后，这个架构可以横向迁移到任何其他业务场景的毕设项目中。
关于后端技术栈，我针对“本地开发调试方便”和“部署成本低”两个诉求做了对比：
| 方案 | 开发效率 | 部署难度 | 学习成本 | 毕设友好度 |
|---|---|---|---|---|
| Node.js + Express | 高，前后端同语言（JS） | 低，单进程启动 | 中 | 中 |
| Python + Flask/Django | 高，代码简洁 | 低 | 低 | 高 |
| Java + Spring Boot | 中，配置略繁琐 | 中，需打包部署 | 高 | 高（主流） |
| PHP + ThinkPHP | 高 | 极低，虚拟主机即可 | 低 | 中 |
我帮学弟选的是Python + Flask，原因很直接：以论坛这种CRUD为主的业务，Flask的路由写法非常直观，ORM用SQLAlchemy管理数据表，几乎不需要写原生SQL。而且Python的代码量比Java少一半以上，对于需要同时兼顾论文和代码的同学来说，时间分配压力会小很多。如果你后续想走Java方向，这套架构思路完全一致，只是换一套语言实现而已。
2.2 Android端的三层架构：别再让Activity当“万金油”
很多做毕设的同学有一个通病——拿到需求就开始写Activity，把网络请求、JSON解析、界面更新、SharedPreferences存取全部堆在一个类里面。这种代码在功能简单的时候跑起来没问题，但一旦帖子列表、详情页、评论、个人中心都做完，你会发现每个文件的代码量都突破天际，改一个接口字段要全局搜索替换，写论文时连“软件设计”这一章都凑不齐内容。
我推荐的客户端结构是标准的三层：
- View层（Activity/Fragment + XML布局）：只负责界面渲染和用户事件监听，不直接处理业务逻辑。
- ViewModel层：持有界面所需的数据状态，通过LiveData或回调通知View刷新，同时承接用户操作的业务调用。
- Model层（数据仓库 + 网络请求 + 本地缓存）：负责从远程API拉数据、解析JSON、缓存到本地数据库，向上层提供干净的数据接口。
举个例子，当用户在帖子详情页点击“点赞”按钮时，View层只负责调用mViewModel.likePost(postId)，ViewModel内部去调Model层的PostRepository.likePost()，这个请求先走缓存判断，再走网络API，回调结果通过LiveData传回View层。这样每个类的职责都是单一的，论文里画模块图时，三层边界清清楚楚。
网络层我选的是Retrofit + OkHttp，这是目前Android生态里最主流的组合，没有之一。Retrofit把HTTP API声明成Java接口方法，配合Gson做JSON自动转换，代码量比HttpURLConnection写AsyncTask少一个数量级。我见过有同学坚持用原生的HttpURLConnection，理由是“不想引入第三方依赖”，但实际上Retrofit在毕业设计答辩中是加分项，面试官和评审老师都认可这个选型代表你了解行业主流实践。
2.3 数据库与服务器环境：一台学生笔记本就能搞定全套
后端数据库毫不犹豫选MySQL，这是最通用、参考资料最多的选择，没有之一。论坛业务需要的核心数据表非常清晰，我在设计阶段就整理成了以下结构：
- user表：用户基本信息，包括用户名、密码哈希、昵称、头像URL、个人签名、注册时间。密码绝对不能明文存储，至少也要做一次加盐的SHA-256哈希，这是我特别强调的安全底线。
- post表：帖子主体，包含标题、正文内容、所属板块ID、发帖人ID、发布时间、最后回复时间、浏览量、点赞数、置顶状态。
- comment表：评论记录，关联帖子ID和评论人ID，支持嵌套回复的话再加一个parent_id字段。
- board表：板块分类，比如“校园生活”“学习交流”“二手交易”“失物招领”，结构上只需要id、名称、描述、图标URL。
- like_record表：点赞记录，用于防止重复点赞，联合唯一索引(user_id, post_id)。
服务器端我在开发阶段直接跑在本机，用Flask的debug模式监听局域网IP，手机和电脑连同一个Wi-Fi就能联调，完全不需要租用云服务器。等到中期检查或最终演示前，再花几十块钱租一台最便宜的云主机，把代码部署上去，客户端把BaseURL从局域网地址换成云服务器公网IP就行。
3. 核心功能与模块拆解
3.1 用户系统：登录注册的完整闭环
用户模块是一个论坛的门面，也是工作量最实打实的部分。我建议至少实现注册、登录、退出登录、个人信息查看与编辑这五个功能，如果把密码找回也加上，论文内容会更有底气。
注册流程我做了客户端字段校验和服务端二次校验的双保险。客户端检查项包括用户名长度（3-20位）、密码强度（至少8位且包含数字和字母）、两次密码一致性；服务端再校验用户名是否已经被占用。这里有一个非常容易踩的坑：只做前端校验导致用户绕过客户端直接调API传脏数据，所以我服务端用了一组简单的条件判断兜底，不合规直接返回带错误码的JSON。
登录成功后服务端返回用户对象和一个token值，客户端把token存进SharedPreferences，后续所有需要身份认证的接口都在请求头带上这个token。服务端用一个装饰器去解析请求头中的token并反查用户，查不到就返回401，客户端收到401就跳转回登录页。这是拦截未登录操作的标准做法，比在每个Activity里手动判断用户是否登录要优雅得多。
关于Token的过期策略，我采用的是“长期有效但包含签发时间”的简单方案：Token过期时间设置为30天，每次请求时检查签发时间是否过期。这个方案虽然不如JWT标准，但对于毕设而言完全够用，而且逻辑一眼就能看懂，答辩时你不需要给老师花20分钟解释无状态认证原理。
3.2 帖子浏览与发布：信息流是论坛的心脏
首页信息流是整个App里用户感知最强的部分，我采用的是分页加载的帖子列表。顶部是轮播图横幅推荐位，下方是板块Tab栏，再往下是瀑布流卡片式帖子列表。每张卡片展示标题、部分正文摘要、作者昵称和头像、发布相对时间、浏览量、点赞量和评论数。这些信息直接绑定的是列表数据源中的一个Post模型对象。
帖子列表的数据加载我用的是经典的分页策略：每页加载10条，上拉到底部时自动加载下一页，同时在下拉刷新时重置页码重新拉取第一页。服务端SQL通过LIMIT #{offset}, #{pageSize}实现物理分页，接口返回JSON中带上totalPage字段，客户端据此判断是否有下一页可加载。
在这个模块里有个非常影响体验的细节：列表图片的加载必须用异步方式。我用的Glide图片加载库，在CardView嵌套的ImageView中只需一行代码就可以完成占位图、加载中动画、圆形裁剪这些操作。如果不用Glide而直接在Adapter里用BitmapFactory解码，列表滑动时很容易触发“太滑不动、甚至OutOfMemory”的问题，这个坑我在早期版本就踩过，换上Glide后彻底解决。
发布帖子的流程我做了两步：第一步选择板块、填写标题和正文，加图片的话调系统的图片选择器（通过Intent调起Photo Picker），拿到图片URI后先压缩再上传；第二步点击发布，客户端组装Post请求，调用post API，服务器入库成功后发现帖子的新动态广播，信息流自动刷新。
3.3 评论与互动细节：热度和实时感从哪里来
评论模块最基础的是两级评论结构：帖子下面直接挂一级评论，一级评论下面可以再挂二级回复。数据表设计上我用了parent_id字段，为0就是一级评论，否则就是某一级评论下的子回复。查询时一次查出整个帖子下的所有评论，在内存中根据parent_id递归组装成评论树，这样做只用一次数据库查询就避免了N+1的循环查库问题。
点赞功能是我认为整个项目中最能体现工程思维的一环。客户端点击点赞后不能直接改显示数字，因为这样会产生乐观更新的并发问题；我采取的方式是即时显示“点赞中”状态，调用like API请求，成功后根据返回结果更新点赞数。服务端的实现也不复杂：先查like_record表有没有记录，没有就插入并把post表的like_count加一，有就删除并减一，整个过程包在一个事务里。
浏览量统计这里有个小设计，我把它加在“帖子详情”接口里面，每次进入详情页调用详情接口时浏览量自动加一。为了防止重复刷新刷高浏览量，我在客户端加了一个简单策略——同一用户对同一帖子每10分钟内只计一次浏览。真实场景下浏览量数据难免有一定水分，但在论坛系统里这个思路完全可接受。
3.4 管理后台：一个轻量级Web页面就够了
很多同学做论坛项目只做Android端，答辩时老师问“如果有人发垃圾广告怎么办”，然后当场语塞。我的建议是：一定要加一个简单的Web管理后台，你不用做得很重，但是“话题管理、帖子删除、用户禁言”这三件套必须有。
后台我用的是Flask自带的Jinja2模板渲染，没有做成前后端分离SPA，因为对于内部人员使用的管理页面，服务端渲染最省事。管理员登录后能看到全站帖子列表，按板块和发布时间筛选，点“删除”按钮可以物理删除违规帖子，点“禁言”按钮可以把某个用户加入黑名单。统计面板上展示用户总数、今日发帖数、总帖子数和各板块帖子数对比图表——这个图表我用的是ECharts的CDN，接入成本极低但呈现效果非常好，论文里截图放到“系统实现”一章会非常加分。
4. 实操过程与关键实现
4.1 第一步：环境配置与项目骨架搭建
先说开发环境。Android Studio版本我用的是较新的稳定版，JDK用的17，Gradle配置走的是Android Gradle Plugin的标准配置。要注意的是，如果你用Flask作为后端，Android端的网络请求默认不允许明文HTTP流量——这是Android 9（API 28）开始强制执行的策略，必须要在AndroidManifest.xml中给application标签加上android:usesCleartextTraffic="true"属性或者在网络配置文件里放行特定域名，否则你本地联调时跑API都调不通，这个坑几乎每个初学者都会遇到。
项目骨架我按照下面的包结构组织：
com.example.campusforum/ ├── data/ │ ├── model/ # Post、User、Comment等实体类 │ ├── network/ # Retrofit接口声明、OkHttp配置 │ ├── repository/ # 数据仓库，封装网络和缓存逻辑 │ └── local/ # Room数据库、SharedPreferences封装 ├── ui/ │ ├── login/ # 登录注册Activity │ ├── main/ # 主界面Activity和Fragment容器 │ ├── post/ # 帖子列表、详情、发布 │ ├── mine/ # 个人中心 │ └── adapter/ # RecyclerView相关Adapter ├── utils/ # 时间格式化、图片压缩等工具类 ├── App.java # Application初始化类 └── config/ └── ApiConfig.java # 全局接口地址配置包结构清晰之后，你会发现写代码的节奏感完全不同——你想找某个功能的时候，直接根据包名定位，不用在整个工程里搜索类名。这一步对论文里的“系统模块设计”章节也有直接价值，你完全可以把这个包结构图直接画成模块架构图放进去。
4.2 第二步：数据库建表与服务端接口编码
MySQL建表我直接通过Navicat图形化创建，偷懒点的做法是写一份schema.sql脚本一次性执行导入。下面这个是我实际用的是简化版帖子表结构，你可以参考着扩展：
CREATE TABLE `t_post` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL COMMENT '发帖人ID', `board_id` int(11) NOT NULL DEFAULT '1' COMMENT '板块ID', `title` varchar(120) NOT NULL COMMENT '标题', `content` text COMMENT '正文内容', `image_urls` varchar(500) DEFAULT NULL COMMENT '图片URL，多个用逗号分隔', `view_count` int(11) NOT NULL DEFAULT '0', `like_count` int(11) NOT NULL DEFAULT '0', `comment_count` int(11) NOT NULL DEFAULT '0', `is_top` tinyint(1) NOT NULL DEFAULT '0' COMMENT '是否置顶', `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1正常 0已删除', `create_time` datetime NOT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_board_time` (`board_id`, `create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='帖子表';几个设计上要留意的点：content字段用text类型而不是varchar，因为帖子正文可能超过255字符；图片URL用逗号拼接的字符串存储而不是单独建一张图片表，这是为了在毕设这种中小规模业务下减少表关联复杂度——当然你要在论文里严谨一点，也可以拆成t_post_image子表，但我个人觉得额外的复杂度对毕设收益不大；时间字段统一用datetime，前端展示时再格式化为“x分钟前”这种相对时间，更友好。
Flask服务端我定义了一组RESTful路由，比如：
| 方法 | 路由 | 功能描述 |
|---|---|---|
| POST | /api/auth/register | 用户注册 |
| POST | /api/auth/login | 用户登录 |
| GET | /api/post/list?page=1&board_id=2 | 分页获取帖子列表 |
| GET | /api/post/detail?id=10 | 获取帖子详情 |
| POST | /api/post/publish | 发布新帖 |
| POST | /api/post/like | 点赞/取消点赞 |
| POST | /api/post/comment | 发表评论 |
| GET | /api/board/list | 获取板块列表 |
这里再强调一个很容易被新手忽略的细节：Flask返回JSON时，jsonify方法默认输出的中文是Unicode转义形式，也就是\u4e2d\u6587这样的格式，虽然客户端能正常解码，但调试时看着非常难受。在app.run()之前加一行配置app.config['JSON_AS_ASCII'] = False就能输出原生中文，这个小技巧能让你的调试日志可读性翻倍。
4.3 第三步：Android客户端核心代码实现要点
网络请求层是最先要写的，我封装了一个极简的API工具类，中心是一个Retrofit实例：
public class ApiClient { private static final String BASE_URL = "http://192.168.1.100:5000/"; private static Retrofit retrofit = null; public static Retrofit getClient() { if (retrofit == null) { OkHttpClient client = new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(10, TimeUnit.SECONDS) .addInterceptor(new AuthInterceptor()) // 自动附加token .build(); retrofit = new Retrofit.Builder() .baseUrl(BASE_URL) .client(client) .addConverterFactory(GsonConverterFactory.create()) .build(); } return retrofit; } }AuthInterceptor是我强烈建议你花10分钟写出来的一块逻辑。它能拦截到每次请求，自动从SharedPreferences里取出用户token并加到请求头的Authorization字段。这样你在业务代码里调用API时完全不用关心“当前用户是谁”，服务端通过解析token自然知道身份，不管是发帖、评论还是点赞，接口调用代码都极其干净。
主界面的帖子列表用的是RecyclerView + ViewBinding + LiveData的组合。PostListFragment里持有PostViewModel，ViewModel持有MutableLiveData<List<Post>>，Adapter数据变化触发时通过submitList刷新界面。下拉刷新用SwipeRefreshLayout，分页上拉加载是在Adapter里设置OnScrollListener，滑到底部时回调nextPage()方法触发加载。
帖子详情页我有一个很得意的设计——把评论加载和帖子详情拆成两个接口并发请求，页面骨架先出来，哪个接口先返回就先渲染哪块。让用户感觉“App非常快”的秘诀不在于接口本身快，而在于你不要让用户在等待时盯着一张纯白屏。哪怕只是先展示帖子标题和正文，再慢慢加载评论，用户的等待感知都会大幅下降。
发布帖子时选择的图片，必须做压缩处理。我写了一个ImageCompressor工具类，利用系统API读取图片的尺寸比例，先做采样压缩到最大不超过1080px宽，再通过压缩质量把单张图片控制在200KB以内，最后走Retrofit的Multipart上传接口。不压缩的话，一部手机拍出来的照片至少3MB，用户随便传三张图就是10MB，不仅上传慢，服务器存储空间也撑不住。毕设演示的时候现场如果网速不稳定，图片压缩这个细节直接决定你的Demo是否流畅。
4.4 第四步：前后端联调、打包与演示环境准备
联调阶段我有两个建议给你。第一是务必先写一个简单的接口自测脚本，用Python的requests库直接去调后端的API，确认每个接口的请求和返回都正常再做Android端的界面对接。这样可以过滤掉“到底是客户端代码写错了，还是服务端逻辑有Bug”的干扰因素。第二是Android端日志要打清楚，Retrofit的LoggingInterceptor在debug模式下打印完整请求URL和响应体，遇到问题直接看Logcat，千万不要靠猜。
打包安装到手机上的时候注意，有一些同学图方便直接用USB连Android Studio的Run按钮跑App，现场演示时手机一拔掉数据线，应用就不能用了。正确的做法是Build -> Generate Signed Bundle or APK，生成签名后的APK文件传到手机上安装。没有签名密钥的话，用Android Studio的“Generate Key Store”功能生成一个即可，整个过程10分钟。
最后再提醒一个非常重要的演示准备：把服务端部署到云主机之后，一定要在Android端的ApiConfig.java里把BASE_URL从局域网IP改成云服务器公网IP，重新打包。最好提前做一次“断网模拟”——把手机切到4G流量而不是Wi-Fi，确认App能正常通过公网访问。有过太多同学在答辩现场发现模拟器里跑得通，换到真机就变成一片空白的惨案，都是因为忘了改接口地址或者没开放云主机的安全组端口。
5. 常见问题与避坑经验
5.1 数据库与接口层面的高频故障
在帮学弟做这个项目的过程中，我整理了一个问题速查表，你在开发过程中碰到的80%的问题应该都能在这里找到答案：
| 症状 | 根因分析 | 解决办法 |
|---|---|---|
| App端请求一直返回超时 | 手机和电脑不在同一局域网，或后端绑定了127.0.0.1 | Flask跑在0.0.0.0；确保连通性（ping验证） |
| 客户端能请求通但数据解析失败 | 后端返回的JSON字段名与实体类不对应 | 用Gson的@SerializedName注解映射或统一命名风格 |
| 发中文内容保存后显示乱码 | MySQL表或连接字符集不是utf8mb4 | CREATE DATABASE xxx CHARACTER SET utf8mb4；连接URL加?useUnicode=true&characterEncoding=utf8 |
| 评论列表出现重复数据 | 分页查询中的LIMIT offset在数据变动时失效 | 改用游标分页或固定主键排序后再limit |
| 点赞计数时多时少 | 并发情况下like_count = like_count + 1引起丢更新 | 使用UPDATE t_post SET like_count = like_count + 1让数据库原子操作 |
| 上传图片后服务器找不到文件 | 客户端传的文件名包含中文或特殊字符 | 服务端统一用UUID重命名图片文件再落盘 |
| APK安装到手机后一打开就闪退 | 签名包用的是debug版本产生的debug keystore | 配置release签名或用正式签名打包 |
这里有一个比较隐蔽的坑值得单独拿出来说：MySQL在事务隔离级别下，如果两个请求同时读写like_record表和like_count字段，可能产生死锁。我的解决方法是把点赞记录判断和计数更新放在同一个存储过程中执行，或者至少在应用层用SELECT ... FOR UPDATE加锁。毕设项目并发量不大，一般不会真的触发，但一旦答辩老师追问“高并发下你怎么保证数据一致性”，你能把加锁方案讲出来，绝对是个加分项。
5.2 Android端最容易踩的坑：主线程、上下文和内存
Android开发里有几个基础但致命的点，我在这个项目里反复给学弟纠正，在这里集中列出来：
主线程网络请求：很多人一上来就在onCreate里写new Thread(() -> httpRequest()).start()，然后在线程里更新UI崩溃——因为Android不允许在子线程直接操作UI。用Retrofit天然避开问题，因为Retrofit的回调默认切回主线程执行，你只管写界面更新逻辑就好。如果你的项目保留了原生网络请求代码，务必用Handler或runOnUiThread包一下。
Context泄漏：在Activity里初始化单例工具类时传入this，如果这个单例被静态持有，Activity销毁后仍然被引用导致内存泄漏。正确做法是传getApplicationContext()。严格的LeakCanary检查能抓出这一点，但一般你只需要养成一个习惯——跨生命周期对象一律用applicationContext。
自动装箱与空指针：从结果里取出一个Integer类型的viewCount，直接拼接到字符串时如果为null就会崩溃。建议所有从JSON解析出来的字段都做默认值兜底，在模型类里这样处理：
public int getViewCount() { return viewCount == null ? 0 : viewCount; }不要小看这行代码，它可能帮你省掉答辩前一晚调试崩溃日志的最痛苦两小时。
5.3 图片加载与内存优化：Glide的高效玩法
如果你没有用Glide而用了原生方式加载网络图片，我强烈建议立刻切换。Glide不仅负责加载，还负责三级缓存、图片复用和生命周期绑定，一个URL直接加载到ImageView里：
Glide.with(context) .load(post.getImageUrls().split(",")[0]) .placeholder(R.drawable.ic_placeholder) .error(R.drawable.ic_error) .circleCrop() .into(imageView);在RecyclerView列表场景中，图片错位是一个著名的坑：滑动后ViewHolder被回收复用，图片显示位置不正确。Glide通过into()自动绑定ItemView生命周期，基本不会遇到这个问题，但如果你起了一个手动加载的图片任务，一定要在ViewHolder复用时取消旧任务，否则就会错位。
关于图片缓存还有一个小优化：Glide默认缓存原始尺寸图片，在列表里加载时我设置了override(300, 300)强制压缩为缩略图，这样即便原图有2MB，列表滑动加载时也几乎无感知，点开大图时再重新加载原图。整个App的流畅度会因此上一个台阶，我实测列表帧率从偶发掉帧到稳定满帧。
5.4 服务端部署：云主机上的安全与稳定性配置
部署阶段，很多同学直接把Flask开发服务器（app.run()）开着就完事了，这在公网上是完全不可取的——Werkzeug内置服务器仅适合开发调试，并发能力弱而且容易崩。我用的是gunicorn把Flask应用跑起来，配合nginx做反向代理。
部署的完整流程我整理一下：
- 购买一台最便宜的云主机，装好Ubuntu，开放22（SSH）、80（HTTP）、3306安全组端口（如果你用云数据库，则只开放应用到数据库的内网访问）。
- 把项目代码通过git推到服务器，或者直接scp上传。
- 服务器上创建Python虚拟环境，执行
pip install -r requirements.txt。 - 用gunicorn启动服务：
gunicorn -w 4 -b 0.0.0.0:8000 app:app，注意-w表示worker进程数，建议设为CPU核心数的2倍；app:app前一个是Python文件名，后一个是Flask实例名。 - 配置nginx反向代理，把
location /api/转发到本机的8000端口，同时配置client_max_body_size 20m，否则你传大图的时候会直接被nginx拒绝。 - 最后用
supervisor守护gunicorn进程，防止进程意外退出后服务不可用。
这套流程中nginx的配置其实是一个非常好的论文素材，你可以把“服务器性能与安全加固”写成论文的一个小节，而且它也是你简历上可以写的真实技能。如果时间不够，我建议至少做“gunicorn + supervisor”两步，supervisor一行命令就能守护进程。
6. 从毕设到项目经验：这个题目带给我的几点后话
帮学弟完整做下来这个项目之后，我最大的体会是：论坛系统不是一个“高级”的系统，但正因为业务足够亲民，你才有精力把架构和工程质量打磨到一个完整的高度。那种把每个接口都定义清楚、每个实体都设计好、每层之间边界划分明确的感受，和为了炫技堆砌复杂框架是完全不同的成长路径。
如果你时间还充裕，我真心建议你在基础功能完成后，挑战以下几个进阶方向：
- 给帖子增加富文本编辑（比如图文混排、@好友提醒），用到的技术是Android的TextStyle和Span，以及服务端的HTML解析与渲染，能显示你的前端功底。
- 把列表改为推荐排序而非纯时间排序，通过热度值=浏览量×0.3+点赞数×5+评论数×10+时间衰减因子计算，这个算法本身就可以写成论文的创新点之一。
- 做消息推送，比如有人回复了你的帖子时，服务端通过极光推送或Firebase Cloud Messaging通知到Android端。如果不用第三方SDK，也可以做一个基于MQTT的简易推送服务，写到“系统特色”里面够分量。
- 做过的用户行为数据采集与展示：用户停留时长、最活跃板块、发帖时段分布等，用ECharts做可视化图表放在管理后台，论文里的“数据分析”章节就有着落了。
最后说一个我在演示前总结的小经验：毕设答辩最看重的是“你亲手把系统从零搭起来并解决了真实问题”的能力。不要只盯着功能做完了没有，多问问自己“为什么这么设计”“如果不这么做会怎样”。当你能流畅回答出这两个问题时，你的答辩基本上稳了。
如果这篇分享给你省下了一些绕路的时间，那就够了。去把代码跑起来吧，遇到问题也别慌——大部分坑，我都替你踩过了。
