基于Django+Vue3的干部测评系统开发实战：从权限设计到数据统计-代码聚汇网

基于Django+Vue3的干部测评系统开发实战：从权限设计到数据统计

邱达丕·2026-09-25·阅读 21 GEO检测（免费）

PythonDjangoVue3

|难度：普通|阅读约 38 分钟

我从一个实际经历说起吧。前两年有个做组织人事工作的朋友找我吐槽，说每年年底干部测评都像打仗——纸质打分表发下去，收上来以后要手动誊录到Excel，再按十几个维度的指标逐项算加权分、做排名、划等次，几十号人的测评数据经常要两三个人加班统计好几天，中间还容易抄错行、算错分。他问我能不能帮忙搞一套在线测评系统：发起任务、分发问卷、自动汇总、生成图表一条龙搞定。

我评估了一下需求，决定用Python这套技术栈来做，后端选型在Flask和Django之间摇摆过，最后落地的是Django + Vue 3 + PyCharm的方案。这套系统现在已经跑完两轮真实测评，数据导出、权限控制、匿名打分这些核心点都验证过了。这篇文章把这套干部测评系统的完整思路和实现过程写出来，从业务需求拆解到数据库设计，从后端API实现到前端页面搭建，再到部署时容易踩的坑一次性讲透。适合正在做类似管理系统、毕业设计，或者想用Python + Vue从零搭一个带权限、带统计分析的真实项目的朋友参考。

1. 干部测评系统背后，是三类角色和一套完整流程

很多做技术的人拿到这种需求，第一反应就是“做一个表单打分功能”。真做下去就会发现，打分只是最表面的一层。干部测评本质上是一个带严格流程和时间约束的协同作业：有人负责发起、有人负责执行、有人只能看结果。把这三类人的权限和操作边界理清楚，系统才有落地的可能性。

1.1 核心角色梳理：管理员、测评人、被测评干部

在干部测评业务里，系统用户基本可以分成三个角色。

管理员，通常是组织人事部门的经办人。他们负责创建测评任务、选测评对象、设置指标模板、指定测评人，也负责在测评结束后查看汇总报表和导出数据。他们的核心诉求是“配置效率”和“统计准确”。

测评人，是实际打分的人。他们可能是被测评干部的同事、下属、上级，也可能来自其他部门。测评人登录系统以后，只能看到分配给自己的待办测评任务，进入以后需要按指标逐项打分，提交后就不能再改了。这个角色的核心诉求是“操作顺手”和“匿名安全感”——担心打分被查出来，这也是测评系统能不能被信任的关键。

被测评干部，是测评对象。他们的诉求很简单：测评结束后能查看自己的综合得分、各维度表现和等次反馈，但看不到究竟谁给自己打了分，也看不到自己的横向排名（有的单位允许看排名，这块完全看业务要求）。

1.2 测评任务的完整生命周期：从创建到归档

整个测评业务跑起来，是一条非常清晰的流水线：

管理员创建测评任务，选择或复制一套指标模板，设置测评周期的起止时间。
从人员库里勾选本次被测评的干部名单。
为每个被测评对象匹配一批测评人。这里有两种模式：一种是管理员手动指定，一种是从某个范围内自动分配（比如“部门内随机20人”）。
系统根据配置自动生成测评表，测评人在个人待办里会看到这些表。
测评人逐项打分并提交，提交后锁定。
到达截止时间后，管理员关闭任务，系统自动计算各维度的得分、加权总分、等级分布、排名。
结果按权限呈现给被测评干部和管理员，支持导出Excel归档。

这个流程里最容易遗漏的是状态的流转。测评任务从“草稿”到“进行中”到“已截止”到“已归档”，每一步都会影响前端能做什么：草稿状态下测评人是看不到任务的；截止后即使测评人点进打分页面也提示已关闭。所以我在后端单独为任务定义了状态字段，而不是用时间字段临时判断——时间判断容易出bug，比如时区不一致的时候，明明已到截止时间，页面还能打分。

