简介本资源是一套完整的基于PythonDjango开发的问卷调查系统毕业设计源码面向计算机类专业本科生及初阶Web开发者解决在线问卷创建、发布、回收与可视化分析等核心需求覆盖用户管理、多题型问卷编辑、答案采集、统计图表生成及CSV/PDF报表导出等典型功能模块。压缩包共46个文件含28个Python后端逻辑文件models/views/urls等、7个HTML模板页、5个JavaScript交互脚本、1个CSS样式文件及README.md等工程文档总大小787KB结构清晰符合Django标准项目布局含surveySystem主项目与web/questionnaire子应用。已有288人学习下载代码具备完整可运行性包含数据库迁移脚本、初始化配置init.json、API接口定义及前后端分离式视图组织适合作为毕设参考、课程设计原型或Django全栈开发入门实践范例。 拿到“基于pythonDjango的问卷调查系统.zip”这个压缩包我第一反应就是这多半是某位同学的课程设计或者毕业设计也可能是小团队内部要做的快速投票工具。这类项目我经手过好几次也帮人跑通过不少名称看起来都是一个套路但解压之后里面的完成度天差地别——有的只有两三个app和几个裸模板有的则包含完整的问卷编辑、答卷收集、后台统计和报表导出。这篇文章就把这类项目从解压到跑通、再到扩展提升的完整链路拆开讲一遍全程用我实际踩坑验证过的经验来写尽量让刚接触Python和Django的人也能照着操作。Django在这个场景里是最不折腾的选择问卷调查系统的核心就是“建表、渲染表单、收数据、做统计”这些恰恰是Django自带的强项。你不用额外搭前端工程不用自己写数据库连接层模型定义好之后迁移命令一敲表就建好了后台管理界面免费送问卷数据能直接在Admin里看。下面我会按照项目设计、核心流程、部署上线、问题排查这几个环节来展开把这套代码背后真正值钱的逻辑说清楚。1. 内容整体设计与思路拆解1.1 为什么选PythonDjango而不是Flask或前后端分离先说结论如果是毕业设计、课程设计或者公司内部需要一个快速上线的问卷工具Django是完成度最高、返工风险最低的选择。Flask确实更轻但问卷调查不是“Hello World”它要处理用户登录、问卷发布、答卷入库、统计图表这些完整业务用Flask的话光是数据库迁移和Admin后台就得自己接不少东西。前后端分离的方案虽然看起来“高大上”但对单人开发来说Vue或React那套工程化链路——Node环境、接口文档、跨域处理、打包部署——每一环都是额外的学习成本和时间成本。而Django把这些全部打包好了。它的ORM让你直接用Python类定义问卷、题目、选项、答卷这些数据模型不需要手写SQL它的Form和模板系统能服务端渲染问卷页面天然规避了跨域问题Django自带的Admin后台可以直接拿来管理问卷和查看数据。一个典型的开发流程就是python manage.py startapp survey创建应用在models.py里定义数据表写视图函数处理请求配好urls.py模板渲染页面然后跑python manage.py runserver。整个过程不需要跳出Python这一门语言对新手极其友好。1.2 解压后应该先看到什么项目结构自查清单拿到一个Django工程项目不要急着runserver先把目录结构看一遍。标准Django项目里一定会有这些关键文件最外层的manage.py是项目操作的入口所有python manage.py xxx命令都靠它内层同名目录里的settings.py是整个项目的配置中心urls.py是URL路由入口如果你看到requirements.txt那就在安装依赖时省很多事直接pip install -r requirements.txt即可。问卷调查的核心业务通常放在名为survey、questionnaire或polls的app目录里里面一定有models.py数据表定义、views.py业务逻辑、admin.py后台管理注册。模板文件一般放在app目录下的templates/文件夹或者项目根目录的templates/文件夹里面是HTML页面。有些项目还带着static/目录放CSS和JS也可能带着media/目录存用户上传的图片附件。建议先对照这份清单确认文件结构再开始下一步操作能少走很多弯路。2. 核心细节解析与实操要点2.1 数据模型设计问卷、题目、选项、答卷怎么建表问卷调查系统的数据库设计是整个项目的地基我用过几种方案最终稳定的做法是四张表问卷表、题目表、选项表、答卷表。问卷表存标题、描述、创建时间、发布状态题目表通过外键关联到问卷存题型和题干选项表通过外键关联到题目存A/B/C/D这些选项内容答卷表则记录用户每次提交的答案。这种设计的好处是扩展性强以后想增加“填空题”“矩阵题”都可以通过题型字段扩展而不需要重构表结构。from django.db import models class Survey(models.Model): title models.CharField(max_length200, verbose_name问卷标题) description models.TextField(blankTrue, verbose_name问卷说明) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) is_published models.BooleanField(defaultFalse, verbose_name是否发布) def __str__(self): return self.title class Question(models.Model): QUESTION_TYPES ( (single, 单选题), (multiple, 多选题), ) survey models.ForeignKey(Survey, related_namequestions, on_deletemodels.CASCADE) text models.CharField(max_length500, verbose_name题干) question_type models.CharField(max_length20, choicesQUESTION_TYPES, defaultsingle) def __str__(self): return self.text class Choice(models.Model): question models.ForeignKey(Question, related_namechoices, on_deletemodels.CASCADE) text models.CharField(max_length200, verbose_name选项内容) def __str__(self): return self.text class Response(models.Model): survey models.ForeignKey(Survey, related_nameresponses, on_deletemodels.CASCADE) submitted_at models.DateTimeField(auto_now_addTrue, verbose_name提交时间)这里有一个容易踩坑的点不要把答案存在一个JSON字段里图省事。JSON字段确实方便但后续做统计、筛选不同选项的答卷时你会发现SQL查询变得很别扭Django的ORM也没法高效地按选项聚合。正确做法是单独设计一张答案明细表Answer每条记录存一次提交中的一道题答案通过外键关联到Response再关联到Question和Choice。虽然多写一两张表但统计功能实现起来清爽很多。2.2 显示题目与收集答卷的完整流程问卷填写页面是用户唯一接触的部分。Django的视图函数逻辑很简单一个视图负责渲染问卷页面从数据库取出问卷关联的所有题目和选项另一个视图负责接收POST提交。这里最大的坑是表单的name属性。我见过不少项目用循环遍历题目时忘了给每个题目和选项设置唯一的name结果提交后后端拿不到数据。我的做法是单选题的radio组件统一用namequestion_题目ID多选题的checkbox加上[]后缀即namequestion_题目ID[]后端接收时就能通过key解析出每道题的答案。模板核心代码写法如下{% for question in questions %} p{{ forloop.counter }}. {{ question.text }}/p {% for choice in question.choices.all %} label input typeradio namequestion_{{ question.id }} value{{ choice.id }} {{ choice.text }} /label {% endfor %} {% endfor %}接收提交的视图里用request.POST.getlist(question_3)就能取到第3题的全部选项ID。注意多选一定要用getlist用get只会拿到最后一个值这是新手必踩的坑。拿到数据之后先做合法性校验——检查选项ID是否真的属于对应题目防止有人构造恶意请求提交不存在的选项然后逐条创建答案记录。2.3 统计数据与导出报表的实现思路统计环节决定了这个问卷系统是“能用”还是“好用”。最简单直观的做法是Django的ORM聚合功能。要统计每道题每个选项被选了多少次可以用Count和annotate。from django.db.models import Count def survey_statistics(request, survey_id): survey Survey.objects.get(idsurvey_id) stats {} for question in survey.questions.all(): choices_data [] total_answers Answer.objects.filter(questionquestion).count() for choice in question.choices.all(): count Answer.objects.filter(questionquestion, choicechoice).count() percentage round(count / total_answers * 100, 2) if total_answers else 0 choices_data.append({ choice_text: choice.text, count: count, percentage: percentage }) stats[question.text] choices_data return render(request, survey/stats.html, {stats: stats})写这段代码的时候我用了一个小技巧先用一个字典按question_id缓存每个题目的答卷总数然后对每个选项做filter().count()。如果题目数量不多这种写法完全够用代码可读性也好。数据量真的到了几万条答卷再考虑用annotate在数据库层一次性聚合但课程设计阶段完全没必要提前优化。2.4 后台管理的快速配置Django自带Admin后台是这类项目交付时的重要加分项。注册模型之后你不需要写任何前端页面就能直接添加问卷、配置题目和选项也能在后台看到用户提交的答卷记录。from django.contrib import admin from .models import Survey, Question, Choice, Response, Answer class QuestionInline(admin.TabularInline): model Question extra 0 class SurveyAdmin(admin.ModelAdmin): list_display (title, is_published, created_at) list_filter (is_published,) inlines [QuestionInline] admin.site.register(Survey, SurveyAdmin) admin.site.register(Question) admin.site.register(Choice) admin.site.register(Response)把is_published加入list_filter之后管理员可以在后台一键筛选出已发布和未发布的问卷管理体验会好很多。我在交付这类项目时还会帮用户在admin.py里加上list_display和search_fields让后台界面看起来像模像样这对答辩或者演示打分很有帮助。3. 实操过程与核心环节实现3.1 环境准备本地把项目跑起来的三板斧拿到别人的zip项目第一步永远是创建虚拟环境并安装依赖千万别直接往全局Python环境里装包。我用venv比较多创建虚拟环境、激活、装依赖三步走python -m venv venv # Windows环境激活 venv\Scripts\activate # Linux/macOS环境激活 source venv/bin/activate pip install -r requirements.txt如果项目没带requirements.txt就手动安装Django和必要的扩展库一般只需要pip install django。装完之后先检查版本是否和项目兼容有些老项目用Django 2.x写的用Django 4.x跑起来会报一堆django.urls相关的错误。检查方法很简单python -m django --version接下来是数据库迁移。Django的模型对应数据库表迁移命令会自动比对模型和当前数据库的差异把新增的表建出来python manage.py makemigrations python manage.py migrate python manage.py createsuperuser登录后台、创建一份测试问卷并填写提交如果数据能正常展示这个项目的核心流程就已经通了。3.2 部署到服务器或局域网的配置要点开发阶段的runserver只能用于本地调试真正要让别人能访问得做部署。最简单的方案是在同一局域网内用python manage.py runserver 0.0.0.0:8000跑起来别人就能通过你的IP地址访问。这种方式演示够了但不稳定终端一关服务就没了。要长期稳定运行我用的是最经典的Nginx加Gunicorn组合。Gunicorn负责运行Django应用Nginx负责接收HTTP请求、转发给Gunicorn、处理静态文件。配置settings.py时有几个必须改的点DEBUG False、ALLOWED_HOSTS加上你的服务器IP或域名、静态文件配置STATIC_ROOT并执行python manage.py collectstatic收集静态文件。Django在部署时对静态文件的管理比较特殊开发模式下Django自己处理静态文件生产模式下必须交给Nginx处理。不执行collectstatic的话后台管理页面和页面CSS全是缺失的。这里我遇到过不少次页面毫无样式的情况排查到最后都是这个原因。3.3 跨平台迁移项目时要特别注意的坑搜索热词里出现了“win迁移麒麟”之类的词说明有人把整个Django项目从Windows迁移到国产化系统上。这类跨平台迁移我自己实战过总的原则是项目代码跨平台兼容性很好问题几乎都出在路径和数据库上。Windows下项目里如果有硬编码的C:\Users\xxx绝对路径迁到Linux必定报错。建议搜一下代码里有没有os.path.join用错的地方改成Path(__file__).resolve().parent.parent基于项目文件相对定位。数据库这块如果原来用的是SQLite直接把.db文件拷过去就能用最省事如果用的是MySQL或PostgreSQL迁移的时候记得用python manage.py dumpdata data.json把数据导出来到新环境再python manage.py loaddata data.json。数据库迁移命令会有编码和权限的坑导出导入之间最好保持Django版本一致。3.4 避免常见的性能和数据问题问卷数据量大的时候填完问卷后的统计页面可能会变慢。一个常见原因是每次统计都循环查询数据库题目多、答卷多时就会上百次查询。解决办法是用Django的Prefetch预取关联数据一次把所有题目和选项加载到内存再在内存里做统计。from django.db.models import Prefetch def survey_statistics(request, survey_id): survey Survey.objects.prefetch_related( Prefetch(questions, querysetQuestion.objects.prefetch_related(choices)) ).get(idsurvey_id) # 之后遍历时不再产生数据库查询 for question in survey.questions.all(): for choice in question.choices.all(): pass另外提醒一件事数据库的on_delete参数要谨慎选择。如果问卷和题目之间的关系设为级联删除在后台删掉一份问卷时所有答卷也会一并删除。如果交付的需求是“保留答卷记录”就需要在删除操作里做软删除处理或者把外键的on_delete改成SET_NULL。这个细节经常被忽略等问题出现时已经晚了。4. 常见问题与排查技巧实录4.1 环境报错速查表我在跑这类zip项目时总结了一个高频报错表遇到问题先对照排除能省下大量搜索引擎往返时间。报错信息原因解决方法ModuleNotFoundError: No module named django虚拟环境没激活或没安装依赖激活venv后执行pip install djangoUnknown command: makemigrations当前目录不是项目根目录先cd到含manage.py的目录django.core.exceptions.ImproperlyConfiguredsettings.py中配置有误常见是SECRET_KEY格式问题检查SECRET_KEY是否为空或格式异常No such table没有执行migrate执行python manage.py migrateTemplateDoesNotExist模板文件路径配置错误检查settings.py的TEMPLATES配置和文件实际位置DisallowedHostALLOWED_HOSTS没有包含当前访问域名或IP在ALLOWED_HOSTS中加入对应地址这张表是我把常见错误按出现频率排序整理出来的排名第一的“没装依赖”能占所有问题的三成。很多同学拿到项目后直接python manage.py runserver报错后不知道先看虚拟环境浪费时间还容易产生挫败感。4.2 逻辑功能不能正常工作的排查实录功能层面找Bug时我习惯先看数据再看代码。比如问卷页面显示了题目但提交后没有任何反应先确认数据库的Response表里有没有新增记录。没有新记录说明视图函数或表单提交有问题重点看request.method POST判断是否正确、CSRF token是否正常渲染有新记录但统计页面没显示问题大概率出在查询逻辑比如统计拿错了问卷ID。还有一次遇到奇怪问题统计比例永远是100%。排查后发现问题出在代码里total_answers算的是所有题目的答案总数而不是当前题目的答案总数。这类逻辑错误不报错但结果不对最有效的排查方式是打印中间变量或者用Django的shell工具一条条执行查询语句亲眼看到每步返回什么数据定位会快很多。python manage.py shell在shell里可以手动创建问卷、回答然后执行统计视图里的关键查询逐步对照预期结果。这个方式对付“页面能打开但数据不对”的问题是神器我强烈建议遇到逻辑bug时先开一个shell窗口。4.3 数据安全与基础权限的补全建议原项目的代码里不一定做了权限控制谁都能打开问卷管理后台或者访问统计页面这在演示现场会很尴尬。我一般会给这类项目补三个基础防护登录要求、CSRF验证、查询参数校验。Django在最简单的场景下加权限不需要写额外表用装饰器就够了from django.contrib.auth.decorators import login_required login_required def survey_statistics(request, survey_id): # 只有登录用户才能查看统计给统计页面加login_required访问时未登录用户会被重定向到登录页。另外对switch_publish这类修改状态的操作建议用staff_member_required限制为管理员操作防止普通用户越权。CSRF防护Django默认开启只需要确保所有POST表单里包含{% csrf_token %}。这三步做完项目的安全水平就从“裸奔”提升到了“能演示不会翻车”的程度。5. 从课程设计到可展示项目的几个加分扩展如果时间充裕我强烈建议给这个问卷系统加一个结果可视化页面。方案不用太复杂在统计页面用ECharts或者Chart.js通过Django视图把统计数据以JSON格式输出前端拿数据画饼图/柱状图。我在给一个企业内部培训平台做问卷模块时就是在统计页面加了几行ECharts脚本管理员查看反馈的速度快了很多反馈质量也明显提升。扩展的方向可以按自己的需求选问卷填写页加一个密码验证只有拿到问卷密码的人才能填写问卷编辑页面用Django Formset动态增删题目实现多题批量编辑导出答卷数据为Excel方便在答辩或者汇报时展示原始数据增加匿名/实名填写切换用于内部调研和民主测评拿Excel导出举例用openpyxl库几行代码就能实现import openpyxl from django.http import HttpResponse def export_responses(request, survey_id): wb openpyxl.Workbook() ws wb.active ws.append([用户名, 提交时间]) responses Response.objects.filter(survey_idsurvey_id) for response in responses: ws.append([response.user.username, str(response.submitted_at)]) response HttpResponse(content_typeapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheet) response[Content-Disposition] attachment; filenameresponses.xlsx wb.save(response) return response这段代码要正式用建议再补上逐题的答案明细列。Excel文件能直接在WPS和Office里打开兼容性很好不会出现编码问题是明确无误的加分项。6. 把这套项目跑顺之后的几点真实心得课程设计或者小工具做到“能跑”很容易做到“能演示、经得起问”不容易。我在评估一个Django问卷项目时会看三件事数据库设计对不对、表单提交后数据是否完整、统计数据是否准确。这三件都是基本功练好它们比堆很多花哨功能更能体现工程能力。另外说一个实际操作中很实用的小建议项目交付前把这个zip压缩包里的__pycache__、.db.sqlite3、虚拟环境venv这些目录删掉再打包。这类压缩包如果带着虚拟环境文件夹解压出来可能有几百MB甚至更大而且别人没法跨平台直接使用。代码里也不要包含SECRET_KEY和数据库密码这类敏感信息交付前统一改成环境变量读取既安全又专业。Django这套技术栈做问卷系统其实有点“高射炮打蚊子”的意思但正是因为它自带的组件太多你才能在两三天内把问卷编辑、在线填写、后台管理、数据统计全链路打通。只要把数据模型设计清楚、表单提交链路捋顺、统计逻辑调对这个项目无论用于课程设计还是实际业务场景都能称得上扎实。我在实际使用中体会最深的一点是不要纠结于炫技把问卷从创建到统计的闭环走通比什么都重要。本文还有配套的精品资源点击获取
简介本资源是一套完整的基于PythonDjango开发的问卷调查系统毕业设计源码面向计算机类专业本科生及初阶Web开发者解决在线问卷创建、发布、回收与可视化分析等核心需求覆盖用户管理、多题型问卷编辑、答案采集、统计图表生成及CSV/PDF报表导出等典型功能模块。压缩包共46个文件含28个Python后端逻辑文件models/views/urls等、7个HTML模板页、5个JavaScript交互脚本、1个CSS样式文件及README.md等工程文档总大小787KB结构清晰符合Django标准项目布局含surveySystem主项目与web/questionnaire子应用。已有288人学习下载代码具备完整可运行性包含数据库迁移脚本、初始化配置init.json、API接口定义及前后端分离式视图组织适合作为毕设参考、课程设计原型或Django全栈开发入门实践范例。 拿到“基于pythonDjango的问卷调查系统.zip”这个压缩包我第一反应就是这多半是某位同学的课程设计或者毕业设计也可能是小团队内部要做的快速投票工具。这类项目我经手过好几次也帮人跑通过不少名称看起来都是一个套路但解压之后里面的完成度天差地别——有的只有两三个app和几个裸模板有的则包含完整的问卷编辑、答卷收集、后台统计和报表导出。这篇文章就把这类项目从解压到跑通、再到扩展提升的完整链路拆开讲一遍全程用我实际踩坑验证过的经验来写尽量让刚接触Python和Django的人也能照着操作。Django在这个场景里是最不折腾的选择问卷调查系统的核心就是“建表、渲染表单、收数据、做统计”这些恰恰是Django自带的强项。你不用额外搭前端工程不用自己写数据库连接层模型定义好之后迁移命令一敲表就建好了后台管理界面免费送问卷数据能直接在Admin里看。下面我会按照项目设计、核心流程、部署上线、问题排查这几个环节来展开把这套代码背后真正值钱的逻辑说清楚。1. 内容整体设计与思路拆解1.1 为什么选PythonDjango而不是Flask或前后端分离先说结论如果是毕业设计、课程设计或者公司内部需要一个快速上线的问卷工具Django是完成度最高、返工风险最低的选择。Flask确实更轻但问卷调查不是“Hello World”它要处理用户登录、问卷发布、答卷入库、统计图表这些完整业务用Flask的话光是数据库迁移和Admin后台就得自己接不少东西。前后端分离的方案虽然看起来“高大上”但对单人开发来说Vue或React那套工程化链路——Node环境、接口文档、跨域处理、打包部署——每一环都是额外的学习成本和时间成本。而Django把这些全部打包好了。它的ORM让你直接用Python类定义问卷、题目、选项、答卷这些数据模型不需要手写SQL它的Form和模板系统能服务端渲染问卷页面天然规避了跨域问题Django自带的Admin后台可以直接拿来管理问卷和查看数据。一个典型的开发流程就是python manage.py startapp survey创建应用在models.py里定义数据表写视图函数处理请求配好urls.py模板渲染页面然后跑python manage.py runserver。整个过程不需要跳出Python这一门语言对新手极其友好。1.2 解压后应该先看到什么项目结构自查清单拿到一个Django工程项目不要急着runserver先把目录结构看一遍。标准Django项目里一定会有这些关键文件最外层的manage.py是项目操作的入口所有python manage.py xxx命令都靠它内层同名目录里的settings.py是整个项目的配置中心urls.py是URL路由入口如果你看到requirements.txt那就在安装依赖时省很多事直接pip install -r requirements.txt即可。问卷调查的核心业务通常放在名为survey、questionnaire或polls的app目录里里面一定有models.py数据表定义、views.py业务逻辑、admin.py后台管理注册。模板文件一般放在app目录下的templates/文件夹或者项目根目录的templates/文件夹里面是HTML页面。有些项目还带着static/目录放CSS和JS也可能带着media/目录存用户上传的图片附件。建议先对照这份清单确认文件结构再开始下一步操作能少走很多弯路。2. 核心细节解析与实操要点2.1 数据模型设计问卷、题目、选项、答卷怎么建表问卷调查系统的数据库设计是整个项目的地基我用过几种方案最终稳定的做法是四张表问卷表、题目表、选项表、答卷表。问卷表存标题、描述、创建时间、发布状态题目表通过外键关联到问卷存题型和题干选项表通过外键关联到题目存A/B/C/D这些选项内容答卷表则记录用户每次提交的答案。这种设计的好处是扩展性强以后想增加“填空题”“矩阵题”都可以通过题型字段扩展而不需要重构表结构。from django.db import models class Survey(models.Model): title models.CharField(max_length200, verbose_name问卷标题) description models.TextField(blankTrue, verbose_name问卷说明) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) is_published models.BooleanField(defaultFalse, verbose_name是否发布) def __str__(self): return self.title class Question(models.Model): QUESTION_TYPES ( (single, 单选题), (multiple, 多选题), ) survey models.ForeignKey(Survey, related_namequestions, on_deletemodels.CASCADE) text models.CharField(max_length500, verbose_name题干) question_type models.CharField(max_length20, choicesQUESTION_TYPES, defaultsingle) def __str__(self): return self.text class Choice(models.Model): question models.ForeignKey(Question, related_namechoices, on_deletemodels.CASCADE) text models.CharField(max_length200, verbose_name选项内容) def __str__(self): return self.text class Response(models.Model): survey models.ForeignKey(Survey, related_nameresponses, on_deletemodels.CASCADE) submitted_at models.DateTimeField(auto_now_addTrue, verbose_name提交时间)这里有一个容易踩坑的点不要把答案存在一个JSON字段里图省事。JSON字段确实方便但后续做统计、筛选不同选项的答卷时你会发现SQL查询变得很别扭Django的ORM也没法高效地按选项聚合。正确做法是单独设计一张答案明细表Answer每条记录存一次提交中的一道题答案通过外键关联到Response再关联到Question和Choice。虽然多写一两张表但统计功能实现起来清爽很多。2.2 显示题目与收集答卷的完整流程问卷填写页面是用户唯一接触的部分。Django的视图函数逻辑很简单一个视图负责渲染问卷页面从数据库取出问卷关联的所有题目和选项另一个视图负责接收POST提交。这里最大的坑是表单的name属性。我见过不少项目用循环遍历题目时忘了给每个题目和选项设置唯一的name结果提交后后端拿不到数据。我的做法是单选题的radio组件统一用namequestion_题目ID多选题的checkbox加上[]后缀即namequestion_题目ID[]后端接收时就能通过key解析出每道题的答案。模板核心代码写法如下{% for question in questions %} p{{ forloop.counter }}. {{ question.text }}/p {% for choice in question.choices.all %} label input typeradio namequestion_{{ question.id }} value{{ choice.id }} {{ choice.text }} /label {% endfor %} {% endfor %}接收提交的视图里用request.POST.getlist(question_3)就能取到第3题的全部选项ID。注意多选一定要用getlist用get只会拿到最后一个值这是新手必踩的坑。拿到数据之后先做合法性校验——检查选项ID是否真的属于对应题目防止有人构造恶意请求提交不存在的选项然后逐条创建答案记录。2.3 统计数据与导出报表的实现思路统计环节决定了这个问卷系统是“能用”还是“好用”。最简单直观的做法是Django的ORM聚合功能。要统计每道题每个选项被选了多少次可以用Count和annotate。from django.db.models import Count def survey_statistics(request, survey_id): survey Survey.objects.get(idsurvey_id) stats {} for question in survey.questions.all(): choices_data [] total_answers Answer.objects.filter(questionquestion).count() for choice in question.choices.all(): count Answer.objects.filter(questionquestion, choicechoice).count() percentage round(count / total_answers * 100, 2) if total_answers else 0 choices_data.append({ choice_text: choice.text, count: count, percentage: percentage }) stats[question.text] choices_data return render(request, survey/stats.html, {stats: stats})写这段代码的时候我用了一个小技巧先用一个字典按question_id缓存每个题目的答卷总数然后对每个选项做filter().count()。如果题目数量不多这种写法完全够用代码可读性也好。数据量真的到了几万条答卷再考虑用annotate在数据库层一次性聚合但课程设计阶段完全没必要提前优化。2.4 后台管理的快速配置Django自带Admin后台是这类项目交付时的重要加分项。注册模型之后你不需要写任何前端页面就能直接添加问卷、配置题目和选项也能在后台看到用户提交的答卷记录。from django.contrib import admin from .models import Survey, Question, Choice, Response, Answer class QuestionInline(admin.TabularInline): model Question extra 0 class SurveyAdmin(admin.ModelAdmin): list_display (title, is_published, created_at) list_filter (is_published,) inlines [QuestionInline] admin.site.register(Survey, SurveyAdmin) admin.site.register(Question) admin.site.register(Choice) admin.site.register(Response)把is_published加入list_filter之后管理员可以在后台一键筛选出已发布和未发布的问卷管理体验会好很多。我在交付这类项目时还会帮用户在admin.py里加上list_display和search_fields让后台界面看起来像模像样这对答辩或者演示打分很有帮助。3. 实操过程与核心环节实现3.1 环境准备本地把项目跑起来的三板斧拿到别人的zip项目第一步永远是创建虚拟环境并安装依赖千万别直接往全局Python环境里装包。我用venv比较多创建虚拟环境、激活、装依赖三步走python -m venv venv # Windows环境激活 venv\Scripts\activate # Linux/macOS环境激活 source venv/bin/activate pip install -r requirements.txt如果项目没带requirements.txt就手动安装Django和必要的扩展库一般只需要pip install django。装完之后先检查版本是否和项目兼容有些老项目用Django 2.x写的用Django 4.x跑起来会报一堆django.urls相关的错误。检查方法很简单python -m django --version接下来是数据库迁移。Django的模型对应数据库表迁移命令会自动比对模型和当前数据库的差异把新增的表建出来python manage.py makemigrations python manage.py migrate python manage.py createsuperuser登录后台、创建一份测试问卷并填写提交如果数据能正常展示这个项目的核心流程就已经通了。3.2 部署到服务器或局域网的配置要点开发阶段的runserver只能用于本地调试真正要让别人能访问得做部署。最简单的方案是在同一局域网内用python manage.py runserver 0.0.0.0:8000跑起来别人就能通过你的IP地址访问。这种方式演示够了但不稳定终端一关服务就没了。要长期稳定运行我用的是最经典的Nginx加Gunicorn组合。Gunicorn负责运行Django应用Nginx负责接收HTTP请求、转发给Gunicorn、处理静态文件。配置settings.py时有几个必须改的点DEBUG False、ALLOWED_HOSTS加上你的服务器IP或域名、静态文件配置STATIC_ROOT并执行python manage.py collectstatic收集静态文件。Django在部署时对静态文件的管理比较特殊开发模式下Django自己处理静态文件生产模式下必须交给Nginx处理。不执行collectstatic的话后台管理页面和页面CSS全是缺失的。这里我遇到过不少次页面毫无样式的情况排查到最后都是这个原因。3.3 跨平台迁移项目时要特别注意的坑搜索热词里出现了“win迁移麒麟”之类的词说明有人把整个Django项目从Windows迁移到国产化系统上。这类跨平台迁移我自己实战过总的原则是项目代码跨平台兼容性很好问题几乎都出在路径和数据库上。Windows下项目里如果有硬编码的C:\Users\xxx绝对路径迁到Linux必定报错。建议搜一下代码里有没有os.path.join用错的地方改成Path(__file__).resolve().parent.parent基于项目文件相对定位。数据库这块如果原来用的是SQLite直接把.db文件拷过去就能用最省事如果用的是MySQL或PostgreSQL迁移的时候记得用python manage.py dumpdata data.json把数据导出来到新环境再python manage.py loaddata data.json。数据库迁移命令会有编码和权限的坑导出导入之间最好保持Django版本一致。3.4 避免常见的性能和数据问题问卷数据量大的时候填完问卷后的统计页面可能会变慢。一个常见原因是每次统计都循环查询数据库题目多、答卷多时就会上百次查询。解决办法是用Django的Prefetch预取关联数据一次把所有题目和选项加载到内存再在内存里做统计。from django.db.models import Prefetch def survey_statistics(request, survey_id): survey Survey.objects.prefetch_related( Prefetch(questions, querysetQuestion.objects.prefetch_related(choices)) ).get(idsurvey_id) # 之后遍历时不再产生数据库查询 for question in survey.questions.all(): for choice in question.choices.all(): pass另外提醒一件事数据库的on_delete参数要谨慎选择。如果问卷和题目之间的关系设为级联删除在后台删掉一份问卷时所有答卷也会一并删除。如果交付的需求是“保留答卷记录”就需要在删除操作里做软删除处理或者把外键的on_delete改成SET_NULL。这个细节经常被忽略等问题出现时已经晚了。4. 常见问题与排查技巧实录4.1 环境报错速查表我在跑这类zip项目时总结了一个高频报错表遇到问题先对照排除能省下大量搜索引擎往返时间。报错信息原因解决方法ModuleNotFoundError: No module named django虚拟环境没激活或没安装依赖激活venv后执行pip install djangoUnknown command: makemigrations当前目录不是项目根目录先cd到含manage.py的目录django.core.exceptions.ImproperlyConfiguredsettings.py中配置有误常见是SECRET_KEY格式问题检查SECRET_KEY是否为空或格式异常No such table没有执行migrate执行python manage.py migrateTemplateDoesNotExist模板文件路径配置错误检查settings.py的TEMPLATES配置和文件实际位置DisallowedHostALLOWED_HOSTS没有包含当前访问域名或IP在ALLOWED_HOSTS中加入对应地址这张表是我把常见错误按出现频率排序整理出来的排名第一的“没装依赖”能占所有问题的三成。很多同学拿到项目后直接python manage.py runserver报错后不知道先看虚拟环境浪费时间还容易产生挫败感。4.2 逻辑功能不能正常工作的排查实录功能层面找Bug时我习惯先看数据再看代码。比如问卷页面显示了题目但提交后没有任何反应先确认数据库的Response表里有没有新增记录。没有新记录说明视图函数或表单提交有问题重点看request.method POST判断是否正确、CSRF token是否正常渲染有新记录但统计页面没显示问题大概率出在查询逻辑比如统计拿错了问卷ID。还有一次遇到奇怪问题统计比例永远是100%。排查后发现问题出在代码里total_answers算的是所有题目的答案总数而不是当前题目的答案总数。这类逻辑错误不报错但结果不对最有效的排查方式是打印中间变量或者用Django的shell工具一条条执行查询语句亲眼看到每步返回什么数据定位会快很多。python manage.py shell在shell里可以手动创建问卷、回答然后执行统计视图里的关键查询逐步对照预期结果。这个方式对付“页面能打开但数据不对”的问题是神器我强烈建议遇到逻辑bug时先开一个shell窗口。4.3 数据安全与基础权限的补全建议原项目的代码里不一定做了权限控制谁都能打开问卷管理后台或者访问统计页面这在演示现场会很尴尬。我一般会给这类项目补三个基础防护登录要求、CSRF验证、查询参数校验。Django在最简单的场景下加权限不需要写额外表用装饰器就够了from django.contrib.auth.decorators import login_required login_required def survey_statistics(request, survey_id): # 只有登录用户才能查看统计给统计页面加login_required访问时未登录用户会被重定向到登录页。另外对switch_publish这类修改状态的操作建议用staff_member_required限制为管理员操作防止普通用户越权。CSRF防护Django默认开启只需要确保所有POST表单里包含{% csrf_token %}。这三步做完项目的安全水平就从“裸奔”提升到了“能演示不会翻车”的程度。5. 从课程设计到可展示项目的几个加分扩展如果时间充裕我强烈建议给这个问卷系统加一个结果可视化页面。方案不用太复杂在统计页面用ECharts或者Chart.js通过Django视图把统计数据以JSON格式输出前端拿数据画饼图/柱状图。我在给一个企业内部培训平台做问卷模块时就是在统计页面加了几行ECharts脚本管理员查看反馈的速度快了很多反馈质量也明显提升。扩展的方向可以按自己的需求选问卷填写页加一个密码验证只有拿到问卷密码的人才能填写问卷编辑页面用Django Formset动态增删题目实现多题批量编辑导出答卷数据为Excel方便在答辩或者汇报时展示原始数据增加匿名/实名填写切换用于内部调研和民主测评拿Excel导出举例用openpyxl库几行代码就能实现import openpyxl from django.http import HttpResponse def export_responses(request, survey_id): wb openpyxl.Workbook() ws wb.active ws.append([用户名, 提交时间]) responses Response.objects.filter(survey_idsurvey_id) for response in responses: ws.append([response.user.username, str(response.submitted_at)]) response HttpResponse(content_typeapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheet) response[Content-Disposition] attachment; filenameresponses.xlsx wb.save(response) return response这段代码要正式用建议再补上逐题的答案明细列。Excel文件能直接在WPS和Office里打开兼容性很好不会出现编码问题是明确无误的加分项。6. 把这套项目跑顺之后的几点真实心得课程设计或者小工具做到“能跑”很容易做到“能演示、经得起问”不容易。我在评估一个Django问卷项目时会看三件事数据库设计对不对、表单提交后数据是否完整、统计数据是否准确。这三件都是基本功练好它们比堆很多花哨功能更能体现工程能力。另外说一个实际操作中很实用的小建议项目交付前把这个zip压缩包里的__pycache__、.db.sqlite3、虚拟环境venv这些目录删掉再打包。这类压缩包如果带着虚拟环境文件夹解压出来可能有几百MB甚至更大而且别人没法跨平台直接使用。代码里也不要包含SECRET_KEY和数据库密码这类敏感信息交付前统一改成环境变量读取既安全又专业。Django这套技术栈做问卷系统其实有点“高射炮打蚊子”的意思但正是因为它自带的组件太多你才能在两三天内把问卷编辑、在线填写、后台管理、数据统计全链路打通。只要把数据模型设计清楚、表单提交链路捋顺、统计逻辑调对这个项目无论用于课程设计还是实际业务场景都能称得上扎实。我在实际使用中体会最深的一点是不要纠结于炫技把问卷从创建到统计的闭环走通比什么都重要。本文还有配套的精品资源点击获取
