企业官网建设流程全解析

1. 从需求调研到模块划分：一个工资系统该管哪些事

工资管理系统在国内的课程设计、毕业设计和中小型企业内部项目里出现频率极高，但说句实话，真正把“工资”这两个字做明白的并不多。很多人把增删改查做完就觉得够了，结果一接触真实业务就发现：考勤要不要联动？个税怎么算？社保基数搞错怎么补救？员工自己能不能查工资条？公司换了财务负责人，历史工资数据怎么归档？这些问题才是工资系统的灵魂，也是我这套基于 SpringBoot + Vue 的企业工资管理系统想重点解决的。项目完整交付内容包括后端源码、前端源码、MySQL 数据库脚本和一份可以直接照着跑的部署文档，拿到手导入数据库、改个配置就能启动。

1.1 角色权限怎么设计才不漏薪不漏税

权限设计是这类系统的第一个分水岭。普通的菜单显隐只能算“能跑”，真正要落地，必须把角色和数据范围同时管起来。我最终划分了四个角色维度：超级管理员、人事专员、财务专员、普通员工。超级管理员负责系统设置、角色授权和全局数据查看；人事专员维护员工档案、部门和考勤数据；财务专员负责工资项配置、月度核算和发放确认；普通员工只能查看自己的工资条和个人信息。

为什么要在这个小项目里较真角色划分？因为“录入考勤的人”和“核算工资的人”必须分离，这是财务流程的基本要求。一个人既管考勤又管工资，上个月给谁多记了两天加班都不容易被发现。角色分离之后，考勤和工资数据在业务上形成互相校验的关系。

数据范围同样关键。财务专员不能看到所有历史财务数据，我做得比较简单但有效：财务默认只能看到当前核算周期的数据，历史数据按年度归档；员工查询工资条时，后端强制把登录用户的 employeeId 绑定到查询条件，而不是信任前端传过来的员工ID。这个细节看着简单，实际很多项目翻车就翻在这——前端把某个员工ID传进参数，后端不加校验直接查出来，结果把别人的工资条漏出去了。工资条属于敏感性极高的个人数据，接口层面必须做“越权校验”，不能只靠前端按钮藏起来。

1.2 六大功能模块的边界怎么划

系统拆成六个模块：系统管理、人事管理、部门管理、工资管理、考勤管理、统计报表。系统管理管用户、角色和菜单；人事管理管员工档案的增删改查和离职调岗；部门管理维护组织树；工资管理是核心，包含工资项配置、月度核算、工资条查询和发放记录；考勤管理承载基础考勤数据，因为如果没有考勤联动，工资里的“扣款”和“加班费”就是空谈；统计报表给管理层看人力成本和工资趋势。

这个边界划分是从实际业务流程里倒推出来的。工资核算需要三份输入：员工基础信息（人事模块）、考勤结果（考勤模块）、工资项配置（工资模块），全部齐备才能生成一张正确的工资单。模块之间不是孤立的页面，而是通过工号（emp_no）作为主键把数据串起来。如果你拿到一套类似的项目，第一件事不要看代码，先把这几张表的关联关系画出来，后面所有问题都好理解了。

2. 数据库建模：工资数据表不是简简单单一张表

很多初学者设计工资系统时，会试图把所有字段塞进一张表：基本工资、岗位工资、绩效、加班费、迟到扣款、请假扣款、社保、公积金、个税、实发工资……一张表二三十个字段，索引建不痛快，后期加一个工资项就要改表结构，历史数据还得跟着迁移。我在这个项目里做了拆分：配置类数据和核算结果数据分开存放，这是工资系统数据库设计的一个重要原则。

2.1 核心表的字段设计与关联关系

第一张核心表是员工表employee，包含工号、姓名、性别、部门ID、岗位、入职日期、银行卡号、身份证号、在职状态。工号在业务场景里可见可打印，其他业务表统一用emp_no做关联，比用自增ID好维护。第二张是工资配置表salary_config，保存每个员工的基础工资、岗位工资、绩效基数、社保基数、公积金基数、缴费比例。第三张是工资记录表salary_record，保存某一个核算周期（年+月）的应发明细、扣款明细和实发金额。第四张是考勤表attendance，记录员工每天出勤状态。