1.3 明确定义“不做”的部分，项目才能按期交付

接需求的时候一定要和业务方把边界谈清楚，否则项目会被无限加需求拖死。我在这套系统里明确砍掉了几块内容：

不做纪检监督、廉政档案等强组织业务模块，只专注测评打分和结果统计；
不做多级多部门嵌套审批流，测评任务由管理员直接发起和关闭；
不做移动端App，通过浏览器适配的方式解决手机访问问题；
不做自定义表单引擎，指标模板允许增删改指标，但不支持非结构化自定义表单。

砍掉这些边界的好处是，核心路径——建任务、打分、算分、出报告——可以集中精力打磨，而不是陷入“一个页面要适配五种业务”的泥潭。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. Flask还是Django？我做了个小Demo之后果断换了赛道

标题里既有Flask又有Django，很大概率是很多人在项目起步时确实在这两个框架之间纠结过。我的实际经历是：先用Flask写了一个能打分、能提交的简易Demo，但越往后越觉得不对劲，最后切到Django重写。这个过程值得展开讲讲，因为框架选型直接决定了后续开发的效率。

2.1 Flask原型暴露了什么问题

Flask的优势大家都知道：轻量、灵活、上手快。一个空白的Flask项目可以只有几KB代码，路由写起来也确实爽。但干部测评系统不是一个小接口服务，它需要账号密码、登录会话、角色权限、数据库迁移、后台管理界面这些“标配能力”。

在我用Flask搭Demo的时候，真正卡住我的不是路由和视图，而是配套生态要自己拼装：用户认证要装Flask-Login，表单校验要装Flask-WTF，数据库迁移要装Flask-Migrate，做一个后台管理界面还得自己写一堆样板代码。每一项单独看都不难，但组合起来以后，项目结构很容易变得散乱。更要命的是Django默认自带的Admin后台，在Flask生态里几乎找不到同等成熟度的替代品。

我当时的判断是：如果目标是快速学习和验证技术，Flask完全没问题；但如果是做一个需要长期迭代、有真实用户并发访问的管理系统，Django的“全家桶”反而能节省大量时间。

2.2 Django为什么更能落地这类管理系统

Django自带的东西，几乎每一个都长在我的需求点上：

Auth模块：内置User模型、权限组、登录会话，改造成三类角色非常方便；
ORM：配合PostgreSQL/MySQL做聚合查询、条件过滤、关联统计，比写原生SQL高效很多；
Admin后台：开发期间直接用它维护指标模板、部门数据，省了一套管理界面；
迁移体系：python manage.py makemigrations 和 python manage.py migrate 在数据库变更时非常稳，不用手动维护SQL脚本。

干部测评系统里最核心的“算分”场景，用ORM的 annotate 和 aggregate 能很流畅地实现，这在Flask + SQLAlchemy里也有办法，但表达式和分组逻辑的易用性还是有差距。

2.3 Vue技术栈与PyCharm开发环境的配合

前端选Vue也是经过考虑的。Vue 3 Composition API的代码组织方式对中等复杂度的管理后台非常友好，配合Element Plus组件库，表格、表单、弹窗、树形选择器开箱即用，开发速度肉眼可见地提升。

我的开发环境组合是：PyCharm Professional + Python 3.10 + Django 4.2 LTS + MySQL 8.0，前端用Vite创建的Vue 3项目，通过代理转发解决跨域问题。PyCharm的价值在项目初期尤其明显：一键创建Django项目模板、自动识别虚拟环境解释器、内置Database工具可以直接看表结构和跑SQL。还有一个实用习惯——在PyCharm里把前端项目目录也加到同一个Project里，这样Django的settings和Vue的代码可以并排查看，改API联调的时候不用来回切换窗口。

3. 三张核心数据表：把指标、打分、匿名一次说清

