手上刚完成一套高校人事管理系统正好趁热做个复盘。项目不算大但“django-flask基于python的高校人事管理系统”这个标题单看容易让人犯迷糊到底是选Django还是Flask我实际落地的时候Django是主框架Flask被安排成独立报表服务两边共用同一个数据库接口层面也做了明确切分。这么拆分不是炫技而是业务逼出来的人事系统的琐碎管理功能、权限体系、审批流都适合交给Django这种“全家桶”框架而月末集中爆发的复杂报表导出任务单独拆出去用Flask跑既不拖累主工程后续资源不够还能单独扩容。这套系统解决的问题很直接让学校人事处彻底告别“Excel传来传去”的状态。教职工信息统一维护入职离职异动走线上审批工资数据按权限分层可见各类统计报表自动生成年底考核资料也不再翻遍聊天记录找版本。它适合正在做毕业设计或课程设计的同学参考也适合打算给学校、事业单位做类似管理系统的开发者借鉴。下面把这轮的选型、建模、编码、部署过程连同踩过的坑一起写出来。1. 项目整体设计与选型思路1.1 先理清业务边界再谈框架选型很多人一上来就在Django和Flask之间纠结其实框架之争反而是最后的问题。人事管理系统表面看简单拆开看至少有六大块人员库、组织架构、考勤、薪资、异动审批、统计报表。每一块复杂度差异非常大。人员库和部门树是基础数据操作频繁考勤和薪资是敏感数据权限边界必须卡死异动审批流程长、状态多需要严谨的状态机统计报表平时没人看月末全员一起点又慢又卡就会被投诉。我拿到需求之后先画了一张业务清单把每个模块的操作频率、数据敏感度、复杂度列清楚。人员库要天天用要求响应快导入导出要顺手审批流是低频操作但每一步操作都要留痕报表是月底集中访问要求能扛住瞬时并发。这张清单直接决定技术选型而不是先确定框架再倒推功能。高校环境还有个隐藏约束网络环境比一般企业复杂有些楼宇之间网段隔离信息办也可能提供统一身份认证服务。这些在一期未必用得上但数据库字段和认证接口必须提前留好扩展位否则后期对接统一身份平台的时候改起来会非常痛。1.2 Django 做主体Flask 做配套报表服务为什么主体用Django而不是Flask主要原因是人事系统业务逻辑密集Django的ORM、迁移、Admin后台、认证模块都是开箱即用的开发效率高出一大截。Flask虽然灵活可控但用户管理、权限、表单、后台管理都要自己搭或者拼一堆第三方库搭到一半就会发现工作量直接翻倍。那Flask放在哪我把它放在报表服务里。人事系统的报表场景很特殊月底要导出各学院花名册、职称结构统计、年龄分布分析Excel模板往往来自其他科室字段顺序完全固定。如果这些报表逻辑全部写进Django主工程报表相关的模板代码、Excel处理库会跟业务代码纠缠在一起以后谁改谁头疼。单独做一个Flask服务挂在同一个MySQL和Redis上对外只暴露几个报表接口既能复用数据又能独立部署、独立扩容。有人会问为什么不用cron脚本或者Django的管理命令直接跑关键问题是报表通常要人工选择条件例如“导出信息学院2024年以后入职、副高以上职称人员”这不是一句固定命令能解决的需要可交互的接口。而文件生成是耗时操作适合通过Redis队列把任务参数交给Flask Worker处理比在主进程里开线程池更可控也不容易出现内存泄漏把主服务拖垮。1.3 技术栈与版本选型参考这套系统实际使用的核心工具和版本如下供后续参考组件版本承担角色Python3.10基础运行环境Django4.2 LTS主业务框架、ORM、认证、AdminFlask2.3报表服务、文件导出MySQL8.0主数据库Redis7.x缓存、异步任务队列Nginx Gunicorn1.24 / 21.xWeb服务与反向代理选Django 4.2是因为它是当时比较稳的LTS版本不仅安全更新周期长第三方库兼容性也更好。Python选了3.10而不是更新的版本是因为部分内网服务器环境特殊老版本编译依赖更容易满足。这里想提醒一句千万别以为“Python版本越新越好”真到部署阶段服务器上能不能装、编译是否缺依赖才是决定成败的地方。2. 数据库设计与核心数据模型2.1 人事系统绕不开的几张核心表把人事处日常工作一步步拆开数据库里最核心的就是这几张表员工主表、部门表、岗位表、异动记录表、薪资表、用户账号表。我的设计原则是“主表精简、变更留痕、权限关联独立”。员工主表存放教职工的静态基础信息例如工号、姓名、性别、出生日期、学历、学位、入职时间、部门、岗位、职称、政治面貌、联系方式等。部门表负责组织架构高校通常是多级树结构比如学校下面分学院、处室学院下面再分系部和教研室。异动记录表负责记录一个人从入职到离职的全过程比如转岗、升职、调离、退休。薪资表存储月度工资相关数据但绝不直接和员工账号权限绑定。用户账号表则单独存放系统登录账号并关联角色和权限。有人可能会问“员工基本信息直接放在用户表里不就行了吗”不行。业务账号和人事主数据必须分开因为在职员工、离职员工、临时用工、外聘人员并不都需要登录系统但他们的基本信息都必须存在于员工主表中。账号只是某个人访问系统的一把钥匙不该和基础档案绑死。2.2 员工主表设计的关键细节员工主表是这个系统的地基设计得不好后面所有功能都会别扭。我实际进行过两次比较大的字段调整总结经验如下。工号字段要加唯一约束并且不能允许为空。身份证号不要做主键不要让用户手动输入身份证号因为人工手输极容易出错重号、错号都会给后续统计带来麻烦。工号最好由系统生成比如根据入职年份和部门编号组合生成后不可变更。部门、岗位、职称这些信息在员工主表里存放外键关联而不是直接存文本。文本的好处是显示方便坏处是部门改名字或者岗位统一调整之后历史数据对不上。用外键存ID配合独立的部门表和岗位表展示时再关联查询数据才可控。员工状态字段我建议用整型而不是字符串。0表示在职1表示离职2表示退休3表示停薪留职4表示试用期。为什么要用数字因为字符串依赖记忆容易写错而数字可以配合常量类统一管理代码里写清楚了可读性完全没问题。同时保留一个激活标记字段实现逻辑删除。动态属性推荐使用JSON字段。高校人事系统最麻烦的就是字段不固定今天要采集家庭住址明天要补社保卡号后天又可能增加一项海外经历。把这些不确定字段放到JSON字段里比频繁改表结构省事得多。Django从3.1之后原生支持JSONFieldMySQL 5.7之后也有JSON类型使用非常顺手。2.3 部门树和异动记录的建模部门表设计时我比较推荐两种方案之一。第一种是使用django-mptt这类现成树形库它把父节点、子节点关系封装好查询也非常方便。第二种是自关联parent字段加path字段path字段存储从根节点到当前节点的完整路径例如“/1/23/45/”这样查询某个部门下所有子部门时直接做前缀匹配即可。高校人事管理系统里部门树通常不会频繁变化但会频繁查询。我用的是自关联加path字段在path字段上建索引统计和权限过滤时性能很稳定。担心树层级太深、路径字符串过长的问题不会出现高校组织架构一般四到五级就到头了。异动记录表的核心字段是员工ID、异动类型、原部门、新部门、原岗位、新岗位、生效日期、审批状态、申请人、审批人、审批意见、审批时间。这里最容易踩的坑是“直接修改员工主表不记录变更历史”。如果不记录历史三个月后根本查不到“谁在几月从教学岗转到行政岗”的准确时间点审计也找不到依据。每次异动必须在主表更新当前状态同时在异动记录表写一条完整记录。状态流转则需要单独建一个审批记录表每过一道审核就追加一行。2.4 为什么一定要留审计字段很多初学项目的人建表时只关注业务字段很容易忽略审计字段。我在这套系统里每张表都加了这几个字段创建人、创建时间、更新人、更新时间、逻辑删除标记。看起来是小事真到出问题的时候能救命。曾经有一次人事处的老师反馈说“某个教职工的职称被改错了”如果不记录更新人你根本不知道是谁改的、什么时候改的。有了updated_by和updated_at直接翻审计日志就能定位再配合操作日志表还能追溯修改前后的字段值。另外metadata逻辑删除标记配合默认过滤器既能防止误删数据又能在恢复数据时留有余地。3. 核心功能模块实现要点3.1 登录认证与权限控制高校人事系统的权限场景比一般企业系统要复杂。除了“人事处管理员可以看所有人”这种粗粒度权限还有大量数据级权限各学院的院长只能看本学院员工院系人事秘书只能维护本学院人员教师本人只能看自己的部分信息。实现上我没有直接用Django默认的Group硬编码角色而是建了角色表和权限表采用RBAC模型。用户关联角色角色关联权限然后再在代码层做数据范围过滤。数据范围通过用户模型上的一个字段标识比如a负责的部门就是部门树中某一个节点及其子部门。认证这块我预留了统一身份认证的对接入口单独写了一个认证后端处理校内统一账号体系。在没有接入统一认证之前先用Django自带认证跑通业务等接口条件具备再替换。这样做的意义是系统上线初期不会被对接进度卡住后期对接时也不需要推翻既有代码。3.2 员工信息的Excel批量导入导出学校人事处最常提的需求就是“把某某系统导出的Excel表导进系统”。这功能看着简单做起来却容易翻车。我使用openpyxl处理Excel文件因为对xlsx格式支持最稳而且不依赖Office环境。导入流程分成四步走。第一步下载模板模板列头必须和系统字段一一对应第二步读取用户上传的文件先校验文件是否损坏、列头是否匹配第三步逐行校验数据比如工号不能为空、身份证号格式是否正确、部门名称能否在系统中找到第四步把有效数据批量写入数据库错误行则汇总成错误清单。这里很关键的一点是不要边读边写。正确做法是先全部校验完再统一提交事务。否则前面十行写进去了后面有一行格式错误整个导入结果就会出现半成功状态用户很难理解。我的做法是只要发现错误行就整体回滚把错误清单导出给用户修改后重新上传。导出Excel则相对简单但要注意大数据量下的内存问题。导出全量人员名单时几万条数据一次性塞进内存再生成Excel很容易出现明显的卡顿甚至崩溃。正确做法是分页查询或者使用流式写入。我采取的方案是用pandas分块读取然后通过openpyxl的write_only模式写入文件。3.3 人事异动的审批流状态机审批流是人事系统里最容易写乱的部分。我把它抽象成一套状态机逻辑状态包括待提交、待一级审核、待二级审核、已完成、已驳回、已撤回。操作包括提交、通过、驳回、撤回、作废。为了不引入复杂的工作流引擎我直接用了一个整型状态字段再写一个状态转移校验函数。每次操作前先判断当前状态是否允许该操作不允许就直接抛异常。这样设计的好处是逻辑直观调试容易状态流转不清晰时会很快暴露问题。异动审批的工作流一个很重要的端点是驳回之后应该回到提交人上一次编辑的状态而不是直接回到“待提交”。我在状态机里专门加了一个“驳回状态”概念提交人可以在原有表单基础上修改后重新提交。另外所有审批操作必须记录操作人、操作时间和意见这些信息放在审批记录表里后续生成审批轨迹时直接按时间排序即可。3.4 薪资模块的数据脱敏薪资数据是全系统敏感度最高的部分这一块最容易出安全事故。我的处理方式是分层设计数据库存储完整数据Web接口层严格按角色过滤字段前端展示层再做一次脱敏。具体做法是给薪资表增加一个权限等级字段只有具备“薪资查看”权限的角色才能看到具体金额普通教职工在工资查询页面只能看到应发、实发等汇总数字不能看到其他同事的工资明细。导出工资单必须走审批流程在生成的Excel文件里增加水印和自动清除功能控制文件的传播范围。实际过程中我还做过一次部门数据越权的修复。当时一个学院的人事秘书账号理论上只能看本学院人员但因为列表查询条件里漏加部门过滤导致能翻到其他学院的人员工资。这个问题提醒我凡是涉及数据级权限的功能在代码审查时必须逐一核对查询条件不能只依靠前端的按钮隐藏。3.5 统计报表做到秒开人事系统里的统计报表很多例如部门人员数、学历结构、职称结构、年龄分布、入职年限分布等。最初直接写聚合查询数据量小的时候毫无压力但到了几万人规模加上多级部门筛选页面最夸张时会达到两秒以上。后来我做了几个调整。第一常用报表每天凌晨用定时任务预生成到Redis缓存用户在Web端直接读缓存。第二月度大报表在月末生成结果并固化到数据库表生成一次之后所有查询只读结果表。第三真正需要实时数据的场景使用数据库原生聚合SQL避免在Python层循环计算。这套方案上线之后绝大多数报表都能在几百毫秒内打开月末高峰期也没有再出现明显卡顿。经验就一句话报表数据优先考虑“预计算”而不是“实时查询”用户根本不关心数据是不是一秒前生成的他们只想知道能不能快点看到结果。4. 关键代码与实操过程4.1 项目初始化与环境准备项目落地第一步是创建虚拟环境并安装依赖。这个环节看起来简单但在高校内网环境里经常翻车因为部分依赖包需要编译编译过程缺依赖就失败。我实测下来比较稳的做法是先安装基础编译工具再安装Python包。python -m venv venv source venv/bin/activate pip install --upgrade pip setuptools wheel pip install django4.2 flask2.3 mysqlclient openpyxl redis gunicorn django-admin startproject hr_platform . python manage.py startapp hr_app python manage.py startapp orgmysqlclient这个包在内网环境很容易编译失败如果服务器不方便装编译环境可以直接改pymysql或者用PyMySQL替代并在项目的__init__.py里做一些额外操作。我这里图省事开发环境直接用mysqlclient生产环境用同一套。初始化项目之后第一件事就是改settings数据库配置把默认的SQLite改成MySQL。连接参数放在配置文件中别写在代码里。DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: hr_platform, USER: hr_user, PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { charset: utf8mb4 } } }4.2 员工模型与Admin后台员工模型是我最先写的一块核心字段用Django模型定义如下省略了部分扩展字段。from django.db import models class Department(models.Model): name models.CharField(max_length100, verbose_name部门名称) parent models.ForeignKey( self, nullTrue, blankTrue, on_deletemodels.CASCADE, verbose_name上级部门 ) path models.CharField(max_length255, verbose_name路径) sort models.IntegerField(default0, verbose_name排序) class Meta: ordering [path, sort] class Employee(models.Model): emp_no models.CharField(max_length20, uniqueTrue, verbose_name工号) name models.CharField(max_length50, verbose_name姓名) gender models.CharField(max_length10, choices[(M,男),(F,女)], verbose_name性别) birth_date models.DateField(nullTrue, verbose_name出生日期) id_card models.CharField(max_length18, nullTrue, blankTrue, verbose_name身份证号) department models.ForeignKey(Department, on_deletemodels.PROTECT, verbose_name所属部门) position models.CharField(max_length50, verbose_name岗位) title models.CharField(max_length50, nullTrue, blankTrue, verbose_name职称) status models.IntegerField(default0, verbose_name状态) extra models.JSONField(defaultdict, verbose_name扩展信息) created_at models.DateTimeField(auto_now_addTrue) updated_at models.DateTimeField(auto_nowTrue) def __str__(self): return f{self.emp_no}-{self.name}这里有几个细节值得说明。部门外键我用了on_deletemodels.PROTECT意思是部门下面还有员工时禁止直接删除部门。这个策略非常适合人事系统防止误删组织节点以后员工记录变成无根浮萍。员工状态字段使用整型和前面说的数据模型设计对应代码里用枚举常量类做映射。Admin后台注册模型后人事处的老师可以直接在后台维护基础数据不用专门开发全套管理界面。from django.contrib import admin from .models import Employee, Department admin.register(Employee) class EmployeeAdmin(admin.ModelAdmin): list_display (emp_no, name, department, position, status) search_fields (emp_no, name, department__name) list_filter (status, department)4.3 Excel导入的代码套路Excel导入逻辑不复杂但细节很多。我贴一段基于openpyxl的核心实现思路具体字段校验和业务逻辑可根据自己系统的模型调整。import openpyxl from django.db import transaction def import_employees(file_obj): wb openpyxl.load_workbook(file_obj, data_onlyTrue) ws wb.active headers [cell.value for cell in ws[1]] required [工号, 姓名, 所属部门, 岗位] for r in required: if r not in headers: raise ValueError(模板缺少必填列: %s % r) rows [] errors [] for row in ws.iter_rows(min_row2, values_onlyTrue): data dict(zip(headers, row)) emp_no str(data.get(工号) or ).strip() name str(data.get(姓名) or ).strip() if not emp_no or not name: errors.append(第%s行: 工号和姓名不能为空 % row[0].row) continue # 部门转外键 dept_name str(data.get(所属部门) or ).strip() from .models import Department try: dept Department.objects.get(namedept_name) except Department.DoesNotExist: errors.append(第%s行: 部门不存在 %s % (row[0].row, dept_name)) continue rows.append(Employee(emp_noemp_no, namename, departmentdept)) if errors: # 整体回滚不写入任何数据 raise ValueError(\n.join(errors)) with transaction.atomic(): Employee.objects.bulk_create(rows, ignore_conflictsFalse) return len(rows)这段代码只演示了核心流程实际生产还需要补充身份证号格式校验、日期格式转换、重复工号检测、错误行号准确定位等。整体回滚的逻辑一定要保留宁可导入失败也不能制造半成功脏数据。4.4 审批状态机的核心实现状态机我封装在一个独立类里用字典定义状态转移关系。每次操作都对当前状态做校验再更新状态并记录历史。class ApprovalState: DRAFT 0 PENDING_FIRST 10 PENDING_SECOND 20 APPROVED 30 REJECTED 40 WITHDRAWN 50 TRANSITIONS { DRAFT: {submit: PENDING_FIRST}, PENDING_FIRST: {approve: PENDING_SECOND, reject: REJECTED, withdraw: WITHDRAWN}, PENDING_SECOND: {approve: APPROVED, reject: REJECTED, withdraw: WITHDRAWN}, REJECTED: {submit: PENDING_FIRST}, WITHDRAWN: {submit: PENDING_FIRST}, } staticmethod def can_transit(current, action): return action in ApprovalState.TRANSITIONS.get(current, {})这段代码的好处是审批流的规则全部用一张表表达后续新增一个“会签”步骤也只需要在这个字典里加状态和动作不需要拆改大量if-else。审批记录表独立记录每一步操作最终展示审批轨迹时直接查历史记录即可。4.5 Flask报表服务如何配合DjangoFlask报表服务不承担业务展示只处理一类任务接收请求参数生成Excel文件。它的入口接口接收参数和任务ID处理完以后把文件地址回写Redis前端轮询拿到结果后显示下载链接。from flask import Flask, request, send_file import redis import json import os app Flask(__name__) r redis.Redis(host127.0.0.1, port6379, db0) app.route(/report/export, methods[POST]) def export_report(): data request.get_json() report_type data.get(report_type) dept_id data.get(dept_id) file_path generate_excel(report_type, dept_id) r.lpush(report_result, json.dumps({task_id: data.get(task_id), path: file_path})) return {status: ok} def generate_excel(report_type, dept_id): # 这里执行数据库查询和Excel写入 # 临时文件生成完成后返回路径 return /tmp/report_result.xlsx if __name__ __main__: app.run(port5001)生产环境不建议用Flask自带服务器我实际是用Gunicorn单独跑这个报表服务。Django主服务把任务参数写入Redis队列Flask服务从另一个端口监听并处理。如果报表任务量上升只需要多起几个Flask进程不碰Django主工程部署和扩容都清晰。5. 常见问题与排查技巧实录5.1 部门树查询慢部门树在数据量几百个节点时速度完全没有问题可我第一次做出来的版本在页面部门选择下拉框里很卡。原因是前端把整棵部门树递归渲染成所有选项加上权限过滤后每次都做多次数据库查询。后来我把部门树预加载到Redis缓存缓存一次半小时或一天刷新一次。同时前端改成懒加载模式点开第一级才加载子级。优化后部门选择框从一两秒降到即时响应。很多问题的根源不在于数据库多复杂而是查询次数太多能减少数据库交互就尽量减少。5.2 员工导入时身份证号变成科学计数法Excel在处理18位身份证号时如果单元格格式不是文本会自动变成科学计数法。这个问题从Excel导入系统时几乎必现。我在导入函数中做了强制的字符串转换读取单元格时用str()包一层并且去掉可能出现的后缀内容。更稳妥的办法是要求用户先下载系统模板在模板里把身份证列设置为文本格式同时提供打开文件时的类型检查。自己开发时千万别把身份证列自动识别为数字类型否则导入导出反复转换几次数据就全乱了。5.3 权限控制遗漏了数据级范围这是我自己踩过的一个比较严重的坑。当时已经实现了角色权限每个学院人事秘书也能登录系统列表页按钮也正常显示。但深挖查询接口时发现学院人事秘书的查询条件里漏掉了部门过滤理论上可以翻到其他学院的员工工资数据。这类问题最难的地方在于前端页面显示正常不点开具体接口根本发现不了。我最后在全项目做了一次权限专项审查把所有涉及员工和薪资的接口逐一核对是否携带了数据范围过滤。这里给一个建议凡是涉及敏感数据的接口必须在服务端查询语句里拼接数据范围条件不能只依赖前端隐藏入口。5.4 定时任务重复执行报表预生成任务第一次上线时我用crontab每分钟跑一次检查结果某一天的月度报表任务被同时触发了两次导致重复写入数据库结果表。后来我在任务入口增加了Redis分布式锁只有获取到锁的实例才执行任务执行完毕后释放锁。import redis r redis.Redis(...) lock_name report_monthly_lock if r.set(lock_name, 1, nxTrue, ex600): try: generate_monthly_report() finally: r.delete(lock_name) else: print(已有任务在运行本次跳过)同样的问题也会出现在多个Gunicorn Worker并发启动定时任务时分布锁是简便有效的方案。5.5 数据库迁移把生产库搞挂曾经有一回为了给员工主表加一个扩展字段直接在生产库执行了ALTER TABLE结果因为表里有几万条数据锁表了十几分钟把正在上班使用的页面全部卡住。后来所有数据库变更都改成Django迁移文件方式在低峰期执行并且先备份。SQLite和MySQL很多语法细节不同比如字段类型、索引方式、字符串比较规则开发环境没问题不代表生产环境没问题。如果项目起步用的是SQLite上线前必须用真实数据量做一次迁移演练千万别直接拿生产库练手。6. 部署上线与运维避坑6.1 服务器环境初始化这套系统最终部署在内网一台Linux服务器上使用Python3.10、MySQL8、Redis7、Nginx。环境初始化步骤大致如下sudo apt update sudo apt install -y python3.10 python3.10-venv python3.10-dev \ build-essential nginx mysql-server redis-server之后创建专门的系统账号来运行应用不要用root直接跑Python服务。应用目录、日志目录独立出来权限分配清楚这样出问题的时候排查往往会更容易。6.2 Gunicorn与Nginx配置参考Django主服务用Gunicorn跑建议Worker数根据CPU核数配置。我这边是四核服务器Gunicorn配置使用了四个worker加两个线程。配置参考如下gunicorn hr_platform.wsgi:application --bind 127.0.0.1:8000 --workers 4 --threads 2 --timeout 120Nginx反向代理配置静态文件和媒体文件由Nginx直接服务动态请求转发给Gunicorn。server { listen 80; server_name hr.example.local; location /static/ { alias /data/hr_platform/static/; } location /media/ { alias /data/hr_platform/media/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }Flask报表服务独立跑在5001端口由另一个Nginx location转发到内部端口或者不对外暴露只允许内网服务调用。6.3 备份、日志与安全加固数据备份是这类系统的保命底线。我配置了每天凌晨的MySQL逻辑备份保留最近三十天。备份文件直接同步到另一个文件服务器避免本机硬盘故障导致数据全丢。日志方面把Gunicorn的访问日志和错误日志分别拆分Django内部错误走标准logging输出到文件。排查问题的时候日志字段越细分越方便建议把用户ID、操作时间、请求路径、响应状态都记录下来。安全加固虽然烦琐但绝不能省数据库账号禁止使用过于简单的密码Django的SECRET_KEY和数据库密码放在环境变量文件里不要提交到代码仓库Nginx层面关闭不必要的目录浏览系统对外只开放80/443端口其他端口全部走内网。6.4 这类项目的后续扩展方向让我按照目前系统的开发情况给几条参考的方向。第一是接入学校的统一身份认证替换掉现在的本地账号体系以后老师不用单独记人事系统密码这是学校场景里非常实际的刚需。第二是增加消息通知模块审批通过、工资发放、考核结果都能通过短信或内部消息推送给本人。第三是沉淀报表模板把各二级学院经常使用的固定表格模板整理成在线配置让人事处自己调整字段而不是每次改模板都找开发。其实这类系统的技术门槛不算高真正花时间的都在业务理解和数据安全上。如果你打算自己动手做一套我的建议是先把审批流和数据权限这两块设计清楚其他功能可以边做边补。系统上线以后被找得最多的一定不是某个功能不好用而是“为什么他看到了不该看的数据”或者“这个审批单怎么流转乱了”能把这两件事守住系统就算成功了一大半。