这里有一个关键的表结构设计思路：工资项配置做成了“半固化快照”。每个核算周期生成工资记录时，系统会把当时读取到的工资配置一起写入salary_record表的冗余字段中。为什么不直接关联salary_config？因为下个月如果财务调整了绩效基数，历史工资单会跟着变，这在财务上是不可接受的。快照的意义在于：工资记录一旦生成，就与配置表彻底脱钩，历史数据永远可追溯。这条设计原则不止适用于工资系统，任何涉及“历史凭证”的业务场景都适用。

2.2 金额字段的精度陷阱

工资系统最不能妥协的就是金额精度。所有金额字段一律使用DECIMAL(12,2)，Java 后端对应使用BigDecimal。double和float在二进制浮点运算下会产生误差，0.1 + 0.2 不等于 0.3 这种问题在工资场景里会直接造成登账不平。前端金额显示统一通过过滤器保留两位小数，后端任何涉及金额的计算，都严禁使用*或/直接操作BigDecimal，必须调用multiply()和divide()方法，除法还要指定精度和舍入模式，例如divide(BigDecimal.valueOf(100), 2, RoundingMode.HALF_UP)。

另外有个容易忽略的建表细节：扣款字段和社保字段全部设为NOT NULL DEFAULT 0.00，从源头杜绝空值干扰。数据库层面再给salary_record表的(emp_no, year, month)加唯一约束，防止同一员工同一月份生成两条工资记录。别觉得这个不可能，多人并发操作时完全可能发生，后面我会专门讲事务和并发控制。

2.3 数据库脚本里预置了什么

项目配套的数据库脚本包含建表 SQL 和初始化数据 SQL。初始数据里我写好了默认超级管理员账号、四个角色、基础菜单权限和几条示例员工数据，拿到项目后直接导入 MySQL 8.0 就能跑起来。这里提醒一句：初始密码在文档里写得清清楚楚，第一次登录后必须改，别图省事。另外脚本里还顺带设置了时区相关的默认值，确保日期字段不会出现 8 小时偏移。

3. SpringBoot 后端：从登录鉴权到工资核算的实现链路

选择 SpringBoot 做后端几乎没有悬念，生态成熟、上手快、部署简单。但这个项目的难点不在 SpringBoot 本身，而是三件事：登录鉴权怎么做才安全可靠、工资批量核算怎么做才不重复不出错、Excel 导出怎么做才不卡内存。

3.1 登录鉴权：为什么我选了 Sa-Token

小体量管理系统用 Spring Security 会觉得配置繁琐，用 Shiro 又有点老，我最后选了 Sa-Token。理由很简单：API 简洁，登录、登出、权限校验各一行代码搞定；支持 Redis 扩展，将来要上集群不用推翻重写；最关键是支持注解式权限校验。关键接口加上@SaCheckRole("finance")，财务接口就只对财务角色开放。

登录流程是这样的：用户提交用户名和密码，后端用 BCrypt 密码校验器比对密文，比对通过后生成 token 返回前端，前端把 token 存在 localStorage，后续每次请求在 axios 拦截器里塞进 Authorization 请求头。

这里必须强调密码加密问题。BCrypt 算法自带盐值，同一个密码每次加密结果不同，即使数据库泄露，数据库里的密文也难以反推出明文，彩虹表基本无效。注意，如果你用了 BCrypt，初始化管理员时就要把 BCrypt 密文写进数据库，不能直接塞明文，否则登录永远比对不上。有些项目把密码用 MD5 加密存储，我强烈不建议，MD5 不具备抗暴力破解的能力，在现在的算力下太容易被还原。

3.2 工资核算的核心逻辑与税率处理

工资的计算规则是这样的：

应发合计 = 基本工资 + 岗位工资 + 绩效工资 + 加班费 + 奖金 应扣合计 = 社保个人部分 + 公积金个人部分 + 迟到扣款 + 请假扣款 + 个人所得税 实发工资 = 应发合计 - 应扣合计

社保和公积金计算需要特别小心。养老、医疗、失业保险的个人缴费比例不同，公积金比例各地政策也不一样，我在项目里把缴费比例做成了系统参数表，允许财务在后台随时调整。计算社保时还有一个基数上下限的问题：社保缴费基数有下限和上限，如果员工工资低于当地社平工资的 60%，应按下限作为基数；高于 300%，按上限封顶。这个逻辑处理不好，工资表会和社保局的实际扣费对不上账。

个税部分，小系统里可以采用按月换算的简化方式：

应纳税所得额 = 应发合计 - 个税起征点(5000) - 社保个人部分 - 公积金个人部分