数据库设计是这套系统的地基。我前后迭代了三版，最后沉淀下来的核心表结构并不复杂：一张用户表、一张模板表、一张指标表、一张测评表、一张打分记录表。但每张表里都藏着几个容易想错的点，下面逐个拆。

3.1 用户模型：一套User表解决身份问题

测评人和被测评干部在真实组织里其实是同一批人：张三在这个任务里是测评人，在另一个任务里可能就是被测评对象。所以不需要分别建“职工表”和“干部表”，直接在Django的User模型上扩展一个profile字段就够了。

python复制from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser):
    ROLE_CHOICES = (
        ('admin', '管理员'),
        ('staff', '测评人'),
        ('cadre', '被测评干部'),
    )
    role = models.CharField(max_length=20, choices=ROLE_CHOICES, default='staff')
    department = models.CharField(max_length=100, blank=True)
    employee_no = models.CharField(max_length=50, unique=True, blank=True)

这里要注意一个细节：一个人在不同测评任务里的角色是由任务配置决定的，User表上的 role 字段只决定登录后的菜单权限。简单说就是，拥有“管理员”角色的用户能进入后台配置界面，普通用户只能看到分配给自己的测评任务，而“被测评干部”这个角色是任务配置时才产生的身份，不是用户本身的固定属性。

3.2 测评模板与指标：权重和分类的存储结构

干部测评通用做法是“德、能、勤、绩、廉”五个维度，每个维度下再拆若干具体指标。模板是测评任务的骨架，指标是模板的明细。

python复制class EvaluateTemplate(models.Model):
    name = models.CharField(max_length=100)
    description = models.TextField(blank=True)
    is_active = models.BooleanField(default=True)
    created_at = models.DateTimeField(auto_now_add=True)

class Indicator(models.Model):
    template = models.ForeignKey(EvaluateTemplate, related_name='indicators', on_delete=models.CASCADE)
    category = models.CharField(max_length=20)  # 德、能、勤、绩、廉
    name = models.CharField(max_length=100)     # 指标准确名称
    weight = models.DecimalField(max_digits=5, decimal_places=2)  # 百分比权重
    sort_order = models.PositiveIntegerField(default=0)

权重字段用 DecimalField(max_digits=5, decimal_places=2)，存的是百分制数值，比如20.00表示20%。这里不建议用FloatField，浮点累加会出现0.1+0.2不等于0.3这种问题，统计分数时哪怕差0.01也会造成排名争议。维度分类是很关键的字段，前端雷达图要靠它聚集数据，后端统计每个维度的均分也要用它做group by。

权重设计上，切记不要让指标的总权重完全交给用户随意填，至少加一道“权重合计为100”的校验。不同单位可能设置不同的权重，但指标的数量建议控制在10~15个之间，太少了区分度不够，太多了测评人容易产生疲劳，打分质量反而下降。

3.3 打分记录：匿名机制靠的是约束而不是删除身份

打分记录表是整个系统里业务约束最强的一张表。

python复制class EvaluationSheet(models.Model):
    template = models.ForeignKey(EvaluateTemplate, on_delete=models.CASCADE)
    cadre = models.ForeignKey(User, related_name='evaluated_sheets', on_delete=models.CASCADE)
    status = models.CharField(max_length=20, default='pending')

    class Meta:
        constraints = [
            models.UniqueConstraint(fields=['template', 'cadre'], name='unique_template_cadre')
        ]

class ScoreRecord(models.Model):
    sheet = models.ForeignKey(EvaluationSheet, related_name='scores', on_delete=models.CASCADE)
    indicator = models.ForeignKey(Indicator, on_delete=models.CASCADE)
    evaluator_key = models.CharField(max_length=32)  # 匿名序号
    score = models.IntegerField()
    comment = models.TextField(blank=True)

    class Meta:
        constraints = [
            models.UniqueConstraint(fields=['sheet', 'indicator', 'evaluator_key'], name='unique_sheet_indicator_evaluator')
        ]

