考研这仗，一半是复习，另一半是信息战。每年那么多考生，找真题、求经验贴、问专业方向，信息全散在QQ群和贴吧里，不是被广告刷屏就是被旧帖子误导。我前阵子给学校做了一套"校园考研论坛交流系统"，技术路线就是标题里那三样：Python 搭后端接口、uni-app 写前端框架、最后编译成微信小程序发布上线。整套做下来，最大感触是论坛类项目看着简单，真正落地时"微信登录闭环、社区内容治理、小程序包体积控制"这三块才是耗时间的重头戏，任何一个都能让你从下午折腾到凌晨。
这篇文章适合三类人：一是计算机相关专业准备拿项目做毕设或课设的同学，二是想给学校、学院搭一个内部交流工具的学生开发者，三是对 Python 后端和 uni-app 跨端开发的协作方式感兴趣、想跑通全链路的人。我会把需求拆解、数据库设计、微信登录流程、uniapp 页面搭建、打包上线排坑一条线讲完，代码和配置都是可以直接抄的级别，但更重要的是我会说明每一步为什么这么选，避免你做完项目答辩时被问住。
1. 需求拆解与技术选型：校园考研论坛到底该怎么做
1.1 先别急着写代码，把场景和功能盘清楚
校园考研论坛和普通社交论坛有一个本质区别：用户带着非常明确的"阶段性目标"进来，要么是找目标院校的信息，要么是找同路人，要么是分享刚踩完的坑。需求高度垂直，所以功能设计不能照着贴吧抄。
我做需求梳理时，把用户分成了三类：已经上岸的学长学姐、正在备考的在校生、准备考研但还在选学校的大三学生。三类人的诉求分别是"分享与获得认可""获取资料与答疑""消除信息差"。基于这个，核心功能定为五个模块：
- 资料库：按学校、专业、科目分类的真题和笔记上传下载
- 经验贴：考研上岸经验分享，支持按年份、院校筛选
- 问答区：专业课问题、复习规划问题互答，类似轻量版知乎
- 研友匹配：按目标院校和专业维度找研友组队打卡
- 院校信息：分数线、报录比、考试科目等基础数据展示
这五个模块不需要做成大而全的 CMS，MVP 阶段只需要保证信息能发布、能分类、能检索、能互动。我在初版里砍掉了私信功能，因为小程序的消息推送机制做站内信成本不低，而且研友之间完全可以通过帖子评论区互留联系方式，先把最小闭环跑通比什么都强。
论坛类产品最忌讳的是"功能堆砌但没人用"。所以我在设计时反复强调一个原则：发帖路径要短，信息沉淀要有价值。资料库上传、经验贴发布、问答提问这三个动作，全部控制在三次点击以内完成，这直接影响后期冷启动的用户留存。
1.2 技术栈选型：Python 后端 + uni-app 前端 + 微信小程序载体
技术选型是这种项目里最容易被"跟风"的部分，但我要说清楚我为什么这么组合，而不是别人这么用我就这么用。
后端选 Python 而不是 Java、Go，核心原因是开发效率和生态匹配。论坛类系统的核心逻辑是 CRUD 加权限控制，Python 的 Flask 框架写起来非常轻快，几行路由就能把接口跑起来。而且 Python 生态里有现成的微博情感分析、敏感词过滤、文本分类库，后面做内容治理和"垃圾帖识别"时直接用现成模型，不用从零训练。Flask 和 Django 之间我选了 Flask，原因是这个项目表结构不算特别复杂，Django 自带的后台管理虽然方便，但模型层和中间件的学习成本高，Flask + SQLAlchemy 的组合足够清晰，答辩时也更容易讲清楚每一行代码。
前端选 uni-app 而不是原生微信小程序，最主要的原因是"一套代码多端复用"。校园项目有个很现实的情况：一开始是微信小程序，后面学院可能会要求出一个 H5 版方便电脑端访问，甚至打包成 Android App 放到应用市场。uni-app 基于 Vue 语法，写一次可以同时编译到微信小程序、H5、App 等多个平台，实测下来微信小程序端的兼容性基本没有大坑。而且 uni-app 的生态组件库比原生小程序丰富，像是下拉刷新、上拉加载、消息提示这些高频能力都有现成封装。
顺便提一句最近总有人问的 uni-app 和 uni-app x 的区别。uni-app x 是下一代跨端框架，用 UVue 语法，编译到原生渲染，性能和体验更好，但目前生态还在完善中，很多第三方插件只兼容老版 uni-app。做校园论坛这种以内容展示为主的项目，稳字当头，选成熟稳定的 uni-app 完全够用，没必要追新。
载体选微信小程序，理由更是简单直接：零安装成本、扫码即用、微信内天然传播。考研学生在图书馆刷手机看到同学转发到群的论坛小程序，点开就能用，这个体验是任何需要下载安装的 App 都给不了的。小程序还有现成的微信登录体系，省去了一套用户名密码注册流程，对用户来说"一键登录"是降低使用门槛的最大利器。
1.3 功能模块全景：信息流、资料库、问答互动
整个系统我用一张功能矩阵来收敛需求，分成"内容生产"和"内容消费"两侧。生产侧包括发帖、评论、回复、上传资料、点赞收藏；消费侧包括信息流浏览、按分类筛选、关键词搜索、帖子详情阅读。
信息流是主页面的核心，我采用的是"最新 + 热门"双 Tab。最新 Tab 按创建时间倒序，保证更新频率；热门 Tab 按 24 小时内的浏览量、评论数、点赞数加权排序，权重公式就一行：热度 = 浏览量 * 0.3 + 评论数 * 0.5 + 点赞数 * 0.2。这个公式不用太精确，目的是让有人互动的好帖子能浮上来，而不是让广告帖和自顶帖霸屏。
问答区和服务区其实可以共用一套帖子表，只用 category 字段区分。刚开始我纠结过要不要给问答单独建表，后来想通了：从产品角度看，经验贴和问答的差别只是"有没有明确的提问对象"，数据模型完全一样，强行分表只会增加联表查询的成本。评论区用 parent_id 字段支持楼中楼回复，两级就够，不要无限套娃，否则前端渲染树会非常难维护。
资料库的设计稍微特殊一点，因为涉及文件上传。微信小程序的 wx.uploadFile 有 10MB 的单次上传限制，但考研真题的 PDF 经常超过这个体积，所以后端要额外开一个文件分片上传接口，或者直接把文件转存到对象存储再返回 URL。如果学校有服务器资源，也可以用 FastDFS 之类的轻量文件服务器。
2. 后端设计与实现：Python 这一侧的核心代码逻辑
2.1 数据表设计：用户、帖子、评论、点赞、关注
这个系统的表结构我设计得尽量精简，但每张表都能扛住核心业务。总共五张主表：users、posts、comments、likes、follows。
users 表的字段重点是 openid 和用户画像。openid 是微信体系里用户在小程序内的唯一标识，必须建唯一索引。用户画像字段包括 nickname、avatar、school、major、target_school、target_major，后面做研友匹配和内容推荐都靠这些。target_school 和 target_major 是"考研人"这个身份区别于普通论坛用户的关键字段，务必保留。
posts 表的核心字段是 title、content、category、school、major、views、likes_count、comments_count。category 用字符串还是用数字枚举？我建议直接用字符串"experience""question""material""team"，可读性强，前端拿到也不用再做一层映射。school 和 major 字段之所以冗余在帖子表里，是为了列表页能直接按学校筛选，不用再 join 用户表查发起人的信息，这是空间换时间的典型做法。
comments 表字段是 post_id、user_id、content、parent_id。parent_id 为 NULL 表示顶层评论，有值表示是某条评论的回复。这里有个细节：楼中楼查询时要先取顶层评论，再批量查所有子回复，最后在内存里组装成树。如果直接在数据库里用递归查询，数据量一大性能就会崩，实测 10 万条评论后递归 CTE 查询时间从几十毫秒涨到几百毫秒，而内存组装始终稳定。
likes 表用 user_id + target_type + target_id 三个字段做联合唯一索引，target_type 区分"帖子"和"评论"，target_id 存对应的主键。点赞功能最怕的是用户疯狂点取消再点赞刷数据，所以接口层要做幂等：先查有没有记录，有就 delete，没有就 insert，不搞 counter 自增字段的复杂逻辑。
我另外加了一张 banned_words 表，专门存敏感词和广告词，配合 Python 侧的正则匹配做发帖拦截。这里面除了常规的违规词之外，还要重点拦截"代写""包过""内幕资料"这类考研圈典型的诈骗高频词，因为这些词对学生的杀伤力比普通广告大得多。
2.2 微信登录闭环：code 换 openid，再换 JWT
微信小程序的登录流程很多人第一遍写都是懵的，我给一个完整闭环。小程序端调用 uni.login 拿到临时 code，后端拿这个 code 去微信服务器换 openid 和 session_key，然后自己签发 JWT 返回给前端。前端后续所有请求在 header 里带 JWT，后端验证通过就认为用户已登录。
这里最关键的认知是：小程序端永远不能直接拿到 openid，必须经过后端转发。原因很简单，请求带上 AppSecret 的调用如果放在前端，AppSecret 会直接暴露，任何人拿到就能冒充你的小程序调用微信接口。当年很多人踩过这个坑，所以现在官方文档都强调 code2session 必须由后端发起。
后端换 openid 的代码很短：
import requests def wx_code_to_session(code): url = "https://api.weixin.qq.com/sns/jscode2session" params = { "appid": APP_ID, "secret": APP_SECRET, "js_code": code, "grant_type": "authorization_code" } resp = requests.get(url, params=params, timeout=5).json() if resp.get("openid"): return resp["openid"], resp.get("session_key") # 失败时 resp 里会有 errcode 和 errmsg return None, None拿到 openid 后，先去 users 表查这个 openid 是否存在，存在就直接签发 JWT，不存在就自动注册一个只带 openid 的空用户，等用户后续完善头像昵称和学校信息。这样登录链路不用用户手动注册，也保证了一次登录就能进首页。
JWT 签发我用 PyJWT 库，payload 里放 user_id 和过期时间。注意别把 openid 明文塞进 JWT，openid 属于敏感信息，泄露出去虽然不至于直接被盗号，但会让人拿去撞库匹配微信生态内的其他服务。JWT 的过期时间我设置成 7 天，小程序端每次启动时做一次静默登录刷新 token，体验上用户永远感觉不到登录的存在。
2.3 RESTful API 清单：前后端接口是怎么对齐的
接口设计遵循一个原则：资源名词复数 + HTTP 方法表达动作，不做 RPC 式接口。这个项目对外暴露的核心接口如下：
| 方法 | 路径 | 功能 | 说明 |
|---|---|---|---|
| POST | /api/auth/login | 微信登录换 token | 传 code，返回 JWT |
| GET | /api/users/me | 获取当前用户信息 | header 带 token |
| PUT | /api/users/me | 完善用户资料 | 传昵称、院校、专业等 |
| GET | /api/posts | 帖子列表 | 支持 category/school 筛选和分页 |
| POST | /api/posts | 发布帖子 | 需要登录 |
| GET | /api/posts/:id | 帖子详情 | 浏览量加一 |
| POST | /api/posts/:id/like | 点赞帖子 | 幂等，再点取消 |
| GET | /api/posts/:id/comments | 获取评论树 | 返回两层结构 |
| POST | /api/posts/:id/comments | 发表评论 | parent_id 为空是顶层评论 |
| GET | /api/materials | 资料列表 | 按学校专业筛选 |
分页参数统一用 page 和 page_size，后端限制 page_size 最大 20，防止有人拉全量表。返回体统一包一层 {"code": 0, "message": "ok", "data": ...}，约定 code 为 0 表示成功，非 0 表示业务错误码。前端 request 封装里只判断 code，HTTP 状态码只用来区分网络层错误，这样前后端调错的边界非常清晰。
我在实际开发中特意加了统一的异常处理装饰器。Flask 里如果不做异常兜底，数据库查询抛一个 DuplicateEntry 错误，前端拿到的就是一段 HTML 堆栈日志，排查麻烦不说，还容易泄露表结构。统一处理后，后端返回 {"code": 5000, "message": "服务器繁忙，请稍后再试"}，问题日志在服务端单独记录，对用户友好对开发也友好。
3. uni-app 小程序端开发实录
3.1 工程初始化：从新建项目到跑通首页
uni-app 创建工程有两种方式，一种是用 HBuilderX 可视化创建，一种是命令行用 vue-cli 创建。毕设场景我用 HBuilderX 比较多，因为可视化创建项目后直接点"运行到微信开发者工具"就能调试，不用自己配编译链路。选择模板时注意：如果打算用 Vue3 语法就选"Vue3"模板，Vue2 和 Vue3 的响应式原理差异不小，中途切换会带来大量代码改动。
创建完项目后，pages.json 是第一个要动的地方。这个文件是小程序端的路由和页面配置中心，等价于原生小程序的 app.json 加 pages 配置。我在 pages.json 里配了五个主页面：首页信息流、资料库、发布中心、消息通知、个人中心。底部 TabBar 的图标我直接用 iconfont 字体图标转成 base64 图片，避免每个 Tab 单独切图增加包体积。
运行到微信开发者工具前，还需要在 manifest.json 里配置微信小程序 AppID。这里有个小坑：测试阶段可以先用测试号，但体验版和正式上线必须用自己的 AppID，而且 AppID 对应的小程序主体需要和企业或学校主体一致，个人主体很多类目没法过审。后面讲上线我会再展开说这点。
跑通工程后，第一件事就是封装请求库。我习惯在 utils 目录下建一个 request.js，把所有 uni.request 调用的公共逻辑收拢到一起，包括 baseURL 拼接、token 注入、状态码拦截、错误提示。这样后续所有页面里只需要 import 这个 request 函数，不用每处都写一遍 uni.request 模板代码。封装看起来是工程规范问题，但在小程序这种弱网环境下，统一超时处理和数据归一化能避免大量重复 bug。
3.2 登录、资料完善与手机号获取：2021 年后的正确姿势
微信小程序登录和获取用户信息的接口在 2021 年后改过一版，网上很多教程还是老写法，照抄必踩坑。老的 wx.getUserInfo 弹窗授权已经失效，现在拿不到用户的真实头像和昵称。新方案是"头像昵称填写能力"：头像用 button 的 open-type="chooseAvatar"，昵称用 input 组件的 type="nickname"，由用户在页面上主动选择填写。
手机号获取也有新老之分。老方案是 getPhoneNumber 返回加密数据，后端配合 session_key 解密；2023 年后官方推荐的是用手机号快速验证组件返回 code，后端再拿 code 换手机号。这个 code 的有效期只有 5 分钟，而且一个 code 只能用一次，后端做缓存时要注意别把 code 存太久。
登录页我的做法是一个"微信一键登录"按钮，点击后执行三步：uni.login 拿 code、调用后端 /api/auth/login 换 token、存 token 进 storage。如果是新用户，自动跳转资料完善页，要求填写学校、专业、目标院校和目标专业。这一步不能省，因为后续帖子的推荐和筛选全靠这些画像字段。很多人为了省事不做资料完善步骤，结果首页信息流没法按学校过滤，产品价值直接砍一半。
// pages/login/login.vue 核心逻辑 async function wxLogin() { const { code } = await uni.login({ provider: 'weixin' }) const res = await request('/api/auth/login', 'POST', { code }) if (res.code === 0) { uni.setStorageSync('token', res.data.token) if (res.data.is_new_user) { uni.navigateTo({ url: '/pages/profile/edit' }) } else { uni.switchTab({ url: '/pages/index/index' }) } } }这里要特别提醒：uni.login 拿到的 code 是一次性的，时效只有几分钟，而且每次调用 uni.login 都会刷新这个 code。我在开发时就遇到过反复调 uni.login 导致前一个 code 失效的问题，正确的做法是登录流程里只调一次 uni.login，后面不要为了拿用户信息再调第二次。
3.3 列表页、详情页与发布页的代码套路
信息流列表页我用的是"页面滚动到底部自动加载下一页"的模式，配合 uni-app 的 onReachBottom 生命周期。渲染层直接遍历数组即可，数据请求封装成分页拉取函数。列表项组件拆成单独文件，避免每个帖子卡片里的头像、标题、点赞数渲染逻辑全堆在首页里，后期维护会想哭。
帖子详情页除了正文渲染外，重点是浏览量统计。我在后端接口里做了"详情接口调用时 views 加一"的逻辑，但前端要注意防止用户不断下拉刷新刷浏览量。最简单的处理是前端在进入详情页时打一个标记，同一会话内只请求一次详情，或者后端按用户 ID 做 24 小时内的去重统计，这个按项目体量选即可。
发布页是整个系统里用户操作路径最长的一个页面，也是最容易流失的环节。我的表单包含：正文（必填）、分类（单选）、关联院校和专业（可选）。发布按钮点击后先做前端校验，正文少于 10 个字直接拦截并提示。提交成功后不要用 uni.showToast 弹一下就没下文，而是延迟 500ms 后 uni.navigateBack 回列表页，并触发列表页的 onShow 刷新，这样用户能立刻看到自己的帖子出现在列表中。
3.4 自定义导航栏与顶部高度适配
由于每个页面顶部都需要显示自定义标题和筛选按钮，我没有用原生导航栏，而是在 app.json 级别开启自定义导航，然后在每个页面自己计算导航栏高度。这个问题如果你不处理，会出现"自定义标题栏把微信胶囊按钮顶飞"的事故，不同机型上高度差异非常大。
我在 utils 里写了一个通用的导航栏高度计算函数：
// utils/nav.js export function getNavInfo() { const sys = uni.getSystemInfoSync() const menu = uni.getMenuButtonBoundingClientRect() // 状态栏高度即电池栏区域高度 const statusBarHeight = sys.statusBarHeight // 胶囊按钮与状态栏之间的间距，乘 2 加上胶囊自身高度，就是导航栏高度 const navBarHeight = (menu.top - statusBarHeight) * 2 + menu.height return { statusBarHeight, navBarHeight, menuRight: menu.right } }这个函数的原理是：微信胶囊按钮在垂直方向居中于导航栏，所以通过胶囊按钮的 top 减去状态栏高度，得到的是"胶囊上方到状态栏的距离"，这个距离的两倍加胶囊高度，就是导航栏总高度。实测在 iPhone 和 Android 主流机型上这个算法误差基本为零。拿到高度后，导航栏容器设置 padding-top 为状态栏高度，内部内容高度设为 navBarHeight，再把右上角空出胶囊按钮的宽度区域即可。
还有一个细节：自定义导航栏条件下，页面滚动时如果想要导航栏背景色从透明渐变到实色，需要监听 onPageScroll 事件，按滚动距离动态修改容器样式。这个效果做出来很加分，但要注意 scroll 事件频率很高，必须做节流，否则低端机会卡顿。
4. 打包发布与线上常见问题排查
4.1 包体积超限怎么压：从 2.6MB 到 1.8MB 的实操
第一次打包上传微信开发者工具，我收到的报错是 source size 2612kb exceed max limit 2mb。这是新手必踩的经典问题：微信小程序主包编译后不能超过 2MB，uni-app 项目里如果所有页面、组件、图片、静态资源全塞在主包里，随便加点东西就爆了。我的处理办法按优先级排：
第一步是开分包。pages.json 里把不常用的页面放进 subPackages，比如资料详情页、用户主页、关于页面。分包后的原则是：主包只留 TabBar 对应的页面和公共组件，其他全部分到分包里。微信支持主包 2MB、单个分包 2MB、总包 20MB 的容量限制，像这个系统把详情页和发布页拆出去后，主包体积直接从 2.6MB 掉到 1.6MB，效果立竿见影。
第二步是压缩静态资源和公共库。项目里的图标都用 iconfont 的字体文件，不要塞多个 PNG；图片全部上传到图床或对象存储，代码里只留 URL。第三步是检查第三方组件库，这个项目里我引入了一个富文本解析组件，最后发现只有详情页用得到，果断改成按需引用，又省了 200 多 KB。
第四步容易被忽略：删除无用的注释和 console.log。uni-app 编译时默认不会 strip 掉 console.log，而调试阶段打上一堆日志的人不在少数，这些全算进包体积。我是在正式发布前全局搜索 console.log 清理一遍，同时把生产环境的日志开关设为全局变量控制，而不是一行行删。如果你用 vue-cli 创建工程，还可以在 webpack 配置里加 UglifyJsPlugin 的 drop_console 参数做自动剔除。
分包还有一个附带好处：小程序加载首屏时只下载主包资源，分包页面按需加载，首屏速度会明显变快。所以包体积问题不只是为了过审核，它对真实用户体验也有实质提升。
4.2 合法域名、类目与审核：上线前必须过的那几关
微信小程序正式上线有三道关：合法域名校验、类目资质审核、体验版转正式版。这三关每一关都能卡住项目三五天。
合法域名校验是最先碰到的。小程序所有网络请求的域名必须配置在微信公众平台的"服务器域名"白名单里，必须是 HTTPS，而且域名不能是 IP 地址和 localhost。开发阶段可以在开发者工具里勾选"不校验合法域名"，但体验版和正式版一定要在后台配置。我的教训是：域名最好在项目一开始就定好并完成备案，别等开发完了再临时换，否则所有写死的 baseURL 都要改一遍。
小程序类目问题更关键。微信对"社交"类目审核极其严格，个人主体基本拿不到带用户发帖功能的社交类目权限，即使拿到了也要额外的资质。我做校园项目用的是学校主体注册的小程序，类目选的是"教育 - 教育信息服务"，发帖评论这些社区功能在审核时才能说得通。如果你的小程序挂在个人主体下想上线论坛功能，基本会被驳回，除非把发帖改成"咨询提交"或"报名表单"这种弱社区形式。
另外小程序认证有个年费制度，教育类目一般按年度审核收取费用，这笔钱在项目立项时就该预算进去。很多人卡在最后一步：代码写好、功能正常，结果因为没交认证费用无法发布正式版，那种感觉比写代码遇到 bug 还难受。
调试接口还有一个好用的工具就是 Charles。微信开发者工具本身能看到小程序请求，但真机调试时想抓 HTTPS 包就得靠 Charles 配 SSL 代理。我在排查一个安卓机型上接口偶发超时问题时，就是用 Charles 抓包发现是服务端响应时间超过 10 秒，被小程序默认超时拦截了。这类问题不看抓包数据根本定位不出来。
4.3 高频报错速查表
我把这个项目开发期间遇到的高频报错整理成一个速查表，每个问题基本都带坑，遇到时可以按表排查。
| 报错现象 | 可能原因 | 解决办法 |
|---|---|---|
| source size exceed max limit 2mb | 主包体积超限 | 开分包、压缩图片、移除无用组件和日志 |
| request: url not in domain list | 请求域名未配置白名单 | 公众平台后台添加服务器域名，必须 HTTPS |
| login 返回 errcode 10002 | 登录参数或网络链路异常 | 检查 code 是否被重复消费、超时时间是否过短 |
| getPhoneNumber 返回 errCode 30001 | 当前小程序没有该组件权限或类目不符 | 检查主体资质和类目，确认是当前环境支持 |
| uni.request 一直返回 fail | 域名证书过期或代理干扰 | 检查证书有效期，用开发者工具"忽略域名校验"定位 |
| 自定义导航栏位置错乱 | 未适配胶囊按钮位置 | 用 getMenuButtonBoundingClientRect 计算高度 |
| 帖子列表图片加载缓慢 | 图片未压缩且未走 CDN | 上传前压缩，对象存储开 CDN 加速 |
这里重点解释一下 10002 这个错误，它往往不是单一原因。我遇到过的实际场景是：测试手机和 Charles 模拟器同时跑，导致请求走了代理链路，sesstion 状态错乱。后来把模拟器代理关掉，只保留真机调试才恢复。遇到 10002 先别急着查代码，先问一句"是不是开了代理或走了特殊网络"，往往能省半小时。
5. 运营层面的经验与后续扩展
5.1 社区内容治理：考研论坛最怕的不是没人发帖
论坛产品一旦有了流量，最先失控的往往不是服务器，而是内容质量。考研论坛的典型内容是高度垂直的干货经验，如果首页被广告帖、兼职帖、"加微信领资料"的软文刷屏，核心用户一次失望就不会再来第二次。
我的内容治理分三层。第一层是发帖前的敏感词拦截：后端维护一个 banned_words 表，用户提交时逐词匹配，命中直接拒绝并提示"内容包含违规词"。第二层是新帖审核池：前 30 天运营期，所有新帖子先进入待审核状态，管理员在后台一键通过。等社区形成互相信任的氛围后，再放开新用户发帖白名单机制。第三层是用户举报：帖子详情页挂一个"举报"入口，举报信息写进后台日志表，管理员处理。
内容治理的关键不只是"拦截"，还要留出申诉通道。我遇到过有同学分享的笔记里包含了一些平台识别为营销词汇的字段，被自动拦截后直接投诉。后来我在拦截提示语里加了"如系统误判请联系管理员邮箱"，并且把管理员邮箱写在校验失败的返回信息里，这个体验细节很重要，能让用户觉得系统有温度而不是冷冰冰的一刀切。
5.2 冷启动与拉新的一些土办法
技术做完了，最现实的问题是没人用。这类校园项目没有大预算投广告，我采用的方法是"先找 50 个种子用户"：把系统先给学院的学生会和各班级群体验，找十几位上一届已经上岸的学长学姐发第一批高质量经验贴，然后在新生群、考研群里做小范围转发。
这些动作看起来和代码无关，但对项目的长期价值影响巨大。小程序是"用完即走"的产品形态，留存靠的是"这里能找到别人找不到的东西"这个心智。所以我在首页信息流固定展示"本周精华"和"上岸经验Top榜"，由管理员手动置顶优质帖子。实测这样做之后，日活用户回访率比纯时间流排序高了大概三成，因为用户知道每周都有人维护、都有值得看的内容。
5.3 这套工程还能往哪扩展
如果后续想继续迭代，这个系统的扩展空间很大。方向上我可以给几个经过思考的建议：一是接入院校库 API，把分数线、报录比、专业目录做成结构化数据展示，替代人工维护；二是做研友匹配的智能推荐，基于 users 表里的 target_school 字段做算法匹配，这是这个项目最有区分度的功能；三是加一个打卡模块，配合微信订阅消息提醒用户每日学习打卡，打开率会比普通推送高很多；四是可以考虑把 uni-app 编译出的 Android App 上架应用市场，同时做好热更新和后台定位打卡这类扩展能力，不过这些属于产品化和商业化阶段的内容，现阶段先把小程序打磨扎实才是正道。
整个项目从前期的需求梳理到最后的审核上线，我最深的体会是：技术选型和代码实现只占 60% 的工作量，剩下 40% 在"理解平台规则"和"运营设计"上。微信小程序是一个强平台约束的环境，你的每一个功能设计都要先问一句"这个在微信的规则下能不能跑、会不会被封、体验顺不顺"。把这些问题想在前面的项目，开发到最后阶段往往顺风顺水；等代码写完了才意识到平台不允许，返工成本真的很痛。
最后分享一个小技巧：如果你也是第一次做 Python 后端和小程序前端的配合，一定先从前端把接口契约定死，再写后端代码。我一开始是先写后端再写前端，结果两边字段命名对不上，联调时改了一个下午。后来改成先写一个文档类文件把接口字段列出来，两边照着写，之后所有接口几乎都是一次联调通过。这个习惯我后来做所有项目都保留了下来，省掉的时间远比写文档的时间多。