然后对照月度税率表分段计算。月度应纳税所得额不超过 3000 元部分税率 3%，3000 到 12000 部分税率 10%，12000 到 25000 部分税率 20%，逐段累加。虽然真实企业用的是年度累计预扣法，但简化按月的逻辑在中小型系统里已经够用，而且更容易向客户解释。

3.3 批量生成工资记录：事务、锁与唯一约束

批量生成工资记录是整个后端最需要严谨的地方。财务选择核算月份，系统要为所有在职员工生成月度工资记录。这里要做三层检查：员工是否在职、工资配置是否齐全、本月是否已生成过。如果这两个财务人员同时点击“生成工资”，不加控制就可能出现重复记录。我的处理是三个防线一起上：数据库唯一索引兜底、代码层 synchronized 保证单机并发安全、事务回滚保证记录和明细的一致性。

生产环境实测下来，这个设计是够用的。唯一索引解决重复数据问题，synchronized 解决服务内并发问题，事务解决过程失败问题。如果项目将来要部署成多副本集群，再把 synchronized 换成 Redis 分布式锁即可。

3.4 Excel 导出：POI 换成 EasyExcel

工资条查询和月度工资总表都需要导出 Excel。我最初用 Apache POI 直接导出，几千行数据没问题，但到了几万行时内存直接飙高，页面卡死过一次。后来换成 Ali 的 EasyExcel，基于 SAX 模式逐行写入，内存占用一下子降下来了，10 万行数据也能平稳导出。

导出时另外注意两个细节：一是金额列要设置单元格数字格式为#,##0.00，避免导出后变成一长串数字或科学计数法；二是日期列必须指定yyyy-MM-dd格式，否则 Excel 打开后显示一串数字序列。这两个问题几乎每个做导出功能的项目都会遇到，属于基础但影响体验的重要细节。

4. Vue 前端：页面设计中的几个关键交互

前端我用了 Vue 2.7 + Element UI + ECharts。选 Vue 2 不是因为新，而是因为 Element UI 对管理系统这类重 CRUD 场景支持最成熟，表格、表单、弹窗、树形组件开箱即用。Vue 3 更先进，但很多周边库的坑需要额外踩，对于追求稳定交付的项目，用成熟方案更靠谱。

4.1 动态路由与按钮权限控制

前端路由不能写死，因为不同角色看到的菜单不一样。我的实现方式是：用户登录后从后端获取菜单列表和按钮权限，动态生成侧边栏菜单，按钮级权限用自定义指令v-has控制。后端返回的菜单数据结构是树形的，包含路径、标题、图标、子菜单。这样权限配置完全由数据库菜单表驱动，以后新增一个页面，只要在数据库插一条菜单记录并绑定角色，前端无需改代码就能生效。

按钮权限的粒度我建议控制到操作级别，比如“新增员工”“删除工资记录”“导出工资表”。这些按钮在后端接口上都挂了对应的角色权限注解，前端v-has指令只是控制显隐，真正的防线始终在后端。这一点要跟项目里的小伙伴反复强调：前端藏按钮是体验问题，后端验权限才是安全问题。

4.2 薪资核算与工资条页面的交互设计

工资核算页是财务的操作核心。页面左侧选择核算月份，点击“开始核算”后，后端批量计算所有人工资并落库。这里有个实际踩过的坑：如果员工数量多，核算接口耗时可能超过 axios 默认的超时时间，页面会直接报错，但数据其实已经算了一半。我的解决办法是：核算接口单独设置 30 秒超时，同时前端加了防重复点击，并在核算完成后主动刷新工资列表，避免用户看到不一致的中间状态。

工资条页面做成了员工自助查询。员工登录后只能看到自己的工资条。展示层我专门做了打印友好的视图，用 CSS 控制在 A4 纸张上的打印效果。这里有个实用细节：工资条打印时，每张都要有“员工姓名 + 月份”的标题，防止多名员工工资条裁剪后混在一起分不清。打印内容默认隐藏页面菜单和按钮，只保留工资明细区域，这样员工可以直接用浏览器打印成 PDF 或纸质版。

4.3 前后端联调时最容易出问题的几个点

联调阶段的问题，大部分出在跨域和参数格式上。本地开发时在vue.config.js里配置 devServer 代理，将所有/api前缀的请求转发到后端 8080 端口，开发环境不需要后端开跨域。部署环境则通过 Nginx 反向代理统一处理/api请求，前端请求只写相对路径，不写死 IP。