匿名机制是这个系统里最有意思的设计点之一。测评人打分后，前端不传任何身份标识，后端从JWT token里取出用户ID，再通过一个映射函数生成一个随机匿名序号（比如 AN-8F3J），写入 evaluator_key 字段。真实用户ID和匿名序号的对应关系单独存放在一张映射表里，管理员导出汇总结果时完全看不到这层关系，只有极少数超级审计权限才能追溯到具体人。

加 UniqueConstraint 约束的意义在于，哪怕前端出现重复点击、网络重试，数据库层面也会拒绝同一测评人对同一指标重复打分。这种约束在设计时就必须定下来，不然后期排查数据肯定会疯。

4. 后端API里最容易被问到的三个点：权限、去重和统计

后端我用的是Django REST Framework，整套API按照资源分成几类：任务类、指标类、打分类、统计类。开发过程中被问得最多也最容易出问题的，集中在三个点。

4.1 DRF视图集和序列化器：代码量比你想的少

用DRF的ModelViewSet写CRUD接口非常省事。比如指标模板的增删改查，十几行代码就出来了：

python复制from rest_framework import viewsets
from .models import EvaluateTemplate
from .serializers import TemplateSerializer

class TemplateViewSet(viewsets.ModelViewSet):
    queryset = EvaluateTemplate.objects.all()
    serializer_class = TemplateSerializer

但实际项目中不能这么裸奔，因为不同角色能访问的数据范围完全不同。测评人只能看到分配给自己的待办，管理员才能看到全部任务。所以必须重写 get_queryset：

python复制class TaskViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        user = self.request.user
        if user.role == 'admin':
            return EvaluationSheet.objects.all()
        # 测评人只能看到分配给自己的任务
        return EvaluationSheet.objects.filter(evaluator_mapping__evaluator=user)

这里用到的 evaluator_mapping 是一个中间关联表，用来描述“某测评人负责某张测评表”。它解决了一个多对多的关系：一张测评表需要多个测评人打分，一个测评人也会被分配到很多张测评表。Django的ManyToManyField可以自动生成这个中间表，但如果你需要在分配时记录分配时间、是否已完成等信息，建议手动建中间模型，控制力更强。

4.2 加权平均分与等级分布的统计实现

测评统计是业务方最看重的功能，也是技术上最能体现后端熟练度的地方。我用一次数据库聚合把汇总逻辑做掉了，不需要在Python里反复循环算分。

python复制from django.db.models import Avg, Sum, F, Q

def calc_cadre_stat(template_id, cadre_id):
    # 按维度分组求平均分
    dim_scores = (
        ScoreRecord.objects
        .filter(sheet__template_id=template_id, sheet__cadre_id=cadre_id)
        .values('indicator__category')
        .annotate(avg_score=Avg('score'))
    )

    # 加权总分 = 各指标均分 × 权重之和
    indicators = Indicator.objects.filter(template_id=template_id)
    total_score = 0
    for ind in indicators:
        ind_avg = (
            ScoreRecord.objects
            .filter(sheet__template_id=template_id, sheet__cadre_id=cadre_id, indicator=ind)
            .aggregate(v=Avg('score'))['v'] or 0
        )
        total_score += ind_avg * (ind.weight / 100)

    return dim_scores, round(total_score, 2)

这段代码的性能在几十人的单位完全够用。如果模板、测评人、测评对象数量上到几千，建议把加权平均的权重逻辑搬到SQL端，用 Sum(F('score') * F('indicator__weight')) / Sum('indicator__weight') 一步完成。

等级分布统计也简单：90分以上为“优秀”，80~89为“良好”，60~79为“称职”，60以下为“不称职”。用一个Case/When表达式就能在数据库里算好。

4.3 防止重复打分与权限校验的实现细节

权限控制上，我用了DRF的权限类加自定义逻辑。接口层有一个必须的校验流程：

登录用户必须通过JWT认证；
被操作的测评表必须属于该用户；
测评表状态必须是“待评分”；
如果指标分数已存在，则拒绝提交，提示“本项已评分”。

