简介面向企业级Windows应用开发学习者的C#工资管理系统完整源码包对应“BN083-工资系统”项目覆盖员工信息管理、薪资计算、数据库操作、界面交互与报表生成等核心模块。压缩包共372个文件大小3.95MB其中包含130个cs源文件、69个resources资源文件、40个dll库、35个resx界面资源以及配置、图标、图片和数据库文件可清晰看出基于WinForms/ADO.NET的经典分层结构。已有258人学习下载。通过源码可掌握类与对象设计、LINQ查询、事件委托和异常处理等关键技巧理解工资计算中复杂业务规则的封装方式同时可参照项目文件组织与模块划分提升自身在企业信息化系统开发中的实战能力。适合具备一定C#基础、希望系统学习桌面应用开发或快速搭建工资管理原型的开发者。 2022年的时候一个做贸易的朋友找到我——公司两百多号人财务每月用Excel算工资光加班费和请假扣款就要折腾两三天还经常出错。他问我能不能给一套工资系统的C#源码因为公司内部只会WindowsIT环境也是微软系。我原以为网上随便就能找到一套靠谱的开源项目结果翻了一圈要么技术栈是十几年前的WebForms要么把工资规则写死在代码里换一家公司就得改源码。最后我只能自己动手用C#从头写了一套。这套系统从2022年底跑到现在中间经历过多次重构也踩了不少只有在发工资当天才会暴露的坑。这篇文章把我的设计思路、核心代码和经验教训整理出来希望能给同样想自己实现工资系统的C#开发者一些参考。在我开始动笔之前先给这套系统定个位它面向的是中小型公司员工规模几百人月度工资计算考勤数据从Excel或打卡机导入计算结果导出财务软件或银行代发文件。不需要ERP那样的大而全但必须稳定、可追溯、权限清晰。以下是这套系统从建模到实现再到踩坑的全过程记录。1. 为什么我会用 C# 写一套工资系统1.1 现成的轮子为什么不好用找开源项目的经历让我很失望。GitHub上C#写的工资系统大体分两类一类是教学Demo只有员工增删改查加一个简单工资表没有计算引擎、没有扣款规则、没有导入导出另一类是某个企业内部的定制系统代码里写满了那个公司的部门和岗位名称换一家公司根本跑不起来。最要命的是很多项目早就停止维护UI停留在WinForms早期风格数据库还是Access或SQL Server 2000时代的写法。工资系统的难点从来不是CRUD而是业务规则。同样叫加班费A公司规定工作日加班1.5倍、休息日2倍、法定节假日3倍B公司规定所有人都是固定加班补贴不管加几个小时。社保基数、公积金比例、专项附加扣除、迟到扣款、全勤奖每个公司都有自己的组合方式。如果这些规则全部写死在代码里系统交付的第一天就是重写代码的开始。1.2 技术选型C# 的优势正好命中需求做这个项目之前我对比过几条技术路线Java、Python、C#。之所以最终选C#不是因为它最流行而是因为它有几个和工资系统特别契合的点。强类型和decimal类型。工资计算绕不开金额而C#的decimal类型专门用于高精度十进制运算不会出现double那种1.12.23.3000000000000003的问题。这一点对财务场景是致命的也是我后面会反复强调的细节。桌面端和Web端通吃。这套系统最初以局域网桌面客户端运行WPF做界面直接连接SQL Server。后来管理层要求支持远程查看工资条我用ASP.NET Core Web API重写了服务端UI部分换成Vue。C#从桌面到服务端的平滑过渡让这次迁移没有伤筋动骨。成熟的ORM和生态。EF Core、SqlSugar、Dapper随便选数据库从SQL Server替换成MySQL或PostgreSQL也就是改个连接字符串的事。对中小公司来说这降低了部署和运维的门槛。我用一张表说明当时的选型对比方便你也从自己的团队能力出发判断。方案开发效率金额计算精度部署维护合适场景C# WinForms/WPF SQL Server高高decimal原生支持局域网部署需要每个客户端装.NET环境公司内部Windows环境C# ASP.NET Core Web API高高一台服务器浏览器访问最省事多分支、移动办公Java Spring Boot中高依赖JVM服务器部署团队Java技术栈Python Flask/Django中中float需小心处理中等小型、非财务核心PHP高开发快中简单已有PHP系统集成最终我采用了WPF客户端 Web API的混合架构核心是独立的数据访问层和计算引擎WPF客户端负责录入员工和工资项目、发起计算Web端负责员工自助查询工资条和HR审核流程。这样的结构让核心逻辑不依赖具体UI换界面只是换壳。2. 数据建模别把工资系统做成员工花名册2.1 基础表之外多一张工资项目配置表很多人设计工资系统的时候上来就建一张Salary表字段是员工ID、基本工资、岗位工资、绩效奖金、加班费、社保、公积金、个税、实发工资。这种设计在初始化时看起来很直观但第一个月发工资就会遇到问题老板临时说这个月每人补发500元高温津贴你就得给表加一个高温津贴字段下个月改成通讯补贴300元你又得加字段。一年下来Salary表会多出几十个名为各种补贴的列SQL查询要靠动态拼字符串才能查出工资条。正确的做法是把工资项目做成数据。我设计了这样几张表Employee员工基本信息工号、姓名、部门、入职日期、离职日期、银行卡号SalaryItem工资项目定义项目编码、项目名称、加减项标志、是否参与计税、排序EmployeeSalaryItem员工与工资项目的关联员工ID、项目编码、金额用来记录底薪这类因人而异的固定项SalaryDetail每月工资明细员工ID、工资月份、项目编码、金额SalaryHeader每月工资汇总员工ID、工资月份、应发合计、扣款合计、实发金额、发放状态PayRecord发放记录发薪批次、员工ID、实际发放日期、银行流水号SalaryDetail存的是每个员工每个月每个岗位的金额明细这意味着一个员工一个月会有多条记录但换来的是极大的灵活性。任何项目都可以临时加入不需要改表结构不需要发版升级。比如2023年7月公司要补发一笔高温补贴只需要在SalaryItem表里插入一个项目计算月选择202307系统就会自动为每个员工生成一条明细。2.2 金额字段必须用 decimal别碰 float这是我在代码评审时反复强调的一点。数据库里所有金额字段都用DECIMAL(18,2)C#实体类里全部用decimal。原因很简单float和double是二进制浮点数无法精确表示0.1这样的十进制小数。工资计算不是物理仿真不需要科学计数法的动态范围它需要的是财务上的一分不差。// 错误示范 double baseSalary 20000.0; double bonus 6666.6; double total baseSalary bonus; // 26666.599999999998 // 正确用法 decimal baseSalary 20000.0m; decimal bonus 6666.6m; decimal total baseSalary bonus; // 26666.6连接数据库时还要注意SQL Server 的decimal映射到C#的decimal没有问题但如果是MySQL驱动有时候会把DECIMAL映射成decimal用EF Core的话可以通过HasColumnType(decimal(18,2))显式指定避免默认映射成double造成精度丢失。2.3 工资快照为什么不能只存当前值还有一个设计容易忽略员工的底薪会变社保基数每年调这月入职下月涨薪很常见。如果工资系统只读取员工档案的当前底薪来计算那三个月后再打开本月的工资单金额可能就和当初发的不一致——因为底薪已经变了。所以在每个月生成SalaryHeader时我会把计算依据的员工基础信息底薪、岗位工资、社保基数等复制一份写入SalarySnapshot表。这张表相当于计算时点的快照保证了历史数据永远可追溯。审计时打开任何一个月的工资单看到的都是当时计算用的原始数据而不是被后来的调整污染过的值。3. 工资计算引擎策略、反射与精度控制3.1 把每个工资项目做成一个策略工资计算最忌讳写一个几百行的CalculateSalary()方法里面用switch case判断几百个工资项目。我的做法是定义一个规则接口每个工资项目或同一类计算逻辑实现一个类public interface ISalaryRule { string ItemCode { get; } string ItemName { get; } bool IsAddItem { get; } decimal Calculate(Employee employee, SalaryContext context); } public class BaseSalaryRule : ISalaryRule { public string ItemCode BASE; public string ItemName 基本工资; public bool IsAddItem true; public decimal Calculate(Employee employee, SalaryContext context) { // 按实际出勤天数折算 return employee.BaseSalary * context.ActualWorkDays / context.Policy.WorkDaysOfMonth; } } public class AbsenceDeductionRule : ISalaryRule { public string ItemCode ABSENCE; public string ItemName 请假扣款; public bool IsAddItem false; public decimal Calculate(Employee employee, SalaryContext context) { if (context.LeaveDays 0) return 0; var daySalary employee.BaseSalary / context.Policy.WorkDaysOfMonth; return daySalary * context.LeaveDays; } }SalaryContext里放这个月相关的参数实际出勤天数、请假天数、加班小时数、社保公积金基数等。计算引擎本身非常简洁public class SalaryCalculator { private readonly ListISalaryRule _rules; public SalaryCalculator(ListISalaryRule rules) { _rules rules; } public ListSalaryDetail Calculate(Employee employee, string salaryMonth, SalaryContext context) { var details new ListSalaryDetail(); foreach (var rule in _rules) { var amount rule.Calculate(employee, context); if (amount 0) continue; details.Add(new SalaryDetail { EmployeeId employee.Id, SalaryMonth salaryMonth, ItemCode rule.ItemCode, ItemName rule.ItemName, Amount IsAddItem ? amount : -amount }); } return details; } }3.2 用反射自动注册规则扩展业务不再改主流程每实现一个新的工资项目就要在计算引擎里手动Add一次时间长了容易漏。我借用了反射机制让系统启动时自动扫描程序集中所有实现ISalaryRule的类并注册var ruleType typeof(ISalaryRule); var rules Assembly.GetExecutingAssembly() .GetTypes() .Where(t ruleType.IsAssignableFrom(t) !t.IsInterface !t.IsAbstract) .Select(t (ISalaryRule)Activator.CreateInstance(t)) .ToList();这样做的好处是新增一种补贴或扣款时我只需要新建一个类文件实现ISalaryRule不用改动计算引擎的注册代码。对于那种这个项目只有这个公司有的业务规则这个机制简直是写多少规则都不污染主流程。而且这种设计在单测时也很舒服每个规则可以独立测试不用为了测一个加班费而准备整条工资链路。3.3 舍入策略财务系统的一分钱之争工资计算的舍入问题比想象中更容易翻车。C#里Math.Round默认采用银行家舍入四舍六入五成双也就是当小数位是5时会舍入到最近的偶数。比如Math.Round(1.235, 2)在默认情况下等于1.24但Math.Round(1.225, 2)可能返回1.22因为2是偶数。财务上通常要求的是四舍五入所以必须显式指定MidpointRounding.AwayFromZerodecimal amount Math.Round(rule.Calculate(employee, context), 2, MidpointRounding.AwayFromZero);另一个被忽略的点是分步舍入和整单舍入的区别。比如应发工资是10000.505元如果每个工资项目先舍入到分再加总和先加总再舍入到分结果可能差一分钱。很多财务对这个非常敏感因为最后总得对上银行代发文件的总额。我在系统里统一使用先逐项舍入到分、再汇总的方式并且在配置中设置一个RoundingMode字段当发现尾差超过允许误差时允许手工调整到某个项目上。这个手工调差虽然看起来土但实际使用中财务很喜欢。3.4 性能与事务边界月度算薪通常是批量操作遍历所有员工逐个计算最后写入数据库。这里要注意几个问题不要在循环里反复打开数据库连接直接一整个批次用同一个DbContext。计算过程要保证事务性如果第150名员工计算失败整个批次的明细和汇总都不能写入否则会出现上半个月工资发了下半个月没发的数据不完整。批量计算时间通常不会太长几十万条明细级别也就十几秒用Parallel.ForEach可以进一步压缩时间但要注意EF Core的DbContext不是线程安全的所以并行时要为每个线程单独创建上下文。using (var transaction await db.Database.BeginTransactionAsync()) { foreach (var employee in employees) { var details _calculator.Calculate(employee, month, context); db.SalaryDetails.AddRange(details); db.SalaryHeaders.Add(BuildHeader(employee, month, details)); } await db.SaveChangesAsync(); await transaction.CommitAsync(); }4. 发工资当天才会暴露的坑与排查过程4.1 月末入职与计薪周期不一致第一个坑出现在系统上线第三个月。一位员工6月29日入职结果工资单上应发工资是负几十块——因为我的BaseSalaryRule把基本工资按出勤天数折算而考勤模块把6月最后两天算成了缺勤。排查下来发现是两个问题叠加一是入职当月的应出勤天数计算没有考虑入职日期把所有工作日都算成了应出勤二是当月实际出勤没有取最大值导致两天的差值变成了扣款。修复逻辑并不复杂但让我意识到工资系统的日期边界非常苛刻。正确的折算公式应该是// 入职当月的实际工作天数 min(应出勤天数, 入职日期到月末的工作日数) var actualWorkDays Math.Min(monthlyWorkDays, WorkdaysBetween(employee.HireDate, monthEnd));从那以后我把所有关于当月天数、入职离职折算、考勤周期的逻辑集中到一个CalendarHelper类里统一用DateTime.DaysInMonth、枚举工作日、计算两个日期之间的工作日等API避免各处自己写一份又互相矛盾。4.2 文本框失去焦点导致导出旧数据这个问题在WPF客户端里出现过一次现象是用户在加班补贴文本框里手动输入了500但点击导出工资表按钮后Excel里还是300。原因很经典——WPF的TextBox.Text默认绑定更新方式是LostFocus也就是要等输入框失去焦点才会把值写回ViewModel。用户输完数字没按Tab也没点别处直接点了导出按钮按钮的事件触发时文本绑定的值还没有更新。排查时不看绑定根本发现不了。修复方法有两个一是对实时性要求高的输入框把UpdateSourceTrigger改成PropertyChanged二是在按钮点击时主动强制更新绑定private void ExportButton_Click(object sender, RoutedEventArgs e) { var binding TxtBonus.GetBindingExpression(TextBox.TextProperty); binding?.UpdateSource(); // 此时ViewModel里的Bonus才是页面显示的值 ExportSalaryToExcel(); }这个坑看起来小但在工资系统里就是实打实的资金差异。我在这里提示所有做桌面端数据录入的同行任何先输入后点按钮的场景都要确认输入框的绑定更新时机。4.3 扫码枪被当成键盘输入这个是考勤模块的经典问题。公司的打卡机导出的考勤文件经常要手动补录财务用扫码枪刷员工工牌来快速定位员工。但扫码枪本质是一个HID键盘设备它把条码/二维码内容模拟成键盘按键输入并且通常在末尾带一个回车。问题在于扫码枪扫入工号时的输入速度远远快于人手敲键盘如果界面上有多个文本框焦点在哪个框内容就进哪个框经常出现工号跑到了加班时长框这种离谱情况。我的处理方案是不依赖焦点改用全局键盘钩子或者RawInput模式接收扫码枪输入。如果不想引入系统级钩子还有一种简化的折中方案在文本输入事件中记录相邻两次键盘事件的时间间隔如果连续多次间隔小于20毫秒判定为扫码枪输入这样可以在处理时屏蔽掉手动键盘的干扰。private DateTime _lastKeyTime; private void TxtInput_PreviewKeyDown(object sender, KeyEventArgs e) { var now DateTime.Now; var diff (now - _lastKeyTime).TotalMilliseconds; _lastKeyTime now; if (diff 20) { _isScannerInput true; // 扫码枪高速输入 } }如果从源头上解决最稳妥的办法是让扫码枪工作在串口模式通过SerialPort读取而不是用键盘模拟。但考虑到设备成本我在软件层做兼容处理效果也够用。4.4 并发审核工资被重复发放系统上线半年后HR和财务各有一个账号都能执行审核发放操作。某次两个人几乎同时点了审核按钮结果PayRecord里生成了两笔发放记录后续对接银行代发文件时多出了一倍金额。排查后发现是缺少幂等控制。解决方案有两个层面一是状态机层面SalaryHeader的状态必须在代码中流转草稿→待审核→已审核→已发放每次改状态都带WHERE Status oldStatus条件如果更新影响行数为0说明状态已被别人改过需要拒绝操作二是数据库层面给PayRecord表加唯一索引(EmployeeId, SalaryMonth)保证一个员工一个月最多只能有一条发放记录。两条同时用上并发审核的问题才算根治。var header await db.SalaryHeaders.SingleOrDefaultAsync(h h.Id id); int affected await db.Database.ExecuteSqlRawAsync( UPDATE SalaryHeader SET Status newStatus WHERE Id id AND Status oldStatus, new SqlParameter(newStatus, Approved), new SqlParameter(id, header.Id), new SqlParameter(oldStatus, header.Status)); if (affected 0) { throw new InvalidOperationException(该工资单已被人修改请刷新后重试); }5. 源码目录结构与后续扩展思路5.1 我使用的项目分层写到这里顺便说下源码的目录组织。由于这套系统一开始就打算核心逻辑与UI解耦所以解决方案里我分成了几个项目src/ ├── Salary.Core/ # 核心类库实体、接口、计算引擎 │ ├── Models/ │ ├── Rules/ # 工资项目规则实现每个类一个规则 │ └── Services/ ├── Salary.Infrastructure/ # 数据访问EF Core、仓储实现 ├── Salary.Application/ # 应用服务事件、批量计算、导入导出 ├── Salary.WebApi/ # ASP.NET Core Web API 接口层 └── Salary.WpfClient/ # WPF 桌面客户端或之前的WinForms版本这样分层的最大好处是Salary.Core不依赖EF Core和具体数据库计算引擎可以独立单元测试。后来我把Web端的前端换成Vue 3完全没有动Salary.Core一行代码。如果只想做局域网桌面工具可以把WebApi项目去掉WPF直接引用Application和Infrastructure。5.2 迁移到 Web 端时要注意的几个点从WPF客户端转到ASP.NET Core Web API时我踩了几个坑提醒一下数据库连接池桌面端一个程序一个连接Web端并发高要合理设置连接池上限EF Core默认的连接池在几百并发时可能会不够。敏感字段过滤工资API返回员工数据时银行卡号、身份证号等字段要做脱敏处理保留前4位后4位中间打码不能让员工通过API拿到全量花名册。接口鉴权员工自助查工资条只允许查自己的绝不能传一个employeeId就返回别人的工资。我用ClaimTypes.NameIdentifier从JWT里取当前登录工号服务端强制校验。5.3 这套系统还能往哪些方向扩展由于数据模型把工资项目配置化了后续扩展非常顺手。我曾经给另一个客户部署时只新增了两个规则类就支持了按件计薪的产线工资模式。另外几个方向值得提前规划对接银行代发生成银行要求的TXT代发文件核心是字段分隔符和金额格式这部分可以抽象成独立的IFileExporter接口不同银行一个类。对接考勤机网络考勤机大多提供HTTP协议或SDK把原始打卡记录导入到独立数据库再做规则匹配不需要改计算引擎。多账套支持一家公司下面有多个独立核算的部门可以在表上增加AccountSetId字段所有查询按这个字段隔离。奖金池分摊团队奖金、部门绩效奖分摊到个人时用decimal的高精度计算能避免按比例分摊后的尾差问题分摊时最后一个人用总额减去前面所有人已分摊之和保证总和恒等于奖金池金额。最后再分享一个我个人的经验工资系统是典型的业务规则远比技术复杂的系统。写代码前先去财务那里坐半天看她们怎么用Excel算工资、导数据、核对每一位金额。你照着她们的Excel表结构去设计数据库字段大概率不会错反之如果一开始就想着我要设计一个牛逼的引擎最后做出来的东西很可能没人愿意用。这套C#系统的源码我现在还在维护每次新增规则、修复边界情况时最开心的时刻是财务说这次算出来的数跟我手算的一模一样。这句话比任何技术评价都珍贵。本文还有配套的精品资源点击获取