考研这仗一半是复习另一半是信息战。每年那么多考生找真题、求经验贴、问专业方向信息全散在QQ群和贴吧里不是被广告刷屏就是被旧帖子误导。我前阵子给学校做了一套校园考研论坛交流系统技术路线就是标题里那三样Python 搭后端接口、uni-app 写前端框架、最后编译成微信小程序发布上线。整套做下来最大感触是论坛类项目看着简单真正落地时微信登录闭环、社区内容治理、小程序包体积控制这三块才是耗时间的重头戏任何一个都能让你从下午折腾到凌晨。这篇文章适合三类人一是计算机相关专业准备拿项目做毕设或课设的同学二是想给学校、学院搭一个内部交流工具的学生开发者三是对 Python 后端和 uni-app 跨端开发的协作方式感兴趣、想跑通全链路的人。我会把需求拆解、数据库设计、微信登录流程、uniapp 页面搭建、打包上线排坑一条线讲完代码和配置都是可以直接抄的级别但更重要的是我会说明每一步为什么这么选避免你做完项目答辩时被问住。1. 需求拆解与技术选型校园考研论坛到底该怎么做1.1 先别急着写代码把场景和功能盘清楚校园考研论坛和普通社交论坛有一个本质区别用户带着非常明确的阶段性目标进来要么是找目标院校的信息要么是找同路人要么是分享刚踩完的坑。需求高度垂直所以功能设计不能照着贴吧抄。我做需求梳理时把用户分成了三类已经上岸的学长学姐、正在备考的在校生、准备考研但还在选学校的大三学生。三类人的诉求分别是分享与获得认可获取资料与答疑消除信息差。基于这个核心功能定为五个模块资料库按学校、专业、科目分类的真题和笔记上传下载经验贴考研上岸经验分享支持按年份、院校筛选问答区专业课问题、复习规划问题互答类似轻量版知乎研友匹配按目标院校和专业维度找研友组队打卡院校信息分数线、报录比、考试科目等基础数据展示这五个模块不需要做成大而全的 CMSMVP 阶段只需要保证信息能发布、能分类、能检索、能互动。我在初版里砍掉了私信功能因为小程序的消息推送机制做站内信成本不低而且研友之间完全可以通过帖子评论区互留联系方式先把最小闭环跑通比什么都强。论坛类产品最忌讳的是功能堆砌但没人用。所以我在设计时反复强调一个原则发帖路径要短信息沉淀要有价值。资料库上传、经验贴发布、问答提问这三个动作全部控制在三次点击以内完成这直接影响后期冷启动的用户留存。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 用字符串还是用数字枚举我建议直接用字符串experiencequestionmaterialteam可读性强前端拿到也不用再做一层映射。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, paramsparams, timeout5).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 明文塞进 JWTopenid 属于敏感信息泄露出去虽然不至于直接被盗号但会让人拿去撞库匹配微信生态内的其他服务。JWT 的过期时间我设置成 7 天小程序端每次启动时做一次静默登录刷新 token体验上用户永远感觉不到登录的存在。2.3 RESTful API 清单前后端接口是怎么对齐的接口设计遵循一个原则资源名词复数 HTTP 方法表达动作不做 RPC 式接口。这个项目对外暴露的核心接口如下方法路径功能说明POST/api/auth/login微信登录换 token传 code返回 JWTGET/api/users/me获取当前用户信息header 带 tokenPUT/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 封装里只判断 codeHTTP 状态码只用来区分网络层错误这样前后端调错的边界非常清晰。我在实际开发中特意加了统一的异常处理装饰器。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-typechooseAvatar昵称用 input 组件的 typenickname由用户在页面上主动选择填写。手机号获取也有新老之分。老方案是 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。这是新手必踩的经典问题微信小程序主包编译后不能超过 2MBuni-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请求域名未配置白名单公众平台后台添加服务器域名必须 HTTPSlogin 返回 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 后端和小程序前端的配合一定先从前端把接口契约定死再写后端代码。我一开始是先写后端再写前端结果两边字段命名对不上联调时改了一个下午。后来改成先写一个文档类文件把接口字段列出来两边照着写之后所有接口几乎都是一次联调通过。这个习惯我后来做所有项目都保留了下来省掉的时间远比写文档的时间多。