其中第3步尤其重要，因为截止时间过了以后，管理员关闭任务，测评表状态变更为“已截止”，此时任何打分请求都会被拒绝。时间判断不能放在前端，后端必须在视图层做校验，否则绕过页面直接调接口就能刷分。

这部分我吃过一次亏：最初把“是否到期”写成了前端倒计时判断，结果有测评人把电脑时间改了，过了截止时间还能继续打分。后来把校验逻辑挪到后端，以服务器时间为准，这个问题彻底消失。

5. Vue3 + Element Plus搭建的前端：打分页和看板页是灵魂

前端页面我用了Vue 3 + Vite + Element Plus + Pinia + Vue Router的组合。整体上页面数量不多，但两个页面尤其关键：测评打分页和结果看板页，用户体验好不好就看这两页。

5.1 页面骨架：路由守卫、Token管理和角色菜单

前端整体结构比较常规：登录页、测评待办列表页、打分页、结果看板页、管理后台页。路由守卫是最基础但必须做对的部分。

javascript复制// 路由守卫：未登录跳转到登录页
router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.path !== '/login' && !token) {
    next('/login')
  } else {
    next()
  }
})

这个逻辑虽然简单，但要记得在响应拦截器里统一处理token过期的情况——axios拦截器收到401状态码，清除本地token并强制跳转登录页。经验之谈，这个逻辑不做的话，用户token过期后点任何按钮都在报错，排查起来很头疼。

菜单的显隐根据用户角色动态生成。管理员能看到“创建测评任务”“结果总览”，普通测评人只看到“我的待办”和“我的结果”。角色信息从登录接口返回，存在Pinia里。

5.2 打分页面的交互设计：一张表格搞定所有指标

打分页是测评人使用频率最高的页面，交互上我遵循了“一屏完成所有操作”的原则。

页面结构是一张表：左侧是维度分组（德、能、勤、绩、廉），中间是具体指标名称，右侧是打分输入框，表尾是评语文本域。打分控件用了 el-input-number，最小值0，最大值100，步长1。这样测评人只需要从上到下一路填下去，最后点提交。

vue复制<template>
  <el-table :data="indicators">
    <el-table-column prop="category" label="维度" width="90" />
    <el-table-column prop="name" label="指标" />
    <el-table-column label="得分" width="180">
      <template #default="{ row }">
        <el-input-number v-model="scores[row.id]" :min="0" :max="100" :step="1" />
      </template>
    </el-table-column>
  </el-table>
  <el-input v-model="comment" type="textarea" placeholder="综合评价意见（选填）" />
  <el-button type="primary" @click="submitScores" :loading="submitting">提交测评</el-button>
</template>

提交前要做的校验有三层：一是所有必填指标是否已经打分；二是分值是否在0~100区间；三是再次弹窗确认“提交后不可修改”。确认弹窗可以拦截一大部分误操作，实测非常有效。

5.3 结果看板：雷达图和柱状图的实时更新

结果看板页使用ECharts展示统计结果。被测评干部登录后看到的是自己的个人报告：一个雷达图显示“德能勤绩廉”五个维度的得分，一个横向柱状图显示各个具体指标的得分，下面再附上管理员填写的综合评价意见。

雷达图的配置是ECharts里比较常见的写法：

javascript复制const radarOption = {
  radar: {
    indicator: dimensions.value.map(d => ({ name: d, max: 100 })),
    radius: '65%'
  },
  series: [{
    type: 'radar',
    data: [{
      value: dimensionScore.value,
      name: '综合测评',
      areaStyle: { color: 'rgba(64, 158, 255, 0.2)' }
    }]
  }]
}

这里的 dimensions.value 是五个维度的名称列表，dimensionScore.value 是后端统计接口返回的各维度平均分数组。雷达图的直观效果很好，被测评人一眼就能看出自己在哪个维度相对较弱。

