开学季被班主任微信轰炸之后我做了个家校信息共享平台每年九月初那几天我的手机基本处于瘫痪状态。班级群里的通知、家长私信里的询问、作业提交情况的核对提醒全部挤在一起。说实话家长和老师之间的信息沟通需求一直很大但微信群的天然缺陷——消息刷屏、文件过期、通知无回执——决定了它不是干这个活的最佳工具。当时手头正好要做一个Python方向的项目就顺势把它落地成了一个基于Vue前端 Python后端的家校信息共享平台后端框架在django和flask之间权衡了很久。整套开发全程在pycharm里完成从数据库建模、接口开发到前端页面渲染踩了不少坑也沉淀了不少经验。这篇文章就完整复盘一下这个项目的全过程包括技术选型背后的逻辑、核心模块的设计思路、前后端对接时容易忽略的细节以及部署上线前的自测清单。如果你想做同类项目或者正在准备相关的课程设计和毕业设计这份实战记录可以直接参考。1. 家校信息共享平台到底要解决什么问题1.1 微信群里的真实困境先还原一下使用场景。很多班级群的日常是这样的老师在群里发一份通知看到的人回复收到没回复的人需要单独私聊确认作业布置在群里过两天就沉底了想翻出来看往往要翻几百条记录家长想私下了解孩子的在校表现只能私聊老师而老师们白天上课晚上备课很难做到及时回复。这些场景集中起来就是三个核心诉求通知要能触达、信息要能归档、沟通要能分流。把高频的批量信息交给平台来做把低频的个性化沟通留给线上一对一这是家校平台最根本的价值。所以我在设计需求时没有追求功能大而全而是先锁定三条主线学校端老师能发布通知、布置作业、录入成绩、管理班级学生信息。家长端家长能接收通知、查看作业与成绩、在线向老师留言。公共基础能力包括用户注册登录、角色权限控制、消息已读回执、基础数据加密。1.2 平台的核心用户角色与功能边界角色上我做了三种管理员学校教务层、老师、家长。角色的边界直接决定了权限模型的设计也决定了后端接口的粒度。功能边界我控制得比较克制MVP版本里不做IM聊天室、不做朋友圈式的动态流、不做复杂的课表排课。原因很简单这类功能头部产品已经做得非常成熟自研的成本和后续维护负担都很大但班主任发通知、看回执、存资料这三件事在那个时间点是没有被满足好的。所以整个项目把通知—回执—归档这条链路打通就已经覆盖了绝大多数真实使用场景。这个需求定位也在后续的开发中反复被验证是对的。每当我想往项目里加新功能时先问一句这个功能是在帮助老师减少重复劳动还是在给家长增加操作负担凡是答案不明确的一律砍掉。2. 技术选型复盘后端框架、前端栈与IDE的取舍2.1 django与flask的抉择不是二选一而是各就各位标题里同时出现了django和flask这也是很多初学者最容易纠结的事情。我的选择结果很明确后端主体用django在个别模块上用flask做实验性探索但最终生产主服务跑在django上。这个结论不是凭空得出的而是基于项目特性的考量和在pycharm里反复写demo后做的对比。django自带Admin后台、ORM、认证体系、Admin站点——这些对管理后台需求重、数据模型多、权限要求清晰的项目来说太合适了。家校平台恰好具备这些特征老师需要录入成绩、管理班级、维护学生资料这些操作天然需要一个可靠的后台界面django.contrib.admin直接省掉了我写一整套管理界面的时间而且它的权限系统Permission Group可以直接映射到我的角色模型。flask的优势是轻量、灵活、自由度高适合快速搭建小型API服务或者原型验证。我在项目里用它写了一个独立的文件上传微服务处理头像、附件这类不太需要复杂业务逻辑的资源上传。这么做的好处是主服务的代码库不会被文件处理的代码弄乱坏处是运行期间需要多维护一个进程。如果你是一个人做课程设计或毕业设计我不建议拆成两个服务这会显著增加部署复杂度项目收尾时我意识到对于这个体量的平台flask承担的那部分功能完全可以用django的视图函数实现拆分带来的模块清晰度边际收益并不大。2.2 django这边怎么组织代码django项目我按标准的MTV模式组织但针对前后端分离改造了两个部分模板层不再返回HTML页面而是返回JSON数据使用django-rest-frameworkDRF作为接口框架。模型层以业务实体为核心建表通过ORM管理数据库关系不直接写SQL。django-rest-framework是我选django的第二个重要理由。它把序列化器Serializer、视图集ViewSet、路由器Router组合起来我只需定义好模型和序列化规则DRF会自动生成符合RESTful规范的接口列表还自带可交互的API文档页面。这在前后端联调时非常有用——前端同事或自己写Vue时可以直接在浏览器里调用接口调试而不必先把整个前端搭起来才能测接口。2.3 pycharm在项目中的实际定位很多教程把pycharm说得神乎其神但我的真实体会是它最核心的价值在于四个能力——项目解释器管理、远程部署同步、数据库工具、以及调试器。解释器管理pycharm可以直接为项目创建虚拟环境并关联系统Python避免多个项目的包互相污染。我习惯用virtualenvpycharm里创建项目时选择虚拟环境后续安装django、DRF、mysqlclient等依赖全部在IDE的Python Packages窗口里完成比命令行逐个pip install直观得多。远程部署同步开发后期我把代码部署到一台Linux服务器上pycharm的SFTP部署功能直接将本地代码同步到服务器并配置自动上传。这比用git在服务器上不断拉取分支要方便。数据库工具打开pycharm右侧的Database面板链接MySQL后可以直接看到表结构、执行SQL查询、修改数据不需要再单独打开Navicat。对于django的ORM调试来说用IDE看ORM生成的SQL最直观。调试器这是排错神器。在视图函数里打断点逐个检查request对象携带的参数、数据库查询结果的状态比盲改代码加print再重启服务高效一个量级。我用的是pycharm社区版专业版试用结合的方式。这里说明一下社区版完全免费足够应付本项目的日常开发如果要做前端Vue调试社区版也可以配合浏览器开发者工具完成。不推荐在这类校园项目上为激活问题花费精力有需要可以申请教育授权把精力留给写业务逻辑更重要。2.4 前端Vue的选型和构建方案前端选择Vue而非React或Angular两方面的原因一是Vue的中文文档和学习曲线对新手非常友好入门门槛低符合项目的整体技术基调二是Vue单文件组件的写法接近传统HTMLJS的开发习惯从pycharm里的django模板开发过渡到Vue比较平滑。在构建工具上使用了Vite而不是vue-cliwebpack主要原因就是快——Vite启动开发服务器基本秒开热更新也是毫秒级。对于一个需要频繁看页面效果的开发流程来说这个体感提升是实实在在的。3. 后端设计数据模型、接口规范与权限控制的落地方案3.1 数据表结构是怎么设计的这个项目的核心数据模型有六张表。我通过django的模型类来定义它们表名和字段名都有意设计得容易理解表/模型名关键字段作用说明Userusername、password、phone、role统一用户表role区分teacher/parent/adminStudentname、class_name、parent外键、teacher外键学生档案同时关联家长和班主任Noticetitle、content、publisher、created_at、is_deleted通知公告学校端发布NoticeReadRecordnotice外键、reader外键、read_time已读回执记录标记谁看了、何时看Homeworktitle、content、deadline、teacher外键、attachment作业布置支持上传附件Scorestudent外键、course、score_value、exam_type成绩录入与查询这个设计里最花心思的是NoticeReadRecord这张表。最初我图省事想在Notice里加一个read_users字段用逗号分隔用户ID但也觉得性能不好、查询不方便。后来老老实实拆了一张关联表出来每一行记录某一篇通知被某个人已读。这样查询哪些人未读就变成了一条简单的ORM过滤操作NoticeReadRecord.objects.filter(noticenotice).values_list(reader_id, flatTrue)再用差集算法算未读用户。查询效率提升了不止一个层次。django的ORM在关系处理上确实省力定义了外键后可以直接用notice.publisher.username这样的反向关联拿数据不需要手写SQL JOIN。但也因为这样ORM执行时往往伴随隐藏的多次查询——即N1问题。我通过django-debug-toolbar在开发环境下检测SQL执行次数删除了很多for循环内的重复查询改成select_related和prefetch_related提前把关联数据一次性取出。这个优化动作建议早点做越晚做代码里需要改的地方就越多。3.2 API接口规范与返回格式约定前后端分离项目最怕的就是接口格式各写各的。我在项目一开始就和前端约定了统一的返回体{ code: 200, message: success, data: {} }这个规范落实到django-rest-framework中就是封装一个统一的响应函数或自定义Renderer。我的做法是写了一个utils/response.pyfrom rest_framework.response import Response def success(dataNone, messagesuccess): return Response({code: 200, message: message, data: data}) def fail(code400, messageerror): return Response({code: code, message: message, data: None})然后在所有视图集里统一调用不在每个接口里各自发挥。这样做有三个明显好处一是前端处理响应时不需要为每个接口单独写一层适配二是当后端出现未捕获的异常时会有一个统一的兜底返回结构三是调试时看network面板一目了然哪个接口出了问题立刻能定位是业务逻辑错误还是参数格式错误。API的路由设计遵循RESTful风格资源名用复数动作通过HTTP方法表达方法路径功能GET/api/notices/通知列表分页POST/api/notices/发布新通知GET/api/notices/{id}/read/获取某通知的已读状态PUT/api/notices/{id}/修改通知DELETE/api/notices/{id}/逻辑删除通知GET/api/students/学生列表POST/api/scores/录入成绩3.3 权限控制不只是登录才能看家校平台的权限复杂度在于它不仅需要区分登录与未登录还需要区分老师能不能看全班成绩和家长能不能看自家孩子的成绩。我的方案是在django-rest-framework中使用自定义权限类from rest_framework.permissions import BasePermission class IsTeacher(BasePermission): def has_permission(self, request, view): return request.user.is_authenticated and request.user.role teacher class IsOwnerParent(BasePermission): def has_object_permission(self, request, view, obj): if request.user.role admin: return True if request.user.role teacher: return True if request.user.role parent: return obj.parent request.user return False重点在于对象级别的权限判断IsOwnerParent保证了家长只能查看自己孩子的数据翻不到别人的孩子。我在这个环节上吃过一次亏最初只在视图层面判断了登录状态结果家长A通过直接传student_id访问到了家长B孩子的成绩。后来补上object-level permission并在测试时手动构造越权请求验证才算彻底堵住漏洞。这种水平越权IDOR问题在前后端分离项目中非常容易犯——前端只隐藏了入口按钮不代表后端接口不存在接口层面的权限校验才是最后一道防线。4. 前端Vue的实现工程搭建、页面拆解与数据对接4.1 从零搭一个Vue工程前端工程采用Vite初始化。在pycharm的Terminal面板里执行npm create vuelatest交互提问中选择需要Router和Pinia其余保持默认即可。工程结构按照模块化思想组织实际用到的目录如下src/ |-- api/ # 按业务模块拆分的API请求封装 | |-- notice.js | |-- homework.js | |-- score.js |-- views/ # 页面级组件 | |-- NoticeList.vue | |-- NoticeDetail.vue | |-- HomeworkList.vue | |-- ScoreBoard.vue | |-- Profile.vue |-- components/ # 可复用组件如通知卡片、已读列表等 |-- router/ # 路由配置 |-- stores/ # Pinia状态管理 |-- utils/ # axios封装、时间格式化等axios封装是整个前端的基础设施我在utils/request.js里统一配置了baseURL和拦截器import axios from axios import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization JWT ${token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { // 业务错误提示 return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response.status 401) { router.push(/login) } return Promise.reject(error) } ) export default request这里尤其注意拦截器统一处理认证令牌和错误状态。否则每一个页面里都要重复写相似的错误弹窗和跳转逻辑代码会膨胀得很难维护。4.2 核心页面组件是怎么拆的页面拆分遵循一个视图文件负责一个完整功能页面子元素抽成组件的原则。NoticeList.vue是老师发布和家长查看通知的共用页面但根据当前用户角色渲染不同的操作按钮。页面内部调用notice.js里的两个API函数export function fetchNotices(params) { return request.get(/notices/, { params }) } export function createNotice(data) { return request.post(/notices/, data) }在script setup里加载数据const loading ref(false) const notices ref([]) async function loadNotices() { loading.value true try { notices.value await fetchNotices({ page: currentPage.value }) } finally { loading.value false } } onMounted(loadNotices)已读回执是前端较为棘手的效果——老师在通知列表中需要看到33/40人已读点进去还要看到未读家长的名单。我的实现方式是通知详情页调GET /api/notices/{id}/read/拿到一个结构如{ read_users: [...], unread_users: [...] }的对象再通过v-for渲染两个分组列表未读组用红色标签突出显示。这比在列表页一次性加载所有已读状态更省流量也对后端更友好。4.3 路由、状态管理与其他细节路由配置采用createRouter的history模式路由表里每个页面配置meta字段标记访问角色在全局前置守卫里做访问控制router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path ! /login !token) { next(/login) } else if (to.meta.role to.meta.role ! store.user.role) { next(/403) } else { next() } })状态管理用Pinia实际用的最多的store是用户信息store里面存着当前用户ID、角色、姓名、关联的学生ID。由于接口返回的信息分散我将组合操作放在了store的getter里export const useUserStore defineStore(user, { state: () ({ userInfo: {} }), getters: { isTeacher: (state) state.userInfo.role teacher, studentIds: (state) state.userInfo.role parent ? state.userInfo.children_ids : [] } })5. 联调、部署与性能优化的实战记录5.1 前后端联调比想象中花时间很多独立开发者在后端接口写完和前端页面写完之间会有一个思维跳跃——以为各自写完就能无缝对接。实际上联调阶段几乎一定会暴露几类问题第一类是约定不同步。比如后端接口要求参数格式是deadline: 2025-09-30 23:59:59前端传来的却是deadline: 2025/09/30 23:59:59或者是时间戳。解决办法是前后端约定统一使用ISO 8601字符串并在前端封装统一的格式化函数。第二类是跨域与代理。开发环境下前端跑在5173端口后端跑在8000端口必然跨域。我的方案是在Vite的配置里设置开发代理把/api路径代理到本机的8000端口server: { proxy: { /api: { target: http://127.0.0.1:8000, changeOrigin: true } } }这样前端代码里所有请求都是相对路径不需要写死IP和端口部署时也可以无缝迁移。如果不用代理而直接开CORS也能跑通但生产环境里还得再处理一遍所以推荐一上来就配代理。第三类是列表接口的分页结构。DRF的默认分页返回结构是{ count, next, previous, results }如果前端不统一好翻页逻辑很容易错。我在前端封装了一个统一的parsePageData函数把DRF的分页结构转换成前端页面里更顺手的{ total, list }。5.2 部署方案的完整链路项目部署采用的是前后端分离部署方案服务器选择了一台Linux实例。后端使用gunicorn多进程跑django前端构建成静态文件交给nginx托管统一通过nginx反向代理。关键的django配置在settings.py中有几处必须修改DEBUG False ALLOWED_HOSTS [your_domain_or_ip] STATIC_ROOT os.path.join(BASE_DIR, staticfiles)然后执行静态文件收集python manage.py collectstaticgunicorn启动命令如下指定了三个worker进程和一个线程适配低配置服务器的并发需求gunicorn myproject.wsgi:application -w 3 -b 127.0.0.1:8000 --threads 2nginx关键配置片段server { listen 80; server_name your_domain; # 前端静态资源 root /var/www/home-school-web/dist; index index.html; location / { try_files $uri $uri/ /index.html; } # 后端API反向代理 location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里有一个非常关键的坑Vue路由用history模式时刷新页面会404。原因在于Vue是单页应用所有路由切换都在前端完成但浏览器刷新时会向nginx请求真实的路径比如/notices/3而服务器上根本没有这个文件。所以配置里必须有try_files $uri $uri/ /index.html;这一行把所有刷新请求重新指向index.html。如果还有404就检查prod环境的nginx有没有这一行配置。5.3 性能优化的几个实际动作平台上线后实际使用中最影响体感的两个性能指标是首屏加载速度和列表数据请求速度。首屏优化做了三件事路由级代码分割把每个页面打包成独立的chunk首屏只加载首页需要的JS。静态资源压缩Vite默认在build时压缩JS/CSS注意确认产物中没有未压缩的大文件。图片懒加载通知和作业封面图使用v-lazy指令按需加载。数据接口优化做了两件事列表查询加select_related和prefetch_related消除N1。给高频查询的字段追加数据库索引比如Notice.created_at和Score.student_id在django里用db_indexTrue声明。经过这轮优化通知列表接口的响应时间从500ms级别降到100ms以内效果非常直观。6. 项目过程中的经验沉淀与避坑指引6.1 开发顺序和任务拆解的建议如果你打算复刻这个项目我强烈建议按以下顺序推进可以少走很多弯路先定数据模型。不要边开发边加表数据库结构的调整成本会随着代码量增长而加剧。用django Admin完成基础数据维护。Admin里能录入学生信息、测试发布通知验证模型字段设计是否合理这会逼你尽快走通一遍核心业务流。完成所有后端接口的编写与自测。这里说的自测不只是浏览器访问看有没有报错而是用Postman或pycharm自带的HTTP Client把每个接口的异常分支都试一遍。再开始前端开发。接口稳了前端写起来会很顺畅不用边写边等后端返工。最后做前后端联调和部署。这个顺序最关键的一点是它能更早暴露业务逻辑层面的设计缺陷。如果你先画页面再写接口最后建表很容易陷入页面做完了才发现缺字段的被动局面——届时改表、改序列化器、改前端组件一轮改下来非常消耗耐心。6.2 我在这类项目里踩过的具体坑坑一数据库表间关系定义太随意。最初设计学生表时我把家长和学生的关系定义成外键时没有考虑一个家长有多个孩子的场景导致录入二胎家庭的数据时就卡住了。后来才把关系改成学生表里存parent外键即反向的多对一关系这也更符合实际业务。数据模型设计阶段多问几个这个家庭如果有两个孩子会怎样能避免很多返工。坑二前端在for循环里写同步请求。在页面同时加载通知列表和已读状态时我在循环里逐个调用接口导致浏览器并发请求过多需要靠Loading遮罩强撑。后来改成后端一次返回聚合数据或者前端用Promise.all并发请求体验立刻不一样。作为独立开发者我有时会忘记自己面对的不只是API调用还有网络并发问题。坑三admin后台被当作正式功能暴露出来。django Admin确实方便但它没有针对移动端和普通用户做优化不能当作家长端或老师端的正式页面使用。Admin只适合管理员做数据维护普通用户的功能必须走业务页面和API。坑四响应体格式在后期被局部绕过。有一些接口在写的时候因为图省事直接返回了Response({data: xxx})而没有包成统一格式后来联调时前端同事挨个排查了很久。这提醒自己一旦定下规范就要严格执行不要因为这个接口很简单就绕过规范积少成多就成了技术债。6.3 后续扩展这道题我打算怎么做这个项目做完一轮后我在想三个方向的扩展一是在线聊天IM用于家长和老师之间的一对一沟通取代微信私聊。技术上会考虑WebSocket实现实时消息推送django的通道channels层已经在这个方向上有了成熟方案。二是成绩趋势分析。现有的成绩表只存了每次考试的分数后续可以加上画折线图的功能让家长看到孩子的成绩波动曲线。这个功能的数据模型已经天然支持只需要加一个前端图表库echarts再写个聚合查询接口就行。三是班级圈或通知评论让家长在通知下面反馈问题。这个功能对互动氛围有要求如果你们学校或机构的家长群体习惯线上互动可以作为二期功能。整体来说家校信息共享平台的技术难度不算特别高但胜在业务链条完整、用户角色清晰、权限管理有真实的复杂度非常适合作为学习Python Web开发和Vue前后端分离的练手项目。最后分享一个心得好的项目复盘不是罗列完成的功能而是记清楚每个决策的理由。回头看这个项目最有价值的不是我写出了多少行代码而是为什么用django而不是flask为什么通知已读状态要单独建表为什么前端要配开发代理这些选择背后的思考。把这些想明白下次做任何项目心里都会更有底气。