严Phy1. 项目拆解：看似三个功能，其实是一套用户闭环
“php基于微信小程序的学习交流论坛考试平台”这个标题，我第一次看到的时候并不觉得复杂，但真正动手拆过之后才发现，这里面其实藏着一套完整的用户闭环：PHP负责后台数据和业务逻辑，微信小程序负责用户触达和操作入口，论坛是日常交流场景，考试是学习效果的检验场景。把这几个点串起来，才是一个能长期跑下去的平台，而不是三个互不相干的功能页拼在一起。
这种项目最常见的使用场景有两个：一个是高校里的毕业设计或课程设计，另一个是公司或技术社群的内部学习考核系统。前者看重功能的完整度和演示效果，后者看重真实可用性、数据隔离和后续维护。不管哪一种，核心需求都是相通的：用户进入小程序后能注册登录、浏览板块、发帖回帖、点赞收藏，同时还能参加一场限时考试，交卷后立刻看到成绩和错题记录。管理端则需要维护用户、内容分类、题库、试卷和成绩统计。
所以在动工之前，我建议先把“到底要解决谁的问题”写在纸上。如果目标用户是学生，那错题回顾和章节练习比社区排名更重要；如果目标用户是企业内部员工，那考试防作弊和成绩导出又比发帖的UI更值得投入。项目标题里的“学习交流论坛”很容易让人把重头戏放在论坛上，但从实际使用角度看，考试模块才是能产生“数据价值”的部分，论坛则是用来维持用户活跃的辅助场景。
1.1 论坛和考试为什么能放在同一个平台
从产品逻辑上看，论坛负责“学习过程中的交流”，考试负责“学习结果的检验”。用户在论坛上提出问题、分享笔记，管理员把这些内容沉淀下来，整理成题库里的知识点题目，再通过考试让用户检验自己的掌握程度。两者互相补充，形成一个可以循环使用的学习闭环。技术上更是顺理成章，因为两个模块共用同一套用户表、同一套登录逻辑、同一套图片上传服务，只要后端把用户权限分层处理好，就不会出现“论坛有一套账号，考试又要重新注册一次”的尴尬。
很多初学者会把论坛和考试当成两个独立的系统分开开发，最后再用一个导航栏强行拼在一起。这样做不是不行，但你会遇到一个很麻烦的问题：用户积分、学习记录、错题本这些跨模块数据，到底该放在哪一边？所以更合理的做法是在数据库设计阶段就确认，用户是平台的唯一主体，论坛和考试都只是围绕用户展开的子模块，而不是平级的两套独立系统。这个认知直接决定了最终代码的可维护性。
1.2 小程序的定位：不是把一个网页塞进去
微信小程序端的交互习惯和后台管理端完全不一样。通常后台管理页面是“列表 + 表单”，但小程序端要讲究“短路径完成任务”。以考试为例，用户可能是在公交上收到一条“今日还有一次模拟考试”的提醒，点进去就想马上答题，而不是先看三屏考试规则。所以小程序的首页要把“今日考试入口”“最新帖子”“我的错题数”这些高频动作提出来，而不是放一张漂亮的轮播图占满首屏。
论坛在小程序里也要控制展示密度。手机屏幕本身只能显示四五百字的可读内容，如果像传统PC论坛那样把二楼、三楼全部展示出来，页面会非常长，用户浏览体验会变得很差。我的做法是在小程序列表页只显示标题、摘要和几张缩略图，进入详情后再逐条加载楼层评论。这样既能保证页面流畅，也能让接口压力小很多。
1.3 开发前先想清楚的三件事
第一，有没有现成用户体系。如果项目只是演示，可以直接用微信登录换取的用户身份，后台默认给一个普通用户角色。如果要区分管理员、教师、学生，那就需要在用户表里加入角色字段，并在后端接口做权限拦截。
第二，考试是一次性完整交卷，还是逐题实时保存。很多毕设项目一开始都做成“用户点交卷后一次性提交全部答案”，但真实场景里网络抖动很常见。我建议至少做到本地存草稿、交卷时合并提交，或者后端提供“暂停答题”接口。
第三，内容审核有没有人做。论坛开放注册后一定会出现广告和恶意内容，如果完全没有过滤和举报机制，项目将来很难真正上线。哪怕只是做一个简单的关键词替换和“管理员后台删帖”功能，也能让系统看起来可信很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据表与接口设计，先把地基铺好
我在做这种中大型小程序项目时最怕的不是功能多，而是功能做多了以后表结构改不动。微信小程序端一旦发布，用户数据就已经开始产生，如果初期表设计不合理，后续重构的成本非常高。因此数据库设计阶段宁可多花两天，也不要急着写接口。
2.1 统一接口响应格式
前后端分离是这类项目的标准做法。小程序通过请求PHP接口获取JSON数据，PHP不直接渲染HTML模板。为了减少小程序端的判断代码，所有接口可以统一使用下面的返回结构：
json复制{
"code": 0,
"message": "success",
"data": {}
}
这里的 code 表示业务状态码，0代表成功，非0代表失败；message 是给用户看的提示信息；data 是真正的业务数据。登录失效时统一返回 code 为 401，小程序端在请求封装里拦截这个状态码并跳转登录页，比每个页面自己判断要省事得多。
我在实践里会把小程序端的请求方法抽成一个公共模块，例如 request.js，所有页面调用同一个 request.get('/posts', params)。这样如果以后要给接口签名、加时间戳或者统一打印日志，只需要改一个文件就够了。这里有一个容易被忽略的细节：PHP接口返回的字符集要统一用 UTF-8，并且 Content-Type 不要写成 text/html，否则小程序拿到的数据偶尔会被浏览器解析器干扰。
2.2 用户与论坛模块的表结构
用户表是整个系统的核心，微信小程序的用户身份主要靠 openid 区分。openid 是一个用户在某个小程序下的唯一标识，同一个微信用户在另一款小程序里openid也会不同。设计用户表时可以把 openid 设置成唯一索引：
sql复制CREATE TABLE `users` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`openid` varchar(64) NOT NULL DEFAULT '' COMMENT '微信小程序用户唯一标识',
`nickname` varchar(64) NOT NULL DEFAULT '' COMMENT '昵称',
`avatar_url` varchar(255) NOT NULL DEFAULT '' COMMENT '头像地址',
`role` tinyint(4) NOT NULL DEFAULT 0 COMMENT '0普通用户 1管理员',
`status` tinyint(4) NOT NULL DEFAULT 1 COMMENT '账号状态',
`created_at` int(11) NOT NULL DEFAULT 0,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_openid` (`openid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
论坛模块离不开分类、帖子、评论这三张表。分类表可以手动维护，结构比较简单，主要字段是父级分类ID、分类名称、排序值。帖子表则要注意几个“冗余计数”字段，比如浏览量、点赞数、回复数。这里有人会疑惑，数量为什么不用 count 去实时查？因为列表页请求量大，每次 count 都要扫描大量记录，冗余计数配合后台定时刷新是一个很常见的工程方案。当然冗余字段需要保证更新逻辑完整，点赞或删帖时同时更新帖子表里的数字。
2.3 题库、试卷、作答的三张核心表
考试模块相对论坛更独立。题库表存储每一道题目的题干、选项、正确答案和所属分类；试卷表定义一次考试包含哪些题目、总分多少、考试时长多少；作答表记录某位用户参与某张试卷后提交的答案和最终成绩。
我推荐的最小表结构长这样：
sql复制CREATE TABLE `questions` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`category_id` int(11) NOT NULL DEFAULT 0 COMMENT '题目分类',
`type` tinyint(4) NOT NULL DEFAULT 1 COMMENT '1单选 2多选 3判断 4简答',
`content` text NOT NULL COMMENT '题干',
`options` text COMMENT '选项JSON',
`answer` varchar(1000) NOT NULL DEFAULT '' COMMENT '正确答案',
`score` int(11) NOT NULL DEFAULT 0 COMMENT '每题分值',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
题目类型不同，options 字段的含义也不同。单选题直接存 A、B、C、D 的选项列表；判断题可以把选项固定为“正确/错误”；简答题则不需要 options，但正确答案会是一段文本。很多实战项目会把答案直接暴露在接口里，这在演示阶段无所谓，但正式项目中一定要注意：查询题目列表时不要返回 answer 字段，只有用户交卷后后台比对完才可以返回正确答案和解析。否则用户打开小程序调试接口就能把后台答案全部拖走。
3. 小程序端高频功能实操：从自定义导航到组件踩坑
小程序端看起来只是套了一个微信壳，但真正写起来有很多平台特有的细节。很多问题在开发者工具里一切正常，到了真机就出怪事。下面这几个功能点是我实际开发中踩过一遍后沉淀下来的经验，基本覆盖学习交流论坛考试平台的高频入口。
3.1 微信登录与token，别把核心逻辑做成死循环
微信小程序的登录推荐流程是：客户端调用 wx.login() 拿一个临时的 code，然后把 code 发给后端PHP接口，后端拿这个 code 去微信接口换 openid 和 session_key。得到 openid 后，先查数据库，用户不存在就自动创建，然后后端自己生成一个 token 返回给小程序端。小程序端把 token 存到本地缓存，后续每个需要登录的接口请求都带上这个 token。
js复制wx.login({
success: async (res) => {
const response = await request.post('/api/login', { code: res.code });
if (response.code === 0) {
wx.setStorageSync('token', response.data.token);
wx.setStorageSync('userInfo', response.data.userInfo);
}
}
});
很多新手会问：我已经有 openid 了，为什么还要再造一个 token？因为用户后期会修改昵称、头像、角色，如果每次请求都拿 openid 去数据库查，当然也可以，但openid属于敏感身份标识，在接口里高频传递容易泄露。自定义 token 加过期时间，不仅方便做服务端登录状态管理，也便于加权限控制。PHP端生成 token 可以用 bin2hex(random_bytes(32))，不要用简单的MD5拼接，因为碰撞和猜测成本不可控。
3.2 自定义导航栏：状态栏高度怎么算
热搜里经常出现“微信小程序自定义标题上边距怎么弄”，这个问题我自己第一次做时也栽过。因为默认导航栏只能显示一个标题，如果你想在标题右边放一个“发帖”按钮，或者在导航栏区域放搜索框，就必须改成自定义导航栏。自定义导航栏后，顶部状态栏高度不能写死，尤其是 iPhone 的刘海屏和安卓挖孔屏差异很大。
正确做法是同时读取系统状态栏高度和胶囊按钮位置：
js复制const windowInfo = wx.getWindowInfo();
const menuButton = wx.getMenuButtonBoundingClientRect();
const statusBarHeight = windowInfo.statusBarHeight;
const navBarHeight = (menuButton.top - statusBarHeight) * 2 + menuButton.height;
statusBarHeight 是微信小程序顶部状态栏的高度，胶囊按钮是右上角圆形按钮。传统导航栏的总高度等于状态栏高度加上胶囊按钮区域高度。拿到这两个值后，在自定义导航组件的根节点上动态绑定内联样式，再给页面主体内容预留相同的高度作为占位。很多页面内容被遮挡的问题，其实不是 padding-top 没写，而是没有预留导航栏的整体高度，只处理了状态栏高度。
3.3 自定义tabBar方案的取舍
论坛首页、考试大厅、个人中心、消息页，如果只配四个一级页面，可以直接用微信自带的 tabBar，简单稳定。但如果想要中间凸起一个“发帖”按钮，或者想做带有角标的动态消息提示图标，原生 tabBar 就不够用了。
官方推荐的自定义 tabBar 方案是在 app.json 里把 tabBar.custom 设为 true，然后在项目根目录建一个 custom-tab-bar 文件夹，组件结构是一个 cover-view 或普通 view 编写的底部导航。切换页面时仍然要用 wx.switchTab，否则带有自定义 tabBar 的页面不会正常联动。点击不同的 tab 后，组件里要维护一个 selected 状态，并在每个 tab 页面的 onShow 生命周期里调用 this.getTabBar().setData({ selected: index })。
我实际用下来还算稳定，但也有必须注意的地方：自定义 tabBar 组件如果需要读取未读消息数，最好在组件自身 show 时请求，不要放到每个 tab 页去请求。另外，如果使用类似 uni-app 这类跨端框架，自定义 tabBar 在微信小程序里也有自己的配置规则，复制粘贴网页代码前先确认框架版本。
3.4 iOS 里 swiper 嵌套 video 错位问题
现在论坛详情页经常会有视频帖子，很多开发者喜欢把多张视频卡片放在一个 swiper 里左右滑动。这样做在安卓上大概率没问题，但在 iOS 上偶尔会出现 video 进入全屏播放后退出，页面内容错位、视频画面变形甚至视频消失的怪现象。
最根本的原因是 iOS 上 video 组件是原生组件，和普通 view 的渲染层级不同，在容器带 transform 或 swiper 内部的层级状态下，全屏返回后原生组件的位置不能及时同步。我最终的解决方案是：不要在 swiper 里同时创建多个 video，而是通过 current 字段判断当前处于哪一页，只渲染当前页的 video，其他页使用 poster 图片；视频全屏退出后，强制调用 wx.pageScrollTo 或重置 video 所在容器的 transform: translateZ(0)，让原生组件重新排版一次。
另外，给 video 绑定 bindfullscreenchange 很关键。进入全屏时手动暂停背景音乐或视频列表里的其他播放器，退出全屏时再恢复。如果项目中不需要左右滑动切换多条视频，我建议改用列表形式铺开，每个 video 独立存在，不要硬塞进 swiper，从根源上避开这个坑。
3.5 订阅消息、打开其他小程序、天气接口的接入要点
考试平台通常会有一个“开考提醒”功能，让用户点击订阅后，在开考前收到微信的订阅消息。小程序端的调用很简单：
js复制wx.requestSubscribeMessage({
tmplIds: ['模板ID'],
success(res) {
// 返回 'accept' 表示用户允许
}
})
但要注意，微信的订阅消息是一次性订阅，用户点一次只能接收一条。如果你希望每周都推考试通知，就需要在按钮组件上引导用户每次点击“订阅”，不能试图用技术绕过限制。
小程序跳转另一个小程序则调用 wx.navigateToMiniProgram，但前提是双方需要在微信公众平台的“跳转小程序”配置里互相添加AppID。不是代码写完就能跳，页面会提示“无权限跳转”。如果只是跳转后带一个参数，直接放在 path 后面即可。
如果你在小程序里集成“和风天气”这类第三方接口来展示学习打卡区域的天气，最稳妥的办法是后端PHP去请求天气API，再由PHP转发给小程序。千万不要在小程序代码里直接写天气API的密钥，因为小程序代码包被下载后是明文存在的。后端转发还可以把返回字段裁剪成前端真正需要的小型JSON，节省流量和渲染时间。
4. 后端业务实现：发帖、组卷、自动评分
后端PHP的业务代码虽然看起来都是“查数据库、返回JSON”，但真正写起来有不少细节值得打磨。我下面以论坛发帖、题库组卷、自动评分三个功能为例，拆开讲一讲实现时的思路。
4.1 发帖与回帖接口，不该只做最简单的Insert
发帖接口不只是一个 insert 操作。用户提交标题和内容后，后端至少要做这几件事：过滤HTML与脚本、将连续空白符折叠、截断超长文本、提取纯文本摘要、处理图片URL、设置初始浏览量。如果平台允许匿名发帖，还要埋一层风控，防止同一个IP或同一个用户短时间内刷屏。
PHP端使用PDO预处理是对抗SQL注入的基本要求。任何用户输入拼接进SQL，都是拿整个平台在冒险。比如按分类查看帖子：
php复制$stmt = $pdo->prepare('SELECT * FROM posts WHERE category_id = ? AND status = 1 ORDER BY id DESC LIMIT ? OFFSET ?');
$stmt->execute([$categoryId, $pageSize, $offset]);
另外，用户发表的内容不要直接以HTML格式存库。在小程序端，展示内容用的是富文本组件或普通文本组件，它们对HTML标签支持有限。我习惯把发帖内容拆成“纯文本 + 图片列表”两段存储，一个字段放文字，另一个字段放JSON数组。这样在列表页可以直接显示摘要，详情页只需遍历图片列表，展示顺序也很稳定。
回帖接口要比发帖接口多做一个操作：回帖成功后更新帖子表里的 reply_count，并把 last_replied_at 改成当前时间。列表排序大多不按创建时间，而按最后回复时间更新，这样老帖被新回复顶起来的效果才能出来。这些统计字段和发帖表分布在不同的表里，但业务上必须保证一致性，建议包在一个数据库事务中处理。
4.2 题库管理和组卷逻辑，不能一上来就ORDER BY RAND
组卷是考试平台里最有技术含量的一部分。我遇到的需求通常有两类：固定试卷和随机试卷。固定试卷适合期中、期末考试，后台管理员手动选择题目并保存试卷；随机试卷适合每日练习，从某个分类的题库中随机抽若干题。
固定试卷存储时，可以给试卷表增加一个 question_ids 字段，存放题目ID的有序JSON或逗号分隔字符串。真正考试时后端一次性读出题目。随机试卷如果数据量不大，比如几百道题，用简单的 ORDER BY RAND() 也够用，但一旦题库量上万，这个查询会让MySQL性能急剧下降，尤其在高并发考试时会直接把数据库拖垮。
更合理的随机抽题方案是：先查出该分类下所有可用题目的ID，在PHP里用 array_rand 随机挑选，再通过 IN 查询题目详情。如果你还想控制题型比例，可以先按单选、多选、判断分别查ID，再按比例抽取。交卷后，系统只需要记录用户本次抽到了哪些题，后续无论怎么重新考试，都不会再次随机到相同组合。
试卷设计还要考虑分值。举个例子，考试时长30分钟，总分100分，20道单选题每题3分，10道判断题每题2分，10道多选题每题3分，正好100分。这个计算看起来简单，但后台录入题目时如果不限制分值范围，就会出现试卷总分和预期不一致的情况。所以后端在保存试卷前要做一个校验：把 question_ids 中每道题的 score 相加，不等于试卷配置总分就返回错误提示。
4.3 自动评分与人工批改的边界
自动评分主要处理客观题。单选题直接比对用户提交答案与标准答案是否一致；判断题也一样。多选题则要注意答案顺序，标准答案存成 A,C，用户提交 C,A，如果直接用字符串比较会误判，所以提交前要统一排序并拼接成固定格式，例如把 ['C','A'] 排序成 A,C 再比较。
php复制function normalizeAnswer($answer) {
$parts = str_split(strtoupper(str_replace(' ', '', $answer)));
sort($parts);
return implode('', $parts);
}
$userNorm = normalizeAnswer($userAnswer);
$stdNorm = normalizeAnswer($stdAnswer);
$isCorrect = ($userNorm === $stdNorm);
简答题不适合自动评分。我的做法是把这类题目标记为“待人工批改”。交卷后，客观题立刻出分，简答题则由管理员在小程序管理端或后台逐题批改评分。总成绩状态分为“部分已批”和“已完全批改”，等所有题目都批完后再给用户推送最终成绩。这样做的代价是逻辑复杂一点，但它符合真实考试平台的需求，用户在考完一场主观题考试后看到的不是一道毫无意义的零分，而是等待批改的真实状态。
交卷接口还有一个细节：一定要防止用户连续点两次交卷把成绩写两遍。后端可以在考试记录表里维护一个状态字段，0待考试或答题中，1已提交，2已批改。提交时先执行一条带有条件限制的更新语句：
php复制$stmt = $pdo->prepare('UPDATE exam_records SET status = 1, end_time = ? WHERE id = ? AND user_id = ? AND status = 0');
如果影响行数是0，说明本次试卷已经提交过了，直接返回原来的成绩即可。用数据库状态做幂等控制，比前端“按钮置灰”要可靠得多。
5. 部署、发布、排查问题实录
再好的代码最后也要部署到服务器，并成功跑在微信的合法域名里。这个环节踩的坑往往和业务逻辑无关，却最让人崩溃。下面这些是我在部署PHP项目和发布小程序时经常遇到的问题。
5.1 本地PHP环境的两个常见问题
很多开发者在本机配置PHP环境时会遇到一个提示：Warning: Module "mbstring" is already loaded in Unknown on line 0。这个提醒看着吓人，其实多半是php.ini里重复启用了 mbstring 扩展。例如 Apache 以模块方式加载了扩展，但 php.ini 里又写了 extension=mbstring，或者同时加载了 php_mbstring.dll 和 mbstring，最终导致重复加载。排查的方法是先执行 php --ini 找到实际加载的php.ini路径，再去phpinfo页面看加载的是哪个配置文件，把重复的行删除。处理完后重启服务即可消除该警告。
另一个高频问题是PHP版本和扩展不匹配。现在不少老代码是基于 PHP 5 写的，但新环境装了 PHP 8，很多函数行为和扩展逻辑都不一样。微信小程序接口建议使用 PHP 7.4 或 8.1 以上，同时确保安装了 pdo_mysql、openssl、fileinfo、curl 等扩展。如果项目使用 ThinkPHP 或 Laravel，可以在命令行用 php -m 检查，确保扩展已经加载。
5.2 Nginx 伪静态配置
如果使用 ThinkPHP 或者 Laravel 这类框架，接口路径通常不是真实的物理路径。比如用户访问 /api/posts，实际请求会被框架路由到公开目录下的 index.php 入口文件。在 Nginx 里就需要配置伪静态规则，让所有不存在的文件都重新交给入口文件处理。
nginx复制location / {
try_files $uri $uri/ /index.php?s=$uri;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
这里容易踩的坑是 try_files 的 $uri/ 可能会把类似 /api/posts 的路径误认为某个目录，导致404。如果出现这种问题，可以直接用：try_files $uri /index.php?s=$uri;，不判定目录，让框架接管。另外，修改Nginx配置后要执行 nginx -t 测试语法并 reload，不要直接一顿 service nginx restart，万一配置写错会造成线上短暂中断。
5.3 小程序上线前的检查清单
发布微信小程序前，要确认以下几个事项：本地开发时可以在开发者工具里勾选“不校验合法域名”，但体验版和正式版必须把接口域名配置到小程序后台的 request 合法域名中，并且协议必须是 HTTPS。如果使用了第三方图片或音视频地址，也要把它们的域名加入 downloadFile 合法域名列表。否则安卓机上打开体验版，页面数据能加载，但图片一直转圈不显示，大概率就是域名没配全。
还有一个现代微信版本越来越严的点：隐私协议。如果小程序收集用户头像昵称、位置信息或者使用相册，需要在后台“用户隐私保护指引”里完整声明，并在代码中用官方提供的隐私接口按钮去触发授权。否则上线审核时会被驳回，甚至运行时报错提示“无隐私授权”。不要等到提审时才去补，最好在开发阶段就把 wx.getUserProfile、wx.chooseMedia 等调用统一封装进一个“隐私授权确认模块”。
HBuilderX开发时修改小程序AppID也有很多人困扰。你在 manifest.json 的小程序配置里改了 appid，结果运行到微信开发者工具时还是旧ID，通常是因为开发者工具缓存了旧的编译结果。解决办法是先在微信开发者工具里面关闭当前项目，再到 HBuilderX 中重新运行到小程序模拟器，让它重新生成 project.config.json，不要只修改文件后保留工具窗口不刷新。
6. 关于这个项目，我的几条真实经验
这类“PHP + 微信小程序”的学习交流论坛考试平台，市面上虽然有不少参考代码，但真正做完一遍你会意识到，框架和语法只是表层功夫，能把用户体系、内容体系、考试体系串在一起不打架，才是后端工程师的基本盘。
6.1 优先级应该怎么排
如果拿到的需求比较模糊，我的建议是先做考试闭环，再做论坛闭环，最后补消息和数据展示。因为考试闭环是功能边界最清晰的，从题库到试卷到答题再到成绩查询，每一步都能独立测试。论坛闭环涉及的图片上传、敏感词过滤、点赞收藏状态同步，反而更容易在细节上消耗时间。先把考试做通了，项目就有了一个能验收的核心竞争力，论坛即使简化成“发帖 + 评论 + 置顶”也足够撑起交流场景。
用户在论坛和考试之间的跳转体验也很重要。帖子详情里可以把相关试题挂在文章末尾，用户看完一篇技术分享后可以顺手做两道关联题目。考试失败后，也可以把错题对应到相关讨论帖，引导用户去论坛寻找解释。这些交叉连接不需要很复杂的算法，只要在题目表里增加一个 related_post_id，就能极大提升平台的整体感。
6.2 最能提升完成度的几个细节
我做过类似项目后的感触是，真正让人感到“这平台能用了”的关键点，往往不是首页花哨的动效，而是异常状态处理到位。接口加载失败时要有重试按钮；考试中突然断网时要保存已答题目；发帖成功后要能自动回到列表页；用户删除帖子后相关评论也要同步处理。这些功能摆在产品文档里可能只有一行字，但实际实现时会消耗不少精力。
如果时间允许，建议给整个项目加一个简单的操作日志表。用户登录、发帖、修改头像、交卷、管理员删帖，都记录行为。这样出现纠纷时能追溯，也方便后期做用户活跃度统计。学习交流平台的数据最后都沉淀在帖子和错题记录里，有了这些日志，以后想扩展成积分系统或成就系统，才不会觉得无从下手。
这套方案是我在做内部学习考核项目时一步一步验证出来的。前后重构过两版，第一版死在角色权限划分不清，第二版死在考试交卷状态被重复提交。现在把这些问题都记录在这里，也算是给后来者可以拿去直接改进的铺路样式。