做这个项目的起因其实特别简单身边有不少朋友和学弟学妹在学 Python 和 C 语言但普遍存在“视频刷了不少动手一写就懵”的情况。市面上的刷题平台要么只支持单一语言要么题目对零基础不友好要么压根没有反馈机制。所以我自己动手做了一个 Python/C 语言学习辅导网站前端选了 Vue 3 这套生态后端用 Python 技术栈实现把“看知识点、做练习、在线写代码、看评测结果、讨论提问”这几个环节串成一条完整的路径。这个项目很适合课程设计、毕业设计或者作为想入门前端和后端开发的练手项目也能直接改造成公司内部的笔试平台或培训系统。项目做完后回头再看真正有价值的不在“页面多好看”而在整个学习闭环是否转得起来用户能不能从零开始跟着知识点走能不能在网页上写代码并立刻知道运行结果做错的题能不能进入错题本。这篇文章我会把思路设计、技术选型、核心模块和踩过的坑都摊开讲尽量做到能够复现。1. 需求解析与整体设计思路1.1 这个网站到底要解决什么学习问题先别急着打开 IDE 写代码把需求想清楚比什么都重要。当时我调研了一圈目标用户主要分三类刚接触编程的大学生需要 Python 和 C 语言的基础语法、练习题和错误讲解正在准备期中期末上机考试的在校生需要按照知识点拆解的题库和模拟练习作为课程设计作品时还必须有教师或管理员的视角能管理题目、查看学生学习记录。为什么不做成普通的博客加视频站因为视频的反馈链路太慢看三分钟忘了两分钟学习质量的把控全凭自觉。学习辅导网站的核心是“闭环”知识点学习、示例代码、动手练习、评测反馈、错题复习这五件事件缺一件都容易出现“眼睛会了手不会”的状态。所以在设计第一版时我就把“做题 在线评测 结果反馈”作为网站的地基。另一个容易被忽略的需求是“代码运行环境统一”。学生在自己电脑上运行 C 语言代码不同系统、不同编译器版本的差异很大。网站上提供统一评测环境以后判断结果的依据就是“程序输出是不是和标准答案完全一致”这也避免了学生在自己电脑上出现了环境问题却以为是代码问题的连锁挫败感。1.2 为什么技术栈选择 Python 后端 Vue 前端这套技术搭配放在今天已经算是比较成熟的学习型全栈组合。后端的每个模块都围绕 Python 生态来设计后端组件用途选择理由FastAPI提供 REST API自带 OpenAPI 文档写接口联调时能省很多事类型提示对课程设计也很友好SQLAlchemyORM 数据访问设计表结构后直接用 Python 操作数据库方便后续迁移UvicornASGI 服务器FastAPI 的标准搭配调试和部署都稳定Docker SDK / 子进程调用在线代码评测利用 Docker 做隔离保证用户代码不会影响主服务为什么不用 Node.js 或 Spring Boot一方面因为这个网站的代码评测功能天然需要和 Python 生态打交道后面如果给学生做“爬虫入门”“量化策略小项目”这类专题后端可以用 Python 直接调用和演示另一方面 Python 在课程设计场景里代码量更少、可解释性更强答辩的时候好讲通透。前端选择 Vue 则是因为 Vue 的中文资料、社区生态和上手难度都很适合学习型项目。Vue 3 的 Composition API 配合script setup写业务界面非常顺手需要做题目列表、代码编辑器、提交记录列表这类交互组件时可以拆得很干净。脚手架用 Vite 而不是 Vue CLI构建速度快很多而且插件的安装方式也简单。我不想刻意追逐新框架但 Vue 3 的生态已经足够成熟。配合 Vue Router 做路由、Pinia 做状态管理、Axios 做请求这套东西在真实项目中非常常见做完以后学到的技能也能迁移到实习和工作中。1.3 第一版功能边界怎么划分做项目最怕“什么都想要”。我第一版锁定的功能是这样几条基线用户注册登录、JWT 鉴权、学生与教师两种基础角色知识点目录与课程内容展示支持 Markdown 渲染Python 和 C 语言分学科题库题目支持单选、判断、编程题网页代码编辑器支持 Python 和 C 语言提交在线评测沙箱反馈 AC、WA、TLE、RE 等状态提交记录、排行榜、错题收藏、简单问答讨论区管理后台题目管理、学生提交查看、基础统计。那些一听就很诱人但会拖慢进度的功能比如实时聊天、个性化 AI 出题、APP 端等全部留到二期。不是说这些不重要而是第一版必须保证核心链路能完整走通。范围控制是这个项目里我认为最值得分享的一点先做一个能用的闭环再考虑让体验变高级。2. 系统架构与核心功能模块拆解2.1 前后端分离与评测服务的边界整个系统的部署结构大致上可以分成三层浏览器端 Vue 应用、后端 API 服务、评测执行服务。前端只负责渲染和交互后端负责业务逻辑、数据库读写、权限校验评测执行服务则是业务服务通过 Docker 隔离用户代码后独立运行的。这个边界划分有个现实原因不能把用户提交的代码直接扔进后端进程里跑。C 语言的程序理论上可以调用系统函数Python 代码虽然没那么危险但也可能写出占用无限内存的死循环。评测服务和主服务隔离以后就算用户代码把评测容器跑崩了主站的注册登录和题库浏览也不受影响本质上是把“不可信代码”和“可信服务”隔离开了。我当时是在一台普通 Linux 服务器上部署的评测模块直接用 Docker 命令创建一次性容器容器内挂载学生代码目录。更大型的平台会用 Kubernetes 管理评测 Pod但这个量级用 Docker 就够。通过 Docker 的--rm参数容器运行完自动删除不会堆积垃圾容器。2.2 功能模块地图与关键说明先把模块的大致职责整理成一张表模块关键功能数据载体用户中心注册、登录、个人资料、角色权限MySQL 用户表、Redis Session 可选项课程中心知识点章节、文章内容、Markdown 渲染章节表、文章表题库中心选择题、判断题、编程题支持标签和难度筛选题目表、标签表、题目-标签关联表在线做题代码编辑器、Python/C 语言切换、提交提交记录表、用户-题目状态表评测服务编译执行用户代码、比对输出独立服务核心为 Docker 容器讨论社区发布问题、回复、按题目标签检索问题表、回复表管理后台题目管理、用户管理、统计数据查看依赖上面所有表题目表的设计在这里多说几句。编程题一定要和选择题分开存表面上都是“题”但字段差别很大。编程题需要存样例输入、样例输出、评测输入、评测输出、时间限制、内存限制、题目难度、关联的知识点标签选择题只需要题干、选项和正确答案。所以题库层面我用“基础题目表 扩展类型表”的方式而不是把所有字段塞进一张大表。如果做单体小项目一张表硬撑也行可后面维护会越来越难受。评测部分的抽象也要提前做好。后端不能直接写死“只支持 Python 3”而是设计成每种语言对应一个提交配置比如python3对应镜像python:3.11-slimc对应镜像gcc:12扩展名、编译命令、执行命令都从配置读取。这样后面再加 Go、Java 时只是新增一个配置模块而不是把提交逻辑再复制一份。2.3 数据模型设计的一个小思考很多课设项目的数据库表设计是“想到哪写到哪”。我这次尝试换了一种思路先画核心状态流转。用户的做题状态是一个状态机未开始 - 开始做题 - 已提交 - 评测中 - 通过 / 未通过所以除了题目表和用户表还要有一张user_problem_status表里面保存用户卡在哪道题、最近一次提交是否正确提交记录表submissions则记录每一次答题的代码快照、语言类型、评测状态和消耗时间。状态表负责“当前进度”提交表负责“历史过程”两个层次分开以后个人中心展示“继续学习”还是“查看历史”都非常直接。还有一点很实用题目与知识点之间用多对多关系通过中间表关联。当学生在 C 语言“指针”章节学完以后系统可以把所有打了“指针”标签的题筛出来形成章节练习卷。这样的设计让“课程学习”和“题库刷题”两个模块不孤立学习路径才真正成立。3. 前端 Vue 部分的工程化落地3.1 前端工程初始化与依赖安装细节前端部分我选用 Vite 来创建 Vue 3 项目记得初始化时 Node.js 版本别太老我用的是 18否则依赖安装会出一堆莫名其妙的兼容性报错。npm create vuelatest这个命令会生成一个带 TypeScript 选项的项目模板。对于只想快速做课设的同学我建议直接选 JavaScript 而不是 TypeScript不然前期类型定义的时间会占掉不少开发周期。如果你的项目想长期维护或团队成员比较多再考虑 TS。初始化后需要安装的依赖比较固定npm install vue-router4 pinia axios npm install codemirror/lang-python codemirror/lang-cpp codemirror npm install marked dompurify npm install hls.js这里重点是代码编辑器选型。CodeMirror 6 是现在比较省心的方案支持语法高亮、行号、自动缩进。通过codemirror/lang-python和codemirror/lang-cpp就能覆盖 Python 和 C 语言的编辑需求。如果你的网站还涉及 markdown 渲染题目信息一定要用 DOMPurify 清洗 Markdown 转换后的 HTML避免用户在题解区输入恶意脚本。在仓库里我习惯把目录结构固定成这样src/ api/ # axios 封装和接口模块 assets/ # 静态资源 components/ # 全局公共组件 router/ # 路由配置文件 stores/ # Pinia 状态管理 views/ # 页面级组件3.2 路由规划与权限控制Vue Router 在项目里的作用不只是页面跳转还承担了“路由守卫”的职责。访客、普通学生、教师和管理员能看到的菜单不同但不能只靠菜单隐藏做安全控制前端路由守卫只是一道体验层真正的权限校验必须放后端。路由规划大致这样const routes [ { path: /, component: HomeView }, { path: /learn, component: LearnView }, { path: /problem/list, component: ProblemListView }, { path: /problem/:id, component: ProblemDetailView }, { path: /submission/:submissionId, component: SubmissionResultView }, { path: /discuss, component: DiscussListView }, { path: /admin, component: AdminLayout, meta: { requiresAuth: true, roles: [teacher, admin] }, children: [ { path: , component: DashboardView }, { path: problem/edit/:id?, component: ProblemEditView } ] } ]路由守卫里最常踩的坑是“刷新后用户信息丢失”。如果用户信息只存在 Pinia 里刷新页面就会清空所以登录后要同步把用户基本信息存到localStorage路由守卫里先从 Pinia 取取不到再回 localStorage 恢复。3.3 代码编辑器与提交流程实现题目详情页大概分成左右两栏左边是题目描述、样例输入输出、提示右边是代码编辑器和提交按钮。用户在编辑器里选的默认语言来自题目的主要语言比如 Python 题目默认 PythonC 题目默认 C也可以手动切换。点击提交以后前端需要先校验代码是否为空然后调用后端接口把代码、语言和题目 ID 传过去。后端返回提交记录 ID 后前端进入轮询或等待状态。我一开始用setInterval每 2 秒拉一次提交状态后来发现接口请求频率太高改成每 3 秒拉一次并且页面切走时取消定时器。评测状态的界面要友好。大家平时用 LeetCode 应该都习惯“通过/不通过”的显示我在本项目中把评价状态扩展成一张完整的标签AC通过、WA答案错误、TLE超时、MLE超出内存、RE运行时错误、CE编译错误。学生看到CE时的第一反应通常是自己代码哪里写错了这时最好在下方展示编译错误信息方便定位。4. 后端核心逻辑与在线评测实现细节4.1 后端接口设计与 JWT 鉴权后端采用 FastAPI 的工程结构按模块拆目录app/ main.py # 应用入口 api/ # 路由层 models/ # SQLAlchemy 模型 schemas/ # pydantic 校验模型 services/ # 核心业务逻辑 core/ # 配置、安全依赖用户认证采用 JWT 是无状态方案登录成功后服务端返回一个 token前端以后每次请求都往 Authorization 头带上。相较于 SessionJWT 对前后端分离项目更友好。JWT 生成的核心代码不复杂但注意密钥要放在环境变量里不能写死在代码里from datetime import datetime, timedelta, timezone import jwt SECRET_KEY your-secret-key ALGORITHM HS256 ACCESS_TOKEN_EXPIRE_MINUTES 60 * 12 def create_access_token(user_id: int, role: str): expire datetime.now(timezone.utc) timedelta(minutesACCESS_TOKEN_EXPIRE_MINUTES) payload {sub: str(user_id), role: role, exp: expire} token jwt.encode(payload, SECRET_KEY, algorithmALGORITHM) return token需要注意的是 JWT 的sub字段建议传字符串不同库对 integer 类型的处理不太一样容易在解析时踩坑。用户角色校验做成一个 FastAPI 依赖这样在路由里声明dependencies[Depends(require_role(teacher))]就能保护接口。4.2 提交代码与异步评测的设计最早的版本我让提交接口同步等待评测结果一个学生写了个死循环请求直接卡死几十秒体验非常差。后来改成异步模式提交接口把提交记录写入数据库状态为PENDING然后马上把评测任务交给后台执行前端再轮询查询评测状态。这里要注意一个细节评测服务和 API 服务如果放在同一个进程里虽然代码上简单但 CPU 密集的编译工作会阻塞 FastAPI 的事件循环。更好的做法是把评测任务放到独立进程中或者用一个简单的任务队列。由于项目规模不大我用进程加队列实现效果已经足够。提交接口的代码结构可以长这样from fastapi import APIRouter, Depends, HTTPException from sqlalchemy.orm import Session router.post(/problems/{problem_id}/submissions) def create_submission(problem_id: int, payload: SubmissionIn, db: Session Depends(get_db), current_userDepends(get_current_user)): problem db.query(Problem).filter(Problem.id problem_id).first() if not problem: raise HTTPException(status_code404, detail题目不存在) submission Submission( user_idcurrent_user.id, problem_idproblem_id, codepayload.code, languagepayload.language, statusPENDING ) db.add(submission) db.commit() db.refresh(submission) # 交给评测服务 judge_service.submit( submission_idsubmission.id, languagepayload.language, codepayload.code, problem_idproblem_id ) return {submission_id: submission.id, status: PENDING}这里建议在设计表时给submissions表加一个status索引因为个人中心和题目列表都会频繁按用户和状态查询。4.3 用 Docker 搭建 C 语言与 Python 评测沙箱这是全网热搜词里被问得最多的地方也是网站最有技术含量的部分。在线评测后台不能让用户提交的代码在本机直接跑否则两个风险无法接受安全风险C 语言的system(rm -rf /)、Python 的os.remove可以直接删除服务器文件资源风险没有限制的while(1)或异常分配内存会让整台服务器卡死。所以我设计了基于 Docker 的一次性容器方案timeout 10 docker run --rm \ --network none \ --memory 128m \ --cpus 0.5 \ --pids-limit 64 \ -v /tmp/judge/{submission_id}:/workspace \ -w /workspace \ gcc:12 bash -c gcc main.c -o main -O2 -Wall -lm ./main input.txt user_output.txt参数含义做一个快速解释--rm容器退出后自动删除--network none禁止容器联网防止恶意代码外传数据--memory 128m限制容器最大内存--cpus 0.5限制 CPU 使用率--pids-limit 64限制进程数量防止 fork 炸弹-v把刚刚写好的代码目录挂载到容器里外层timeout 10兜底防止 Docker 启动卡住等意外情况。Python 语言评测基本一样的思路镜像换成python:3.11-slim执行命令换成python3 main.py。容器里不需要任何多余服务网络关闭能少掉一大批安全漏洞。评测流程细化以后是这样的后端生成以submission_id命名的临时目录将学生代码写入main.c或main.py把该题的标准输入写入input.txt运行容器编译/执行代码得到用户输出读取用户输出和标准答案输出逐字比对清理临时目录将状态写入数据库。输出比对这一块我最初使用了完全字符串相等判断结果一堆学生因为行末空格、最后一行没有换行而 WA。后来优化成了“忽略行末空白字符、忽略文件末尾空行”的宽松比较更贴合学习场景。同时保留一个严格模式开关在后面做竞赛题时再开启。4.4 评测状态与反馈信息优化评测结果不能只给一个“错误”就完事那样学生根本不知道怎么改。我在前端和后端都做了分层的反馈评测状态含义页面上额外展示内容AC通过消耗时间和内存CE编译错误展示编译器输出的完整错误信息WA答案错误展示用户输出和标准输出前 200 个字符方便对比TLE超出时间限制无额外信息MLE超出内存限制无额外信息RE运行时错误展示程序 exit code 或错误摘要从教学角度看CE 的编译信息是最有用的。比如学生写 C 代码出现了“unreferenced label”这个报错很多新人完全看不懂我就在页面错误提示下面加了简单的解释文案。unreferenced label通常就是代码里写了标签但从来没有被goto跳到虽然不影响精确编译但很多编译器给了警告如果页面不显示学生完全不知道哪里有问题。把这些细节处理好对初学者真的能带来完全不同的体验。5. 联调过程中的踩坑记录与排查方法5.1 前端多环境接口请求与跨域问题本地开发时Vue 页面跑在 5173 端口FastAPI 跑在 8000 端口浏览器直接跨域访问会被拦截。解决办法不是在 FastAPI 里盲目加CORSMiddleware允许所有来源而是通过 Vite 的 dev server 做代理让前端发请求时保持同一源。// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://127.0.0.1:8000, changeOrigin: true, } } } })前端所有请求统一走/api前缀const request axios.create({ baseURL: /api, timeout: 15000 })开发调试阶段一切正常部署到生产环境后 Nginx 也要做一次类似的代理转发location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }我建议从一开始就用统一的/api前缀避免后续部署时一个个改请求地址。跨域问题本身不难难的是一开始没规划好后面要改的牵连太多。5.2 Vue 刷新 404 与前端鉴权细节Vue Router 使用history模式时直接在浏览器地址栏访问/problem/12服务器会找不到对应文件因为请求发给了后端而非前端。开发环境没问题生产环境必须在 Nginx 配置try_fileslocation / { try_files $uri $uri/ /index.html; }还有一个容易忽略的点前端的路由守卫只是控制“显示”接口层必须也做保护。有些同学的课设前端隐藏了管理入口然后直接手动输入接口 URL 就能访问管理接口这是个漏洞。JWT 鉴权中间件必须覆盖每个非公开路由并做角色判断。5.3 m3u8 视频资源和静态资源加载问题课程章节里如果加了录播视频很多同学第一次会踩坑。我第一版直接把视频转成 mp4 扔进 static 目录后来视频文件越来越大浏览器加载非常慢后面选择将长视频切成 HLS 流前端用 hls.js 播放 m3u8 文件。Vue 中使用 hls.js 的基本流程是import Hls from hls.js function playM3u8(videoElement, url) { if (Hls.isSupported()) { const hls new Hls() hls.loadSource(url) hls.attachMedia(videoElement) hls.on(Hls.Events.MANIFEST_PARSED, () { videoElement.play() }) } }生产环境容易出现的问题是页面是 HTTPS 页面但 m3u8 分段地址写的是 HTTP浏览器会拦截掉播放器一直加载不出来。排查时先打开浏览器控制台看到 Mixed Content 就会被秒定位最好的方法是从一开始就统一使用相对地址或全链路 HTTPS。5.4 C语言题库设计中的几个高频问题题目来源和学习反馈这件事我做了一版以后才真正理解热门搜索里的那些学习难点为什么会反复出现。C 语言学得久的人会知道“字符串逆序”是 PTA 等平台的经典题。这道题看着简单但初学者会在“原地逆序、用指针还是用数组”上纠结。再比如“字符出现次数统计”这类问题许多学生到时会用if (str[i]a)判断很多次每次都要重新扫一遍字符串在真正限制时间的用例下就会超时。设计题库时要把这些经典场景纳入成不同难度的关卡不是单纯罗列一大堆题。另外我做了“文件读写操作”的专题很多学生在这块吃亏不是因为不会读文件而是没搞清楚路径问题。学生在本地跑的路径和评测容器里的工作目录不一致导致读取不到文件。后来我在题目要求的模板代码里规范了相对路径读取同时在页面上的“特别提示”区域标注“请使用相对路径如data.txt不要使用绝对路径”。这一步有效减少了无效提交的次数。评测服务里很多 C 语言的崩溃来自野指针、数组越界容器内会把程序运行错误统一标记成 RE页面提示段错误。但段错误信息太抽象了我在帮助文档里增加了常见的 RE 自查清单有没有数组下标越界有没有访问空指针有没有忘记初始化变量这样学生排查问题时才有方向。5.5 Docker 评测环境的稳定性治理评测服务上线跑了两周后遇到一个很经典的问题Docker 容器启动大约需要 1-3 秒如果有十几个学生同时提交同一时间启动十几个容器没问题但每次启动都有编译开销接口返回结果的时间会变得很慢。后来做了几个动作题库管理支持小范围预热热门题目的镜像宿主机缓存好评测服务用独立的 CPU 核心绑定不跟 API 服务抢资源一次性容器使用--network none避免对宿主机网络资源的竞争。还有一次线上事故让我印象深刻C 语言评测临时目录创建后有学生提交代码后立刻刷新页面前端轮询时读到PENDING状态于是再次点击提交产生了大量垃圾容器和临时目录。我做的处理是在提交接口里加了个简单的防抖判断同一用户对同一道题如果在 10 秒内重复提交相同代码直接拒绝并提示“已有评测中的提交”。做这种平台型项目防重复提交一定别忘了。6. 项目复盘与二次开发建议6.1 从架构角度复盘最有价值的三个决策如果重新做一次我仍然会保留三个设计决策。首先代码评测做成独立服务而不是塞进业务接口。哪怕是课设也建议学一学这种隔离思路以后面对真实比赛系统或面试笔试平台时思路是相通的。代码提交的安全风险比其他业务都高必须单独处理。其次题库的数据结构标准化。所有题目有统一 ID、难度、标签、内容类型编程题有统一的输入输出定义提交记录表、用户状态表有统一的字段命名。现在想加一个“错题本随机出题”功能几乎不用改表结构。第三个有价值的选择是按“状态”而不是按“动作”保存数据。比如用户做题状态我只关注“当前状态”而提交动作只作为历史记录存在。这样做出的个人中心会非常稳定不会因为一次接口请求失败导致进度错乱。6.2 在线代码的启发式辅导还能怎么升级学习辅导类网站比起刷题平台更强调引导而不仅仅是判断对错。项目上线后我收到最多反馈是“我 WA 了谁能告诉我思路”。因此后面可以考虑加入一个基于关键词与错误类型的提示系统当代码提交 WA 后系统根据提交代码结构、错误用例和题目标签给出提示。这里目前是规则匹配例如 C 语言题目中如果发现错误输出里多为 0 或空那么大概率是变量未初始化或数组越界可以提示学生先检查循环边界。等积累到足够的提交数据后就可以尝试用简单模型预测学生的知识薄弱点。我看到一些搜索词也很有启发比如“Python 量化交易策略代码”“免费 Python 源码大全”“爬虫入门”这类内容说明纯语法题的结果反馈并不能满足所有学习者。可以扩展出一个“项目实训库”把任务变成多步骤导学每个阶段配置一个检查脚本比如 Python 爬虫项目按“获取网页、解析数据、清洗保存”分阶段评测C 语言方向则延伸嵌入式场景的函数指针、结构体封装例子。这些扩展并不需要推翻现有的架构只需要在题目类型中扩展出一种“阶段型编程题”。6.3 最后的落地建议如果你确实想照着这个思路完整复现建议搭环境的时候按顺序做先本地启动 FastAPI 并确认接口文档能打开再创建前端工程联调注册登录然后接题库模块最后做 Docker 评测。这一步顺序不要反过来因为评测服务是最容易受环境影响的部分如果一开始就做评测后面再联调其他模块时遇到环境问题排查来源会很痛苦。C 语言评测前可以在本机装一下gcc并测试几个最简单的程序确保操作系统上的 Docker 可以正常拉取镜像。如果开发机是 Windows建议评测服务老老实实用一台 Linux 机器或者虚拟机跑文件挂载、权限控制和timeout命令在 Linux 上都要省心很多。我在本地 Windows 上折腾 Docker 文件挂载耗费的时间比写评测模块本身还长。这个项目让我体会最深的是学习辅导网站不只是把题目放到网上代码评测也不是简单执行一条命令。真正的难点在于如何把学生的每一次错误翻译成有方向的学习反馈这需要业务逻辑和工程实现的配合。做的时候多站在学生视角去想他们看到这个页面能不能知道下一步做什么这样产品才能从“能跑”变成“好用”。