王怡蕊1. 项目概述：28960小型企业员工考勤管理系统
最近在整理过往项目时，翻出了这套为中小型企业设计的员工考勤管理系统源码。这套系统最初是为一家60人规模的制造企业开发的，经过三次迭代后形成了现在这个稳定版本。不同于市面上那些臃肿的OA系统，这个方案特别适合50-300人规模的企业，功能精简但足够实用。
系统采用B/S架构，后端使用Python+Django框架，前端是经典的Bootstrap+jQuery组合。数据库支持MySQL和SQLite两种方案，对于没有专业IT团队的小企业特别友好——SQLite版本甚至可以直接单机运行，无需额外配置数据库环境。
提示：虽然系统支持SQLite，但员工数超过50人时建议切换至MySQL以获得更好的并发性能。我在实际部署中发现，SQLite在高峰打卡时段（如早上8:00-9:00）可能会出现响应延迟。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心功能解析
2.1 基础考勤管理模块
系统最核心的功能模块包含：
-
多方式打卡：支持网页打卡、API对接考勤机、移动端H5页面三种方式。其中移动端页面做了PWA适配，员工可以将其添加到手机桌面，使用体验接近原生APP。
-
智能排班：这是我花最多心思的部分。不同于简单的工作日设定，系统支持：
- 弹性工作制（核心工作时间+弹性时段）
- 倒班配置（最多支持四班三运转）
- 临时调班批量处理
python复制# 排班算法核心代码片段（简化版）
def generate_schedule(employees, start_date, end_date):
schedule = {}
current_date = start_date
while current_date <= end_date:
if is_holiday(current_date):
schedule[current_date] = 'H'
else:
for emp in employees:
shift = get_employee_shift(emp, current_date)
schedule.setdefault(current_date, {})[emp.id] = shift
current_date += timedelta(days=1)
return schedule
- 异常处理：系统会自动标记以下异常情况：
- 迟到/早退（根据排班设置阈值）
- 未打卡（支持补卡申请流程）
- 连续工作时长超标（劳动法合规检查）
2.2 统计报表系统
报表模块采用前后端分离设计，后端提供JSON数据接口，前端使用ECharts实现可视化。这个设计让后续定制开发特别方便——我有客户就在此基础上接入了企业微信机器人，每天自动推送部门考勤异常统计。
核心报表包括：
- 个人月考勤明细（支持导出Excel）
- 部门出勤率趋势图
- 年度休假统计看板
- 加班时长排名（这个功能要慎用，实测会让HR部门压力山大）
3. 技术实现细节
3.1 数据库设计要点
考勤系统的数据库设计有几个关键点需要注意：
-
考勤记录表：采用"分表+归档"策略。当前月数据存在
attendance_current表，历史数据按月分表存储（如attendance_202301）。系统内置定时任务每月自动执行数据迁移。 -
员工信息加密：虽然是小系统，但员工身份证号、银行卡号等敏感字段全部采用AES加密存储。密钥管理是个坑——初期版本把密钥硬编码在settings.py里，后来改成了使用环境变量动态加载。
python复制# 加密存储示例
from Crypto.Cipher import AES
import base64
def encrypt_data(data, key):
cipher = AES.new(key.encode('utf-8'), AES.MODE_GCM)
ciphertext, tag = cipher.encrypt_and_digest(data.encode('utf-8'))
return base64.b64encode(cipher.nonce + tag + ciphertext).decode('utf-8')
- 索引优化：在
employee_id+check_time上建立了复合索引，经测试在10万条记录情况下，查询速度仍能保持在200ms以内。
3.2 高并发处理方案
早上打卡高峰期的并发问题是这类系统的通病。我们通过以下方案应对：
- 使用Redis作为缓存层，热门查询（如当日已打卡名单）缓存5分钟
- 数据库连接池配置（建议最大连接数=员工数/10）
- 打卡请求采用异步队列处理，前端立即返回"处理中"状态
4. 部署与二次开发指南
4.1 最小化部署方案
对于没有专业运维团队的企业，推荐以下部署方案：
- 购买腾讯云/阿里云基础版云服务器（2核4G配置足够支持200人规模）
- 使用宝塔面板一键安装Nginx+MySQL+Python环境
- 通过Git克隆代码库，修改配置后使用Supervisor托管进程
bash复制# 典型部署命令序列
git clone https://github.com/xxx/attendance-system.git
cd attendance-system
pip install -r requirements.txt
cp config_sample.py config.py
# 编辑config.py配置数据库等信息
supervisord -c supervisor.conf
4.2 常见定制需求实现
根据过往项目经验，企业最常要求的二次开发包括：
- 对接企业微信/钉钉：需要修改
api/auth.py中的认证逻辑，建议使用官方SDK - 定制审批流程：修改
workflow/目录下的状态机配置 - 数据大屏展示：可以复用现有的报表API，前端用DataV等工具重构
重要提示：修改审批流程时务必先备份数据库。有客户在没通知员工的情况下修改了补卡流程，结果导致当月考勤数据全部需要人工复核。
5. 避坑经验分享
5.1 时区问题
这是最容易被忽视的坑！系统必须确保：
- 服务器时区设置为Asia/Shanghai
- 数据库连接时区参数一致
- 前端传递的时间戳要明确时区信息
我遇到过最诡异的问题是：某客户部署在AWS日本区的服务器上，员工打卡记录全部显示为UTC时间，导致每天统计都少8小时。
5.2 考勤规则配置
建议实施时：
- 先用测试账号模拟各种打卡场景
- 导出测试数据与HR手工记录比对
- 特别关注跨日班次（如夜班22:00-6:00）的计算逻辑
有次项目验收时才发现，系统把凌晨下班的班次全部算成了前一天的出勤，差点导致全员工资计算错误。
5.3 性能优化记录
随着使用时间增长，系统可能出现性能下降。以下是实测有效的优化手段：
- 每月执行一次
VACUUM（SQLite版本） - 定期清理session表（Django默认用数据库存储session）
- 对超过半年的考勤记录做归档处理
sql复制-- 归档旧数据的SQL示例
BEGIN;
CREATE TABLE attendance_2022H2 AS
SELECT * FROM attendance_current
WHERE check_time BETWEEN '2022-07-01' AND '2022-12-31';
DELETE FROM attendance_current
WHERE check_time BETWEEN '2022-07-01' AND '2022-12-31';
COMMIT;
这套系统源码已经放在GitHub上，包含完整部署文档和测试数据。对于想要学习Django实战开发的朋友，代码中有大量注释说明关键设计思路。我在项目里还特意保留了几个"错误示范"（比如最初版本的密码存储方式），通过git历史可以看到完整的优化过程。