axios 拦截器是所有管理系统前端的标配。请求拦截器把 token 塞进 Authorization 请求头；响应拦截器统一处理错误码，遇到 401 就清空登录状态并跳转登录页。这个小机制如果没做，就会出现“登录过期后接口报错，用户一头雾水”的尴尬场面。另外，统一封装后，所有接口的错误提示风格也能保持一致，不会有的页面弹 alert，有的页面静默失败。

5. 部署、测试与真实使用中的避坑清单

项目交付时我习惯把内容整理成四块：后端源码、前端源码、数据库脚本、部署文档。部署文档里写清楚环境要求、导入步骤、账号配置、核心功能说明和常见问题，确保接手的人哪怕没写过这个项目，也能在一小时内跑起来。很多人忽略文档的价值，实际上一个系统能不能交付得漂亮，文档占一半的功劳。

5.1 后端打包与数据库连接配置

后端打包用 Maven 执行mvn clean package，生成一个可执行 jar。如果项目里引用了本地 jar 包，要用 Maven 的 install 命令先装进本地仓库，否则打包时会报找不到依赖。数据库连接配置在application.yml里，项目默认连接 MySQL 8.0，驱动类名是com.mysql.cj.jdbc.Driver，如果你的环境还是 MySQL 5.7 或更老版本，这个配置需要换回com.mysql.jdbc.Driver。

时区问题也特别提醒一下：连接串里加上serverTimezone=Asia/Shanghai，否则日期字段容易比实际时间早 8 小时。这个问题在国内容器化部署场景里尤其常见，因为容器默认时区是 UTC。MySQL 连接串的正确写法大致是：

spring: datasource: url: jdbc:mysql://localhost:3306/salary_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver

5.2 Nginx 部署前端时的三个关键配置

前端构建采用npm run build生成 dist 静态资源目录，再把 dist 内容放到 Nginx 的 html 目录下。Nginx 配置里关键有三块：一是静态资源和接口的路径区分，二是 history 路由模式下的兜底配置，三是接口反向代理。history 路由模式下如果用户刷新某个子页面，Nginx 找不到对应文件会返回 404，必须配置try_files兜底到 index.html。代理部分把/api转发到后端服务，前端不用感知后端真实地址，以后后端迁移时只需要改 Nginx 配置。

5.3 上线前必做的业务验证清单

我每次交付前都会按这份清单过一遍：初始管理员账号能否正常登录并修改密码；新增员工后能否配置工资项并生成工资记录；同一员工同一个月生成两次记录是否会被拦截；导出 Excel 后金额格式是否正确；员工账号是否只能看到自己的工资条；普通员工直接调用后端财务接口是否会被拒绝。这些验证覆盖了工资系统最核心的业务闭环，全跑通才敢说项目“完成”。

5.4 真实使用中常见的业务坑

实际使用中还会遇到一些业务上的坑。比如员工离职后，账号要不要立刻禁用？答案是必须的，否则离职员工还能登录系统查看历史工资条，这属于数据安全事件。我用状态字段控制账号有效性，离职流程除了改员工状态，同时禁用对应的登录账号。

再比如输入校验的边界：财务误操作把绩效填成负数，系统能不能拦住？我在保存逻辑里加了对应发合计和应扣合计的校验，应发不能小于 0，扣款合计不能大于应发合计，数据异常时直接拒绝保存并给出明确提示。这些边界校验虽然不复杂，但正是它们决定了一个管理系统是“玩具 Demo”还是“能用的工具”。

还有一个小坑格外值得记录：工资金额偶尔会出现“分”以下的误差，这是除法换算时四舍五入造成的。我在每一步除法里都指定了RoundingMode.HALF_UP，并统一保留两位小数，最后实发工资再校验一次与应发、应扣的差值是否小于 0.01，从机制上保证账目永远平得上。

我个人在实际操作中体会最深的一点是：工资系统的难点永远不在技术框架，而在对业务规则的尊重。数据库精度、快照历史、权限隔离、并发控制，这些看似零散的点，其实都指向同一件事——让每一分钱都有据可查。如果你也在做类似系统，建议先别急着写代码，把业务角色和数据流转画清楚，后面所有技术选型都会顺理成章。

最后再分享一个小技巧：整套系统跑通后，记得把工资条导出和打印样式做成可配置项。不同企业对于工资条包含哪些字段、打印需要几联，要求差别很大，前端把这两个点做成动态配置，能省掉后续大量的定制维护工作。这套系统目前的 RABC 权限模型、快照式工资记录和 SAX 流式导出，就是为这些定制留的口子，等项目真正落到某个企业里，你就能体会到当初这些设计带来的好处了。