REECHO大鱼总舵前两天有人问我，公司想上一套员工考勤系统，用什么方案最划算。我的回答就四个字：Flask + Python。不是因为它最炫，而是因为它最省事——考勤打卡、请假审批这类企业内部管理系统，业务逻辑并不复杂，最怕的是框架本身太重、改起来费劲。Flask这种微框架，起步快、结构灵活，配合SQLAlchemy做数据持久化，一个人两三周就能搞定一版能用的系统。这篇文章就把我实际开发这套基于Python Flask的考勤打卡请假管理系统的完整思路和关键代码拆开讲，从数据库设计、打卡逻辑、请假审批流到部署上线的坑，一次性说清楚，适合正在做课设、毕设，或者准备给公司搭内部工具的朋友直接抄作业。
1. 项目整体设计与思路拆解
1.1 考勤系统的核心业务到底有哪些
做系统之前，先别急着写代码，把业务理清楚比什么都重要。我接了这么多年内部管理系统，考勤这件事看起来简单，真正落到纸面上，核心业务其实就三条线：打卡记录、请假申请、考勤统计。
打卡这条线的重点是"上下班时间怎么算"。公司规定9点上班、18点下班，那员工在9点之后打卡算迟到，18点之前打卡算早退，但这里面有个细节容易被忽略——要不要允许弹性工作时间？一顿操作之后你会发现，如果规则写死了，改起来全是眼泪，所以我的建议是把上下班时间、迟到容忍分钟数这些都做成配置项，放在一个单独的配置表或者系统设置表里，而不是写死在代码里。项目经理改需求的时候，你只需要改一条数据库记录，不用重新发版本。
请假这条线要解决的其实是"状态流转"。员工提交申请、直属领导审批、HR备案，一套流程走下来，状态无非就是待审批、已通过、已拒绝、已撤销。很多新手容易把审批逻辑和请假逻辑混在一起写，这是个大坑。我习惯把审批动作单独拆出来，谁审批、审批结果、审批意见、审批时间，都记录在一张审批记录表里，这样就算以后要支持多级审批，也只需要加记录，不动主表逻辑。
考勤统计更不用说了，它依赖的是前两条线的数据质量。如果打卡记录和请假记录是脏数据，统计出来的报表就没有任何参考价值。所以我会在月度统计的时候，先做一次数据校验，把缺卡、重复卡、请假未审批通过这些异常情况过滤出来，让HR去人工确认，而不是让系统直接给出一个"漂亮但不可信"的报表。这个思路，是后来我踩了无数坑才总结出来的。
1.2 为什么选Flask而不是Django
选框架这件事，我经历过很多次"选错框架导致项目烂尾"的惨痛教训。在Flask和Django之间做选择，我的判断标准就两条：项目规模和学习成本。考勤系统这种场景，通常就是几十个员工、几万条考勤记录，根本用不上Django那种全家桶式的重量级武器。Flask的轻量是我最看重的，它只帮你把路由和请求响应管好，剩下的自由发挥空间很大，数据库、表单、登录认证这些模块，你需要哪个装哪个，不会有一堆用不上的功能堆在那里增加心智负担。
还有一个实际原因：Flask的第三方生态足够成熟。Flask-SQLAlchemy管数据库，Flask-Login管登录会话，Flask-WTF管表单和CSRF防护，Flask-Migrate管数据库迁移，这几个组合起来，已经覆盖了考勤系统95%的需求。剩下的5%，比如导出Excel，用openpyxl或者pandas都能解决，根本不愁找不到现成的方案。
另外，Flask对新手太友好了。如果你是在校学生要做课设或者毕业设计，Flask的入门曲线比Django平缓不少，你不需要一开始就理解Django的MTV模式和后台管理机制，只要会写Python函数，就能在半小时内跑通第一个页面。这一点对时间紧迫的项目来说，优势是决定性的。
1.3 数据库设计与表结构规划
数据库设计是我的老本行，也是翻车最多的环节。考勤系统一般从五张表起步：员工表（employee）、部门表（department）、打卡记录表（attendance）、请假表（leave）、审批记录表（leave_approval）。这五张表的关系是：部门一对多员工，员工一对多打卡记录，员工一对多请假单，请假单一对多审批记录。
员工表我习惯叫employee，字段包括id、employee_no（工号）、name、password_hash、department_id、role（角色，0是员工、1是管理员）、hire_date、is_active。这里有个小提醒：密码字段一定不要存明文，用werkzeug.security的generate_password_hash和check_password_hash来处理，这是最基本的安全底线。
打卡记录表attendance是这个系统的核心，字段包括id、employee_id、work_date（日期）、clock_in_time（上班打卡时间）、clock_out_time（下班打卡时间）、status（正常、迟到、早退、缺卡、异常）、created_at。这张表的设计有个关键点：为什么不直接每条打卡记录一行，而要把上下班时间放在同一行？因为考勤统计的粒度是"人/天"，如果上下班各一条记录，月底统计的时候就要做行转列，写SQL麻烦不说，效率也低。我甚至在很多项目里直接把work_date设为employee_id和work_date的联合唯一索引，从数据库层面防止同一天重复打卡记录。
请假表leave的字段就比较常规了：id、employee_id、leave_type（事假、病假、年假、调休）、start_time、end_time、reason、status、apply_time。请假时间的存储格式值得注意，请假是精确到天的还是精确到小时的？如果是小时级别的，日期时间字段用DateTime没问题，如果只是天级别的，用Date就够了，别过度设计。
审批记录表leave_approval其实是考勤系统里最容易被忽视的一张表，很多人直接在请假表上加一个approver_id和approved_time字段就完事了，但一旦出现"审批人被驳回后要重新提交再审批"的场景，原来的设计就崩了。多对多的审批关系用独立的审批记录表承载，是最稳的做法。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与项目初始化
2.1 Python环境搭建的几个坑
很多人倒在了环境搭建这一步，尤其是Windows用户。我个人的建议是，直接装Python 3.8以上的版本，别用3.7以下的老版本，也别追最新的3.13，因为有些第三方库的编译版本还没跟上。到官网下载安装包的时候，注意勾选"Add Python to PATH"这个选项，这样你在命令行里敲python才能直接用，省得后面配环境变量配到怀疑人生。
装完之后强烈建议用虚拟环境。我在实际开发中遇到过太多次"全局环境被搞乱、项目A能跑、项目B就报错"的惨案。在项目根目录执行python -m venv venv，然后Windows系统执行venv\Scripts\activate，Linux/Mac执行source venv/bin/activate，这样就把项目的依赖隔离起来了。很多教程上来就让你pip install flask装到全局，这是给机器埋雷的行为，项目一多必然出事。
如果你用的是PyCharm，社区版其实完全够用，别听人说PyCharm社区版不能创建Flask项目就慌。社区版只是没有专业的Flask模板和JavaScript调试面板，对Python开发本身的体验是完全不打折的。你可以在PyCharm的Settings里找到Project Interpreter，选择刚才创建的虚拟环境，然后手动安装依赖包，效果和旗舰版没有任何区别。这就是我在Windows上开发Flask项目最顺的套路。
2.2 Flask项目目录结构有多重要
很多初学Flask的人喜欢把所有代码堆在一个app.py里，几百行代码下来，自己都找不到路由了。考勤系统这种多模块项目，我推荐用蓝图的目录结构来组织代码，清晰、可扩展、后期维护成本低。下面是经过几个完整项目验证过的标准结构：
text复制attendance_system/
├── run.py # 启动入口
├── requirements.txt # 依赖清单
├── config.py # 配置文件
├── venv/ # 虚拟环境
├── app/
│ ├── __init__.py # 应用工厂
│ ├── models.py # 数据模型
│ ├── forms.py # 表单类
│ ├── extensions.py # 扩展对象初始化
│ ├── views/
│ │ ├── __init__.py
│ │ ├── auth.py # 登录注册蓝图
│ │ ├── attendance.py # 打卡蓝图
│ │ ├── leave.py # 请假蓝图
│ │ ├── admin.py # 管理后台蓝图
│ │ └── main.py # 首页蓝图
│ ├── templates/ # HTML模板
│ │ ├── base.html
│ │ ├── auth/
│ │ ├── attendance/
│ │ ├── leave/
│ │ └── admin/
│ └── static/
│ ├── css/
│ ├── js/
│ └── img/
这个结构的核心思想是"按业务模块分蓝图"。打卡相关的路由全部在attendance.py里，请假相关的路由全部在leave.py里，后面加功能只需要新增蓝图文件，不去动已经稳定的代码。用蓝图之前，Flask的路由表是平铺的，模块一多就乱了套；用了蓝图之后，每个模块都有自己独立的路由前缀，比如打卡模块统一挂载在/attendance下面，管理后台统一挂载在/admin下面，一眼就能看出请求去了哪个模块，维护体验提升一大截。
2.3 依赖清单与安装命令
requirements.txt文件里，我列出的依赖精简到不能再精简，装多了纯粹给环境添乱：
text复制Flask==2.3.3
Flask-SQLAlchemy==3.1.1
Flask-Login==0.6.3
Flask-WTF==1.2.1
Flask-Migrate==4.0.5
openpyxl==3.1.2
安装命令就一条：pip install -r requirements.txt。如果你在安装过程中遇到网络超时，可以加-i https://pypi.tuna.tsinghua.edu.cn/simple用清华镜像源，速度快很多。这里有个我经历过的坑：Flask-WTF表单模块在1.0版本之前和之后，CSRF处理的默认值发生变化，导致升级之后表单无法提交。所以我在项目里直接锁定版本，除非必要不升级，避免出现"昨天还能跑、今天就不能用"的尴尬。
3. 核心功能模块实现
3.1 员工认证与权限控制
考勤系统最基础也最关键的一环是登录认证。我用Flask-Login来做会话管理，配合@login_required装饰器保护需要登录才能访问的页面。用户模型继承UserMixin，再实现get_id方法，Flask-Login就能自动帮你在请求进来的时候加载当前用户对象。
权限控制这块，我的做法非常简单粗暴：在数据库中给员工表加一个role字段，0是普通员工，1是管理员。然后自己写一个admin_required装饰器，判断当前用户的role值，不是管理员就返回403页面。这样做的好处是逻辑直观，考勤系统就两种角色，搞太复杂的权限框架纯属杀鸡用牛刀。如果你的公司规模大、角色多，再考虑引入Flask-Principal或者CASBIN，但现在这个阶段，简单就是最好。
python复制from functools import wraps
from flask import abort, redirect, url_for
from flask_login import current_user, login_user, logout_user
def admin_required(f):
@wraps(f)
def decorated_function(*args, **kwargs):
if not current_user.is_authenticated:
return redirect(url_for('auth.login'))
if current_user.role != 1:
abort(403)
return f(*args, **kwargs)
return decorated_function
登录视图的代码套路是固定的：接收表单提交的用户名和密码，check_password_hash校验密码，通过之后调login_user(user)写入登录状态，然后跳转到next参数指定的页面或者首页。这里有个安全细节：next参数容易被恶意用户构造重定向链接，所以我在代码里加了白名单校验，只允许重定向到站内路径。项目上线之后，这类看起来不起眼的小细节，往往是安全审计的重点对象。
3.2 上下班打卡的核心逻辑
打卡是考勤系统的灵魂功能，它的实现难度不在于技术，而在于边界情况的考虑。我的打卡接口设计成只接收POST请求，前端页面上放置两个按钮：上班打卡、下班打卡。后端逻辑大概是这个流程：
- 获取当前登录员工的ID和当前时间。
- 查询当天是否已经有打卡记录：如果没有，判断当前时间是否晚于配置的上班时间加迟到容忍值，将
clock_in_time写入，上班状态记为"迟到"或"正常"；如果有记录，说明之前打过上班卡，现在执行的是下班操作，判断当前时间是否早于配置的下班时间，将clock_out_time写入，下班状态记为"早退"或"正常"。 - 如果当天已经完成上下班两次打卡，再次点击返回提示"今日已经完成全部打卡"。
这里有三个容易踩的坑。第一个是时区问题：Python的datetime.now()返回的是服务器本地时间，如果服务器部署在云端且时区不是北京时间，打卡时间就会错乱。我统一在配置中设置TIMEZONE = 'Asia/Shanghai'，并在获取时间时用zoneinfo.ZoneInfo来强制指定时区，后端所有时间计算都基于这个时区。第二个是同一天重复打卡的问题：我在Attendance模型的employee_id和work_date上加了联合唯一约束，数据库层面就挡住了重复记录。第三个是上下班时间判断的粒度问题：我建议把"9:00:00"这类时间配置写成字符串存在配置表里，每次判断时再转成datetime对象，而不是硬编码在代码里，这样才能满足不同部门不同班次的需求。
python复制from datetime import datetime, date, time, timedelta
from zoneinfo import ZoneInfo
from flask import jsonify, request
from flask_login import login_required, current_user
from . import attendance_bp
from ..models import Attendance, db
TZ = ZoneInfo("Asia/Shanghai")
def _get_now():
return datetime.now(TZ)
def _to_time(clock_str):
"""把'09:00'格式的字符串转成datetime.time对象"""
hour, minute = map(int, clock_str.split(':'))
return time(hour, minute)
@attendance_bp.route('/punch', methods=['POST'])
@login_required
def punch():
now = _get_now()
today = now.date()
punch_type = request.json.get('punch_type') # 'in' 或 'out'
record = Attendance.query.filter_by(
employee_id=current_user.id, work_date=today
).first()
if not record:
record = Attendance(employee_id=current_user.id, work_date=today)
db.session.add(record)
if punch_type == 'in':
if record.clock_in_time is not None:
return jsonify({'code': 1, 'msg': '今天已经打过上班卡了'})
record.clock_in_time = now
late_threshold = _to_time(get_setting('late_threshold', '09:00'))
if now.time() > late_threshold:
record.status = 'late'
else:
record.status = 'normal'
elif punch_type == 'out':
if record.clock_out_time is not None:
return jsonify({'code': 1, 'msg': '今天已经打过下班卡了'})
record.clock_out_time = now
if record.status == 'normal' and now.time() < _to_time(get_setting('work_end_time', '18:00')):
record.status = 'early_leave'
db.session.commit()
return jsonify({'code': 0, 'msg': '打卡成功'})
3.3 请假申请与审批流程
请假模块的完整闭环我拆成了四个部分：员工提交申请、部门负责人审批、员工查看进度、HR月度汇总。提交申请的表单字段包括请假类型、开始时间、结束时间、请假原因。这里有一个我在实际项目中吃过亏的地方：很多新手只存了"开始日期"和"结束日期"，然后直接做减法得请假天数，结果遇到包含周末和法定节假日的跨周请假，算出来的天数多了好几天。我现在的做法是在后端写一个函数，遍历从开始到结束的每一天，来自动扣除周六周日，法定节假日要不要扣，这个需求得问HR，因为各地各公司的政策差异很大，我倾向于把它设计成可配置项。
审批流程的核心是状态机，我用一个简单的字典来定义状态流转规则，不允许从任何状态直接跳到无关状态：
python复制LEAVE_STATUS_FLOW = {
'pending': ['approved', 'rejected', 'cancelled'],
'approved': [],
'rejected': ['pending'],
'cancelled': [],
}
员工提交请假单后状态是pending，部门负责人看到待审批列表，点"通过"状态变成approved，点"拒绝"状态变成rejected。被拒绝的请假单，员工编辑原因之后可以重新提交，状态回到pending。这里有个小细节：审批动作发生时，我要在leave_approval表里插入一条记录，记录审批人和审批意见，方便以后追溯。审核操作本身要加权限校验，只有角色的管理员才能调用审批接口。
python复制@leave_bp.route('/approve/<int:leave_id>', methods=['POST'])
@login_required
@admin_required
def approve(leave_id):
leave = Leave.query.get_or_404(leave_id)
if leave.status != 'pending':
return jsonify({'code': 1, 'msg': '该请假单当前状态不可审批'})
action = request.json.get('action') # 'approved' 或 'rejected'
if action not in ['approved', 'rejected']:
return jsonify({'code': 1, 'msg': '无效的审批操作'})
leave.status = action
approval = LeaveApproval(
leave_id=leave.id,
approver_id=current_user.id,
action=action,
comment=request.json.get('comment', '')
)
db.session.add(approval)
db.session.commit()
return jsonify({'code': 0, 'msg': '审批完成'})
3.4 考勤统计与报表导出
月底的考勤统计报表，是我每次做这类系统都觉得最麻烦的模块，因为它要处理的数据量虽然不大，但计算逻辑绕。我的做法是写一个专用的统计函数，接收year和month参数，遍历该月度每天的打卡记录，先过滤掉请假已批准和周末的日期，剩下的日期里再挨个判断状态是正常、迟到还是早退。最终输出每个员工的一行汇总数据：应出勤天数、实际出勤天数、迟到次数、早退次数、缺卡次数、请假天数。这个函数整体上就是个双层循环，外层员工，内层日期，数据量几百人的公司完全跑得动，没必要上来就搞什么复杂SQL统计，代码可读性反而更重要。
导出Excel我用的openpyxl，这里有一个性能优化的细节：如果每次生成报表都从头查一次数据库，几百人查一个月的数据，查询次数会非常夸张。我的做法是先用一条SQL把整月所有员工的打卡记录查出来，在内存里按员工和日期建索引，统计函数直接从字典里取数据，而不是循环里反复查询数据库。这样做之后，报表的生成时间从几十秒级别降到两秒以内。这个优化技巧本质上就是"把N+1查询问题消灭在源头"，建议每一个做Web开发的都养成这种意识。
4. 前端页面与交互设计
4.1 模板继承提升开发效率
Flask默认的Jinja2模板引擎对我来说，最大的价值就是模板继承。我在base.html里搭好整个系统的页面骨架，包括顶部导航栏、左侧菜单、底部版权信息、公共样式和脚本引用，然后每个具体页面只需要{% extends "base.html" %}，再重写{% block content %}区块的内容就行。这个方式能把重复的HTML代码砍掉70%以上，而且全局改样式只需要动一处。
html复制<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>{% block title %}员工考勤系统{% endblock %}</title>
<link rel="stylesheet" href="{{ url_for('static', filename='css/style.css') }}">
</head>
<body>
<nav class="navbar">
<div class="nav-brand">员工考勤管理系统</div>
<div class="nav-links">
{% if current_user.is_authenticated %}
<a href="{{ url_for('main.index') }}">首页</a>
<a href="{{ url_for('attendance.attendance_page') }}">我的考勤</a>
<a href="{{ url_for('leave.apply') }}">请假申请</a>
{% if current_user.role == 1 %}
<a href="{{ url_for('admin.dashboard') }}">管理后台</a>
{% endif %}
<span class="nav-user">{{ current_user.name }}</span>
<a href="{{ url_for('auth.logout') }}">退出</a>
{% else %}
<a href="{{ url_for('auth.login') }}">登录</a>
{% endif %}
</div>
</nav>
<main class="container">
{% with messages = get_flashed_messages(with_categories=true) %}
{% for category, message in messages %}
<div class="alert alert-{{ category }}">{{ message }}</div>
{% endfor %}
{% endwith %}
{% block content %}{% endblock %}
</main>
<script src="{{ url_for('static', filename='js/main.js') }}"></script>
{% block scripts %}{% endblock %}
</body>
</html>
4.2 考勤页面的实时时间与AJAX交互
打卡页面我做成了一个专属的工作台页面，页面上最醒目的是一个实时时钟，用JavaScript的setInterval每秒刷新，再配两个大按钮："上班打卡"和"下班打卡"。按钮点击后走fetch请求调用后端/attendance/punch接口，后端返回JSON，前端根据code字段弹出提示，并刷新打卡记录的展示区域。整个交互过程不刷新页面，体验比传统表单提交好太多，员工用起来也更顺手。
前端发AJAX请求的时候有一个坑：Flask-WTF开启全局CSRF防护后，所有POST请求都必须携带csrf_token，否则后端会返回400错误。解决办法有两个，一个是使用Flask-WTF提供的{{ csrf_token() }}把token渲染进HTML页面，然后前端每次请求在请求头里带上它；另一个更省事的选择是在调用Flask-WTF的CSRFProtect(app)时，配置WTF_CSRF_CHECK_DEFAULT=False，再手动给需要防护的接口加装饰器。但我建议老老实实走第一个方案，CSRF防护不能因为麻烦就关掉。
4.3 管理后台的考勤明细与日历视图
管理后台是考勤系统里面向管理员的核心操作区。我在admin_bp蓝图里实现了三个主要页面：员工管理页、考勤明细页、请假审批页。考勤明细页我是按照"按日查看"和"按月查看"两种粒度设计的，按日查看时直接展示某一天所有员工的打卡时间列表，如果员工当天没打卡就显示红色"缺卡"，这个页面用于每天的日常巡检；按月查看时展示的是月度汇总表，每一行是一个员工一个月的考勤实况，最后一列是"操作"按钮，可以跳转查看该员工这个月的每日明细。
为了快速定位数据，我在页面顶部放了筛选条件：部门下拉框、员工搜索框、日期选择器、状态筛选。筛选条件通过GET参数传向后端，后端用SQLAlchemy的链式过滤来动态拼接查询条件，这个做法比单独写多个函数应对不同筛选条件要简洁很多。日历视图我用了现成的FullCalendar库，每个月像日历一样展示打卡记录，状态不同的日期用不同颜色标注，绿色是正常，红色是迟到或早退，灰色是请假，橙色是缺卡。管理员扫一眼就知道这个月哪里有异常，真的方便。
5. 常见问题与排查技巧
5.1 打卡时间不对，首先怀疑时区和服务器时间
我帮朋友排查过很多次"打卡时间明明在9点之前，系统却判定迟到"的现象，十有八九是服务器时区问题。云服务器默认可能是UTC时区，而代码里写的是datetime.now()，拿到的就是UTC时间，比北京时间慢了8个小时，当然从9点之后变成了凌晨1点。处理这类问题，我的排查流程是：先执行date命令看服务器系统时间，再执行timedatectl看时区配置，最后检查Python代码里datetime.now()和datetime.utcnow()的使用，统一改成datetime.now(ZoneInfo("Asia/Shanghai"))。这个坑我踩过不下三次，每次都要花掉一两个小时定位。
还有一种情况是员工手机或电脑时间不准。我自己设计的打卡逻辑是以服务器时间为准，不取客户端提交的时间，因为客户端的系统时间很容易被用户手动修改。HTTP请求里面的时间戳更不能信，那是客户端自己声明的，作为考勤依据毫无意义。所以不管前端页面显示的是什么时间，真正写入数据库的永远是后端取到的服务器时间，这点必须从一开始就明确。
5.2 SQLAlchemy的session管理是配置问题重灾区
用Flask-SQLAlchemy的过程中，新手最常遇到的报错是Session is already flushing和DetachedInstanceError。前者多半是因为在请求过程中手动调用了db.session.commit()，然后在模板渲染或后续逻辑中又尝试修改同一个对象；后者是因为在db.session.close()之后还去读取对象的属性。我的排查思路很简单：把整个请求过程中的数据库操作看成一个事务单元，在视图函数结束前统一提交，不搞"边处理边提交"的花活，问题自然就少了。如果确实需要在视图中间提交数据，比如导出Excel这种耗时操作，那就用db.session.expunge_all()把不需要的对象从session里摘出来，避免后续访问时触发DetachedInstanceError。
还有一个我经常看到的坑是忘记定义__tablename__，导致SQLAlchemy自动生成一个奇怪的表名，然后数据库迁移的时候表名对不上。我习惯在每个模型类里显式定义__tablename__，比如__tablename__ = 'employee'，同时在模型里用db.Column定义字段时严格指定字段类型和长度，不依赖自动生成，这样迁移脚本才靠谱。
5.3 Flask-WTF表单提交总是400
表单提交返回400，我第一反应就是CSRF验证没通过。原因是Flask-WTF默认对每一个POST请求做CSRF校验，前端模板的<form>标签里必须有{{ form.hidden_tag() }}或者<input type="hidden" name="csrf_token" value="{{ csrf_token() }}">。如果你用的是纯fetch或Axios发起POST，那必须在请求头加上X-CSRFToken: <token>。排查步骤就是：先看浏览器开发者工具的Network面板，确认请求头和表单数据里有没有csrf_token字段，没有就说明前端漏了，加上就能解决。
在我实际做的项目里，也曾遇到"token 明明加了还是400"的情况。最终发现是Flask-WTF的配置WTF_CSRF_TIME_LIMIT默认是3600秒，也就是token超过一个小时就过期。如果页面挂在后台很久没有刷新，再去提交表单，token就失效了。我把这个值改成了7200，同时在页面里做了一个简单的提示：如果提交失败且疑似token过期，刷新页面再试。
5.4 部署时别再使用Flask自带的开发服务器
最后说一下部署。开发阶段直接用app.run(debug=True)没问题，但生产环境这么干，性能和安全性都扛不住。我习惯用gunicorn来做WSGI服务器，配合Nginx做反向代理，一个简单的启动命令是：
bash复制gunicorn -w 4 -b 127.0.0.1:8000 run:app
-w 4表示开启4个worker进程，具体多少个要根据服务器的CPU核心数来定，一般每个核心配2到4个worker就够用了。Nginx把80端口的请求反代给127.0.0.1:8000，同时负责静态文件的直接返回，Flask只处理动态请求，这样压力被分摊掉大半。
部署之后我建议用flask --app run.py routes看一眼所有路由是否正常注册，再配一个定时任务每天凌晨备份一次SQLite或者MySQL数据库。考勤数据是企业的敏感数据，备份这件事必须做，否则哪一天服务器磁盘坏了，哭都来不及。这些看起来不起眼的运维细节，才是系统能不能长久稳定跑下去的关键。
我自己在反复打磨这套系统的过程中，最大的体会是：考勤系统的难点从来不在技术，而在业务规则的理解和数据质量的保障。上手写代码之前多花半小时想清楚打卡和请假的状态流转、报表的统计口径，后面开发能少走很多弯路。另一个高性价比的操作是先把管理后台的筛选和报表逻辑做出来，因为它是检验打卡逻辑是否正确的放大镜，数据一但不对，你能第一时间发现，不用等到月底汇总时才追悔莫及。