管理员端看板做成任务维度：选择某个测评任务后，展示该任务下所有被测评干部的总分排名表、优秀率、各维度平均分对比柱状图，以及一键导出Excel的按钮。导出用后端生成Excel文件返回下载链接，前端非常简单；后端用 openpyxl 写一个导出函数，20分钟就能搞定。

6. 从PyCharm到生产部署：一趟跑完的完整流程

开发环境和部署环境之间有一道鸿沟，这一步最容易出各种“本地好好的，上了服务器就崩”的问题。我把自己从PyCharm准备环境到部署上线的完整流程和坑点整理一下。

6.1 PyCharm里的环境准备与常用配置

用PyCharm创建项目时，我是这样配置的：

新建项目时选择Django模板，PyCharm会自动生成Django标准目录结构；
Python解释器选择虚拟环境（Venv），Python版本固定用3.10或3.11，Django官方支持的LTS版本是4.2；
在 requirements.txt 里锁定依赖版本，包括Django、djangorestframework、django-cors-headers、PyMySQL、openpyxl等；
安装MySQL后，在PyCharm的Database面板里配置连接，直接在IDE里查看和调试表数据。

PyCharm有一个很实用的功能是Run Dashboard，可以同时管理Django后端（runserver）和前端Vite开发服务器（npm run dev）。两个服务一起跑，改前端代码就自动热更新，联调效率高很多。

6.2 从开发环境到测试服务器：部署流程与配置检查

由于系统是部署到单位内网服务器，没有公网IP，部署方案比较简单：Django用 runserver 可以撑住几十人的并发，更稳妥的方式是用 gunicorn 启动多worker，前面再用Nginx做反向代理。

部署前需要重点检查的配置：

DEBUG = False，并把 ALLOWED_HOSTS 配置为实际访问域名或IP；
生成新的 SECRET_KEY，不要把开发环境的密钥带上线；
CORS配置，将前端的域名加入白名单，否则浏览器会拦截接口请求；
静态文件收集：执行 python manage.py collectstatic，把Django Admin和前端静态资源放到指定目录；
数据库备份策略，至少每天自动备份MySQL数据。

我的nginx配置长这样，很基础但够用：

nginx复制server {
    listen 80;
    server_name 192.168.1.10;

    location /static/ {
        alias /opt/eval_system/static/;
    }

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

前端构建后放在另一个静态域名下，跨域访问API。如果前端也放在同一台服务器的nginx上，就配置一个 location / 指向前端dist目录，location /api/ 反向代理到Django，这样还可以避开跨域问题。

6.3 上线后遇到的两个真实问题与解决过程

这个系统上线后遇到两个值得记录的问题。

第一个问题是并发打分导致数据覆盖。第一轮测评时有几个部门同时提交，出现了同一个测评人提交了两次、后一次覆盖前一次的情况。虽然有UniqueConstraint在数据库层兜底，但因为前端提交请求时没有做“提交中”的锁状态，网络卡顿时用户连点两次，两条请求都进到了后端，后一条把前一条覆盖了。解决方案是在前端提交按钮加loading状态，后端再用事务包裹“插入ScoreRecord前先检查是否已存在”的完整流程。

第二个问题是汇总统计和打印排版不兼容。汇总结果页在浏览器里显示正常，但导出Excel后，评语里的换行符和特殊字符会错乱，导致打印出来排版不齐。后来导出的代码里统一做文本清洗，把换行替换为空格、把全角括号保留、去掉多余空白字符，打印效果就好了。

开发这套系统的过程中，我还有一个体会挺深：测评这类项目，最容易出问题的不是技术难点，而是业务边界和流程状态没想清楚。框架选型、表结构、前端组件这些技术问题都能解决，但“测评人在截止后还能不能打分”“没提交之前万一中途退出怎么办”“同一测评人重复打分要不要允许”这类问题，一定得在开发前就和业务方逐个确认清楚。技术上的坑可以被测试发现，业务上的坑往往要等真实使用时才暴露，而那时候改起来成本和压力都大得多。