简介这是一套基于 Qt 框架开发的职工工资管理系统完整源码包面向 Qt 初学者及需要实现桌面增删改查功能的学习者涵盖登录、注册、主界面与录入四个界面支持员工信息录入、搜索、修改以及总工资与平均工资的自动统计。压缩包共 73 个文件约 21.3MB除 5 个 cpp、4 个 h 源码和 4 个 ui 界面设计文件外还包含可运行的 exe、Qt 运行所需的 27 个 dll 动态库、21 个 qm 翻译文件及配套的 db 数据库文件结构完整便于直接打开工程查看。目前已有 1422 人学习下载适合作为课程设计或入门 Qt 数据库开发的参考资料。使用时注意数据库文件若为空可能影响登录可修改 main 直接进入主界面或自行添加测试数据从中可学习到界面布局、信号槽、SQLite 操作及多窗口切换等关键实现整体对理解 Qt 的界面与数据库协同开发很有帮助。 做工资管理系统这个念头我开始是拒绝的。公司内部的薪资数据一直摊在 Excel 里每逢月底行政要花两三天把考勤导出来、手工匹配请假加班、套公式算社保个税稍不留神就错了行。更难受的是Excel 文件在同事之间传来传去版本一乱谁能讲清楚哪一版才是最后的实发数所以我自己用 Qt 写了一个桌面端工资管理系统整整跑了三个发薪周期才敢说它真正能替代人工。这篇内容就是把这个项目的完整思路、核心实现和踩过的坑一次说清楚尤其适合正在用 Qt 做业务系统的开发者参考。1. 为什么做一个 Qt 版的工资管理系统而不是上 Web 系统选题之前我先算了一笔账。公司内部就那么几十号人OA 和人事系统不是没考察过但每个月要调整的项目太多采购一套 SaaS 年费不低定制接口还得等排期。工资这种数据老板明确不希望走第三方云存储本地化是刚需。桌面应用在这种场景下反而是最优解数据在自己手里功能可以慢慢迭代部署就是复制文件夹不需要运维。选 Qt 而不是 C# 或者 Electron理由也很直白。Qt 的 QTableView 自定义 Model 在处理行列表格数据时性能比 Electron 那套 DOM 渲染高出一个量级几万行工资明细滚动起来不掉帧。C# 虽然做 WinForms 也快但公司里还有几台麒麟系统的国产化机器Qt 的跨平台能力让我只需要维护一套代码编译一个新的 kit 就能跑过去。最关键的是团队本来就有 C 底子Qt 的信号槽机制写业务逻辑非常顺手。有人可能会问工资系统这种低级业务用 DataFrame 不是更香但实际场景里大部分操作都是单条增删改查、按月生成记录、导出 Excel数据量远没到需要 DataFrame 或者列存的地步。SQLite 单文件数据库就足够备份就是一个 .db 文件拷走比什么都直观。桌面端 本地库这套组合在中小规模企业内网里几乎是成本和效率的最佳平衡点。模块划分上我按照工资业务的自然边界拆成了四块人员档案、考勤数据、工资项配置、月度结算。每块对应工程里的一个子目录界面层、业务层、数据访问层分层。千万要把 SQL 语句和界面逻辑分开工资计算规则三个月内必改一次如果写死在按钮点击事件里改起来会想哭。2. 库表设计与工资项配置这是整个项目的定海神针工资系统的难点从来不是界面而是数据结构。一开始我参照 Excel 表头直接给工资表设计了二十多个列基本工资、岗位工资、绩效、加班费、餐补、交通补、社保、公积金、个税、实发……结果第二个月加了一个高温补贴字段我要改表结构、改模型、改插入语句、改导出逻辑改了整整一下午。后来痛定思痛改成字段少而稳数据灵活配的设计。核心表只有五张employee工号、姓名、部门、入职日期、离职日期、银行卡号。attendance_monthly工号、月份、应出勤天数、实出勤天数、请假天数、加班时长。salary_item项目编码、项目名称、计算方式0固定值、1按出勤比例、2按工时、启用状态。salary_record工号、月份、项目编码、金额。salary_settlement工号、月份、税前合计、扣除合计、实发工资、结算状态。工资项不再作为表的列存在而是作为记录存在 salary_item 里。每月的工资构成就是 employee × salary_item × 月份生成一批 salary_record 记录。这笔一行一个工资项的设计比一行一个月工资所有项目的宽表设计灵活得多。加补贴在工资项配置表里插一条记录就行不需要动数据库结构删项目启停开关一拨下月结算自然过滤。每月结算的业务顺序是这样的从 attendance_monthly 读取考勤汇总然后遍历启用的 salary_item根据计算方式算出每一项金额插入 salary_record。固定项直接赋值按出勤比例的项目比如绩效奖金就按实出勤天数 / 应出勤天数 × 基数计算按工时的项目比如加班费就读取加班时长再乘单价。全部落库后汇总 salary_record 算出税前合计再按当地规则计算扣除项最后得到实发工资写进 salary_settlement。这里有个细节很容易被忽略扣款项和扣款基数是有顺序依赖的。比如社保公积金的基数一般是上一年月均工资不是本月工资个税要按累计预扣法而不是单月计算。所以我单独设计了 settlement 的阶段状态字段每次计算都追溯上期累计数据避免把单月数据孤立处理。这个坑做过薪酬的人应该都懂。3. 核心计算逻辑Qt 的模型里不能直接跑业务很多人写 Qt 程序喜欢把数据处理放在 QTableView 的 model 里或者干脆在界面上逐行操作 UI 控件来算工资。这样不是不行但一旦数据量上来界面卡死是小事算错数据才是大事。我采取的方式是业务层独立于界面层Model 只是展示数据的镜像计算结果全部写入数据库后再刷新视图。考勤数据导入用了 CSV 文件接口。行政从考勤机导出的格式五花八门我在工程里写了一个通用的 CsvParser 类按表头名映射字段不依赖固定列序。解析完先预览确认无误再批量写入 attendance_monthly。批量写入用事务包裹一万条数据也就是毫秒级别的事QSqlDatabase db QSqlDatabase::database(salary_conn); db.transaction(); QSqlQuery query(db); query.prepare(INSERT INTO attendance_monthly (emp_no, month, actual_days, overtime_hours) VALUES (?, ?, ?, ?)); for (const AttendanceRow row : rows) { query.addBindValue(row.empNo); query.addBindValue(row.month); query.addBindValue(row.actualDays); query.addBindValue(row.overtimeHours); query.exec(); } db.commit();注意 prepare 要放在循环外面addBindValue 的参数要按占位符顺序来。如果循环里反复 prepare两万行数据能把执行时间拉长十倍不止。还有事务必须捕获异常失败时回滚否则中途断电表里出现半个批次的数据月底对账会疯掉。扣税计算我封装成了一个独立静态库与 UI 完全解耦。函数的输入是累计应纳税所得额和累计已预扣税额输出本次应扣税额。这样计算规则集中在 calc_tax() 函数里每年政策调整只需要改这一个函数然后补充几个单测用例覆盖临界值。Qt Test 框架在这里派上大用场我把工资计算的边界条件写成测试用例改规则后跑一遍确认没有回归才发版。没有单测的保护这种敏感计算模块我根本不敢动。4. 表格呈现与数据可视化让工资数据看得见而不是看得累工资系统界面上工作量最大的不是表单而是对外展示的报表视图。管理者要看全员的薪酬分布、部门人力成本趋势员工要核对个人明细。我用 QTableView 自定义 QAbstractTableModel 实现明细页用 QCustomPlot 做趋势分析图表。列表页的关键是排序与筛选。QSortFilterProxyModel 在这里非常有用我在原始模型之外加了一层代理模型用户点击表头排序、按月份过滤、按部门搜索全部由代理模型处理不需要频繁操作数据库。注意代理模型和源模型的关系自定义 model 里要正确实现 data()、rowCount()、columnCount() 和 headerData()其中 data() 的返回值类型要统一金额用 double 转 QString 时要保留两位小数排序才不会出错。还有一个坑是 QTableView 默认的编辑方式。工资数据不允许随意双击修改特别是 salary_record 这种已经参与结算的记录。所以 model 的 flags() 方法里我关闭了 Qt::ItemIsEditable只有人工调整的专项补贴表才单独开一个可编辑列。变更记录写入 audit_log 表谁在什么时候改了哪个数字一查便知。工资系统不审计出了问题就是大问题。图表这块QCustomPlot 是 Qt 生态里最顺手的开源绘图库。我把个人月薪趋势和部门成本占比画在一张选项卡里QCustomPlot 的 QCPBars 画月度柱状图QCPGraph 画趋势折线双坐标轴放在同一个 QCPAxisRect 里。绘制数据从 salary_settlement 聚合 SQL 查询而来SELECT month, SUM(settled_salary) FROM salary_settlement WHERE department ? GROUP BY month ORDER BY month;从 SQL 取到结果后把月份转成 QVector 的下标再组装成 QCPGraphData一次性 setData 进去然后 replot()。QCustomPlot 高性能就高在它把整个绘图封装在 QCPPaintBuffer 里十万个数据点重绘也不会卡界面。注意 replot() 是同步的如果频繁刷新用 setNotAntialiasedElements() 关掉抗锯齿交互响应会流畅很多。5. 网络功能与远程数据同步该用 QNetworkAccessManager 时别手写 socket工资系统虽然是桌面应用但免不了和外部系统打交道考勤机服务器、企业微信审批接口、工资条推送服务。最开始我图省事想用 QTCPSocket 自己拼协议后来发现解析 JSON 结构实在太繁琐还是换回了 QNetworkAccessManager。这个类用起来有个关键认知所有请求都是异步的不能在一个线程里阻塞等着响应不然界面直接就有假死体检。以同步审批数据为例我的实现思路是构建 QNetworkRequest 时设置 Header用 POST 方法发送 JSON 数据然后连接 finished 信号处理响应。处理函数里用 QJsonDocument::fromJson 解析返回再通过信号把结果传回界面层。整个过程中业务逻辑和 UI 的交互全部通过信号槽解耦数据到了再更新不会出现控件还没刷新用户就开始点按钮的情况。QNetworkAccessManager* manager new QNetworkAccessManager(this); connect(manager, QNetworkAccessManager::finished, this, [](QNetworkReply* reply) { if (reply-error() ! QNetworkReply::NoError) { qCritical() network error reply-errorString(); reply-deleteLater(); return; } QJsonDocument doc QJsonDocument::fromJson(reply-readAll()); emit salaryDataSynced(doc.object()); reply-deleteLater(); }); QJsonObject payload; payload[action] pull_attendance; payload[month] currentMonth; QNetworkRequest request(url); request.setHeader(QNetworkRequest::ContentTypeHeader, application/json); manager-post(request, QJsonDocument(payload).toJson());这里有个 Qt 用久了容易忽略的点reply 对象用完后必须 deleteLater()否则请求多了内存涨得飞快。还有 finished 信号携带的 reply 可能指向空对象判断 error() 前要先判空。另外公司内网 URL 如果走了代理还要在 QNetworkProxy 里设置代理类型否则 post 请求一直报 request method post not supported排查半天才发现是代理拦截。同步数据的时间点也很讲究。我放在发薪日的前一天晚上由 QTimer 触发一次自动同步工资核算模块拉取到最新考勤后自动生成结算预览管理员第二天只要点一次确认。这样的被动拉取 主动推送结合避免了数据库连接被频繁打开。6. 打包发布与跨平台部署windeployqt 不是双击就完事说个真实经历项目在开发机上跑得好好的打包发给行政她双击后直接弹窗 no qt platform plugin could be initialized。第一反应以为是有人解压不完整查了半天才明白是打包时少了 platforms 目录下的 qwindows.dll。这是 Qt 新手最容易踩的坑windeployqt 会帮你复制大部分 DLL但如果你手工删除了某些文件或者把 exe 放在含中文与空格的路径下运行插件加载就会失败。正确的打包流程我在项目里固化成了脚本用 Release 模式编译不要带 Debug 运行库。打开 Qt 自带的命令行环境不是普通 CMD。运行 windeployqt 工资管理系统.exe --release --no-translations。检查输出目录里是否存在 platforms/qwindows.dll注意是 platforms 子目录不是根目录。把 SQLite 数据库模板文件一并复制首次运行自动建库。用 Inno Setup 打成安装包安装路径默认 Program Files避免中文目录。还有几个看不见的雷。MSVC 编译的程序目标机器上可能缺 VC 运行库windeployqt 不会自动带需要在安装脚本里检测 vc_redist.x64.exe。SQLite 插件要确认 sqldrivers 目录下有 qsqlite.dll否则程序打开数据库时报 driver not loaded。中文乱码问题也很常见Qt5 默认用 UTF-8但 Windows 上读取配置文件如果文件是 GBK 编码QTextStream 需要主动 setCodec(UTF-8)否则界面上一堆火星文。如果目标是麒麟这类国产化系统需要额外注意两点。一是安装 Qt 时选对架构麒麟 x86 和 ARM 分别要不同的 kitqmake 的路径也要对应。二是系统自带字体和 Windows 不一样QSS 里写了 font-family 的要注意回退机制否则界面字号忽大忽小。我在这台机器上还遇到过 QCustomPlot 的 OpenGL 渲染异常最后在 main 函数里加了一句 QApplication::setAttribute(Qt::AA_UseSoftwareOpenGL)彻底消停。打包完成后我还做了系统级日志。QLoggingCategory 加上文件输出程序在任何机器上崩溃了都可以让使用者把 log 文件发回来几秒钟就能定位是数据库路径还是插件问题。没有这套日志机制跨机器部署的坑排查起来全靠猜效率太低了。7. 开发环境、调试技巧和写在最后的体会整个项目从设计到上线我用的开发环境是 Qt 5.15.2 MSVC2019IDE 用的 Qt Creator。很多人纠结 Qt Creator 和 VS Code 选哪个我的实测感受是调试 Qt 项目用 Qt Creator 的断点和变量监视非常顺QString 内容直接可读VS Code 写代码补全体验好但要配 C 插件和 CMake调试时对 Qt 类型支持差一截。建议日常写业务用 Qt Creator写后端辅助脚本再用 VS Code。调试时我有个习惯把数据库操作封装成独立的 DataService 层调试时可以直接在单元测试里调用不依赖界面。这样定位问题非常快比如工资计算不对开个控制台测试工程直接调 calcSalary(2025-03)打印每一步中间结果一眼就能看出是哪个月的数据算错了不用在界面上一步步点。另外QSqlQuery 执行出错时一定要多用 qCritical() query.lastError().text()别只看结果。执行一条 SQL 失败后错误信息能告诉你表名打错了还是字段类型不匹配直接省掉大半排查时间。最后再说一个心得工资系统这类管理软件功能做完只是开始数据安全和可追溯才是重中之重。数据库文件我用 SQLite 的加密扩展做了整体加解密。每次结算前程序自动校验所有员工工资项合计与 settlement 总额是否一致不一致直接拒绝确认。发薪操作需要管理员和财务两人分别输入口令才能提交这条业务约束用 Qt 的信号槽处理非常自然计算完成后先阻塞在等待口令状态口令验证通过才继续写库。如果你准备动手复刻我的建议是不要一上来就堆功能。先把手动输入考勤、计算工资、导出 Excel 这条最小链路跑通再逐步加导入、图表、网络同步和打包部署。每一步都能交付使用再往下加东西项目风险是可控的。工资系统最怕的不是功能少而是一个月后用户说算错了所以你留给自己的调试手段和数据校验机制永远不嫌多。本文还有配套的精品资源点击获取