企业官网建设流程全解析

前阵子给一家两百人左右的中型企业做了一套基于Python + Vue3的企业员工考勤打卡薪酬绩效管理系统。这套系统让我重新认识到一件事：市面上的考勤SaaS、薪酬管理工具确实多，但真正要贴合一家公司自己的考勤口径、绩效系数算法和四类角色的权限边界，还是自研最省心。本文不聊销售话术，只把项目从需求梳理、后端核心模块、前端工程化到权限落地，再到开发过程中真实踩过的坑，完整拆给你看。如果你正好在做考勤系统、薪酬管理后台，或者想从零搭一个Vue3 + Python的管理类项目，这篇能帮你少走不少弯路。

1. 项目定位与四角色权限设计思路

1.1 这套系统到底解决了什么问题

很多中型企业到月底发工资前，行政要从Excel里整理考勤，财务要核对病假事假加班工时，主管要在月底突击打分，最后财务再拿绩效结果和考勤表手工算工资。我接手这家企业时，光对齐"迟到多久算迟到"就开了两次会。所以这套系统的第一个目标不是炫技，而是把考勤、薪酬、绩效三件事放进同一个数据流里：考勤表记录原始数据，绩效模块产出绩效系数，薪酬模块读取两边的结果生成工资条。数据只有一份，口径统一，月末核算时间从三天压缩到半小时。

业务闭环是这类系统的灵魂。考勤记录不只是给员工看打卡成功的，它要支撑请假扣款、迟到统计、加班费计算；绩效评分也不是走个过场，最终要换算成系数去影响工资。所以我在设计数据库时，就把考勤表、考核表、薪酬表之间的关联字段提前预留好，而不是等开发到薪酬模块再回头改表结构。实际开发中，这一步做得越扎实，后面写业务逻辑越顺。

1.2 四个角色的权限边界怎么划

这四个角色是系统管理员、员工、部门主管、HR专员。每个角色看到的数据范围完全不一样。系统管理员负责用户管理、角色配置和基础数据维护，不参与日常业务；员工只能看到自己的打卡记录、工资条和绩效结果；部门主管能看到本部门所有员工的考勤和绩效，负责审批申请单；HR专员拥有全公司考勤复核、薪酬核算和绩效汇总的权限。

我把权限矩阵整理成了下面这张表，后面所有前后端代码都是围绕这张表展开的：

这样一个矩阵下来，核心思路是权责分离：主管有审批权没有算薪权，HR有算薪权但需要主管先确认考勤和绩效，避免了一句话改工资的人为风险。很多同类系统败就败在权限粒度太粗，要么主管能看全公司工资，要么HR没有数据入口，所以我建议在需求阶段就把这张矩阵反复和客户确认清楚再动手。

1.3 为什么选择Python + Vue3这个组合

后端选型上，我用的Django REST Framework。Python生态里做这种管理系统是真的很顺手，ORM直接映射考勤表、薪酬表，Django Admin在后端调试阶段可以直接当管理后台用，权限体系用DRF的permission_classes就能控制接口级访问。考勤统计和薪酬计算需要大量日期处理、聚合计算，Python的标准库和pandas用起来比Java那套痛快很多。

前端则是Vue3 + Vite + Element Plus + Pinia。对比Vue2，Vue3的组合式API在复杂表单页面里很好用，同一个考勤打卡页面里的状态、定位、防重复提交逻辑可以按业务切分，而不是全部堆在data里。至于很多人纠结的TypeScript，我的建议是团队不熟悉可以先用JS，把业务跑通，后期逐步加类型定义，比强行TS导致项目卡顿要实际。Vite的开发体验也是明显加分项，冷启动基本在一秒内，调试效率比webpack时代高一大截。

2. 后端核心模块实现：考勤、薪酬、绩效

2.1 考勤打卡：从数据建模到迟到早退判断

打卡模块我一开始想得简单，不就是记录上班、下班两个时间点，结果被业务细节教了一课。首先是考勤规则表，每个部门和岗位的上下班时间不一样，有的部门是九点到六点，有的岗位实行弹性打卡，午休时长也不一样。我的做法是设计一张AttendanceRule表，包含部门、岗位、上班时间、下班时间、迟到宽限分钟、午休时长等字段。员工打卡时，后端根据员工所属部门岗位，动态读取对应的规则表来判断状态。

打卡记录表AttendanceRecord存员工、日期、上班打卡时间、下班打卡时间、加班开始时间等，状态字段区分正常、迟到、早退、缺卡、休息日加班等。判断逻辑放在后端：把上班打卡时间换算成分钟数，减去规则里的上班时间，结果是正数就是迟到，在宽限分钟内的不计迟到，下班时间小于规则下班时间且超过宽限即早退。这套计算逻辑放后端而不是前端，是为了防止有人修改浏览器时间造成数据脏，前端只负责展示状态和调接口。

这里有个实战细节：打卡接口一定要做幂等设计。用户连点两次打卡按钮，后端先查当天是否已有记录，有则直接返回当前状态，不再生成第二条。打卡方式方面，只靠GPS定位容易被模拟，我建议企业同时绑定办公WiFi的SSID，员工连接指定WiFi才能打卡，既准确又防代打。

2.2 薪酬计算：工资单是怎么一步步算出来的

薪酬计算是整个系统最容易被"业务"绑架的模块。我刚做完第一版只算了基本工资加绩效，结果财务说漏了加班费、扣款、补贴，还要支持转正前后薪资不同。后来我把薪酬拆成了三个步骤，每一步都有明确的输入输出。

第一步从考勤模块拉取月度汇总：迟到次数、缺勤天数、加班时长、请假类型和天数。第二步读取员工基础薪资表，拿到基本工资、绩效工资基数、补贴金额，再结合绩效模块给出的绩效系数，按公式算出应发工资：应发工资 = 基本工资 + 绩效工资 × 绩效系数 + 加班费 + 补贴 - 缺勤扣款 - 迟到扣款。加班费按日工资除以8小时乘1.5倍计，法定节假日是3倍，这些口径写成配置项而不是硬编码，因为明年税率规则可能变。

第三步计算个税，用累计预扣法。这一步很多人会偷懒直接网上搜一个公式，但实际运行时你会发现边界情况特别多，比如本月有年终奖要分摊、员工入职不满一个月、专项附加扣除变动等。我就吃过这个亏，后来才规范成统一函数处理，单月算薪和年度累计都走同一套逻辑。工资条生成后，员工端只能看自己的，HR端能看全公司，主管端没有任何薪酬查看入口，这是角色权限的硬约束。

2.3 绩效管理：指标、权重和评分闭环

绩效模块我做成了三层结构。第一层是KPI指标库，存放公司统一的考核指标，比如出勤率、任务完成率、客户满意度，每个指标有默认权重。第二层是考核表，HR给每个员工分配指标和权重，员工自评、主管初评、HR复核，最后加权得到综合分。第三层是系数映射，比如90分以上对应系数1.2，80到90对应1.0，70到80对应0.8，70以下对应0.6。

这里的核心点是绩效结果不要手工录入薪酬表，而是让薪酬模块直接读取考核表里的最终系数，形成数据联动。不然每个月底财务又要拿着一堆Excel去对号入座，系统就白做了。我当时还加了一个保护逻辑：考核表状态只有"已确认"的数据才能被薪酬模块读取，草稿状态的评分一律不参与计算。这样做防止了主管还在初评阶段时，HR那边已经按旧数据把工资算完的尴尬。

3. Vue3前端工程化实战

3.1 从Vite搭建到基础请求封装

前端我直接用Vite创建Vue3项目，Vite启动速度比webpack快很多，Vue3响应式系统基于Proxy，编译和运行时的性能都有提升。项目里我安装vue-router、pinia、axios、element-plus，另外加了dayjs处理日期，这套组合基本是Vue3后台管理系统的标准配置。

axios封装这块很关键。请求拦截器从localStorage读token，统一加到Authorization头；响应拦截器判断HTTP状态码，如果是401就跳登录页，如果是业务错误码就弹出提示。这样业务代码里不需要每个接口都写catch错误处理，写接口方法时只需要关注返回数据的结构。封装的代码不多，但每个项目我都要求团队先写这个再写业务，否则后续几十个页面都在复制错误处理，改一个错误提示语都要全量搜一遍替换。

Vue3的组合式API在这里体现出的优势很明显。比如考勤打卡页面的定位逻辑、打卡状态、防重复提交按钮，可以拆成独立的useClockIn函数，在多个页面复用；薪酬模块的格式化方法也可以单独抽成composable，避免每个页面重复写toFixed和千分位转换。这些代码组织方式的改进，是Vue2时代用mixin很难做到的。

3.2 动态路由与按钮级权限

后台管理系统最常见的问题就是不同角色登录后菜单不一样。我的做法是登录成功后，后端返回当前用户的角色标识和菜单列表，前端把这些菜单转成路由对象，用router.addRoute逐个注册。比如HR登录能看到薪酬核算页面，员工登录就看不到，即便手工输入路由地址访问，也会被全局前置守卫拦下来。

接着是按钮级权限。菜单只能控制大功能入口，但同一张考勤列表里，主管有审批按钮，员工没有，这就得用自定义指令v-permission。指令里传入权限码数组，如果当前用户权限码不匹配，直接移除按钮DOM元素。我有一段模板代码是这样实现的：Vue.directive里根据permission列表判断元素是否有权限，没有就remove()。这样菜单、路由、接口、按钮四个层面都做了控制，真正做到员工页面里不进薪酬模块的代码，数据安全上我心里才有底。

3.3 考勤打卡页面的关键交互

打卡页面是整个前端交互最密集的地方。页面顶部是一张当天的状态卡片，显示当前时间、上班打卡时间、下班打卡时间和状态提示。打卡按钮要做到防连点，我用了两种手段：前端按钮在请求期间加loading并禁用，后端接口做当天记录幂等校验，双重保障。

打卡成功后要刷新Pinia里的今日考勤状态，不然用户切换页面再回来，看到的还是打卡前的状态，这个坑很容易被忽略。页面中间是考勤日历，用Element Plus的日历组件改造，把每个月的出勤情况打点标色，正常绿色、迟到黄色、缺勤红色，一眼看出全月情况。

补卡申请和请假申请都用了日期范围选择器，校验规则必须写清楚：补卡日期不能晚于今天，请假区间不能和已有请假重叠，用rules对象里的validator自定义校验。很多开发者只会用required，结果员工周五请三天假，系统把周六也算成请假天数，财务那边就会闹乌龙。日期范围校验要专门处理跨月、跨年场景，dayjs的diff、isBefore、isAfter方法在这里特别好用。

3.4 薪酬绩效页面的可视化呈现

薪资核算页面我分了两部分。HR端是月度薪资汇总表，表格支持按部门筛选、导出Excel，员工端是工资条形式，把基本工资、绩效工资、加班费、扣款项列清楚，点击查看明细时用抽屉展示计算过程。

绩效页面则用echarts画雷达图和柱状图，雷达图对比员工各维度得分，柱状图看部门绩效分布。这里要注意一个大屏页面和普通页面要尽量复用同一个接口，只是组件不同，避免为了做看板单独写一套统计接口，维护成本会很高。我习惯把所有统计接口都放在dashboard这一个viewset下，后端按角色返回不同粒度，前端再按场景渲染。薪酬这块数据比较敏感，表格里凡是涉及金额的列，都通过权限判断后再决定渲染还是不渲染，而不是简单把列隐藏，因为隐藏列在浏览器控制台里还是能改出来的。

4. 四角色权限的落地细节与审批闭环

4.1 菜单权限和数据权限两层设计

菜单权限解决"能不能看到这个功能"，数据权限解决"能看到哪些数据"。这两层容易混。比如部门主管和HR都能看到考勤汇总菜单，但主管打开只能看到本部门员工的记录，HR能看到全公司，靠的就是后端在Queryset上加过滤条件。

我用Django的get_queryset里根据request.user.role判断，角色是主管就按部门过滤，是HR就全量返回。系统管理员虽然能进所有菜单，但正常情况下不操作业务数据，只维护用户和角色配置。后台的权限控制我做了三层：底层是Django自带的用户组权限，中间层是DRF的permission_classes控制接口访问，业务层再按角色做数据过滤。这套组合下来，考勤薪酬这类敏感数据才算真正关进了笼子里。

4.2 请假、加班、补卡三条审批流怎么嵌套

审批流我实现成了一张统一的Approval表，字段包括审批类型、关联业务ID、当前状态、审批人、审批意见。请假、加班、补卡都复用这张表，只是业务类型不同。流程是员工提交→主管审批→HR确认，状态机用0待审批、1通过、2驳回三段。

关键点在于审批通过后要回写业务数据，比如请假审批通过，考勤模块要生成一条请假记录，补卡审批通过后要把缺卡状态改成正常。这个回写逻辑放在审批状态变更的事务里，避免出现审批通过但考勤数据没更新的情况。我踩过这个坑，上线第一天有员工补卡审批通过，考勤还是缺卡，后来加了事务处理后就没再出过。审批流看起来简单，但和考勤状态联动才是真正的复杂度所在，建议在设计数据库时就预留好业务ID和状态字段，不要等后期再加。

4.3 一张考勤汇总表如何呈现四种视图

同一个考勤模块，四个角色的页面需求完全不同。系统管理员看到的是规则配置入口，员工看自己的月度统计，主管看部门汇总和人员明细，HR看全公司数据并导出。所以我没有做四个独立页面，而是做一个考勤汇总组件，根据角色标识切换展示粒度。

员工模式不分页，只查本人；主管模式列表带部门筛选；HR模式带全量筛选和导出按钮。数据来源是同一个后端接口，后端根据角色返回不同字段集，前端再按角色渲染不同的列和按钮。这样改起来快，也不容易漏权限。实际效果是主管进来默认看到的是本部门考勤汇总卡片和异常记录列表，员工进来就是个人月度统计，HR进来才有批量导出和部门聚合图。一组件多视图的开发方式比复制四个页面省一半工作量。

5. 开发中踩过的坑与排查手记

5.1 后端时间普遍差8小时

Django默认USE_TZ=True，数据库里存的是UTC时间。有一次测试打卡记录，明明下午六点打卡，前端显示凌晨两点。排查后发现后端取出来是UTC时间，直接序列化给了前端。

解决办法是settings里设置TIME_ZONE='Asia/Shanghai'，接口返回时间统一用格式化字符串或者时间戳，前端用dayjs格式化。从此所有日期字段哪怕只是存个年月日，也尽量用DateTimeField而不是DateField，因为后面报表统计经常需要跨时区计算。这类问题在开发环境不一定会暴露，因为本机时区往往就是东八区，上了服务器就现原形，建议所有日期字段从第一版就统一规范。

5.2 打卡定位漂移与防作弊

最开始用的是浏览器navigator.geolocation获取经纬度，判断距离公司半径200米内可打卡。测试阶段就发现定位会飘到两公里外，还偶尔出现拿不到经纬度的情况。解决思路是设了模糊半径500米，同时把打卡记录里存下当时的IP地址和设备信息，后台能看到打卡来源。

更稳妥的做法是接入企业微信或钉钉的定位打卡能力，或者用办公WiFi的SSID绑定代替GPS，减少用户被误判的投诉。另外有人在手机浏览器里改位置信息，所以后端要再做一次IP归属地和打卡半径的双重校验，防君子更要防小人。我在考勤异常列表里专门加了一个"定位来源"列，显示GPS、WiFi、IP归属地三选一，HR看到异常记录时能快速判断是设备问题还是真实迟到。

5.3 前端路由刷新404与打包路径问题

项目部署到Nginx后，用户按F5刷新薪资页面直接404。这个问题很典型，原因是Vue Router用了history模式，Nginx配置里没有fallback到index.html。解决是在location /块里加try_files $uri $uri/ /index.html，让所有路由都回到前端入口。

还有一个和它同类的坑是Element Plus的图标按需引入后，生产环境字体文件路径不对，需要在vite.config里配置base为相对路径或者CDN路径。这两个坑看着小，但不上线看不到，我每次带新人都要强调一遍。如果你遇到刷新404，先检查Nginx的try_files，再检查路由mode是不是hash模式，不要一上来就改代码。

5.4 上传组件和日期校验的细节

补卡模块里员工要上传证明截图，我用el-upload组件，结果on-success事件一直不触发。后来查文档发现，on-success只有在上传返回2xx时才触发，而后端统一返回200但body里业务码是失败，它依然算成功，所以要在回调里判断业务码。如果自定义上传请求，则要用http-request完全接管，不能再用默认的action方式。

日期校验方面，补卡申请通常只允许一周内补卡，请假天数要排除周六周日，这些规则都要写进表单validator里。具体到Vue3实现，rules里可以这样写验证函数：

const rules = { leaveDateRange: [{ validator: (rule, value, callback) => { if (!value || value.length !== 2) { callback(new Error('请选择请假日期范围')) return } const start = dayjs(value[0]) const end = dayjs(value[1]) if (end.isBefore(start)) { callback(new Error('结束日期不能早于开始日期')) return } // 排除周六周日 let weekendDays = 0 for (let d = start; d.isBefore(end) || d.isSame(end, 'day'); d = d.add(1, 'day')) { if (d.day() === 0 || d.day() === 6) weekendDays++ } if (weekendDays > 0) { callback(new Error(`请假天数包含了${weekendDays}天周末，请调整日期范围`)) return } callback() }, trigger: 'change' }] }

这个自定义校验看起来简单，但周六周日排除逻辑、跨月计算、同一天请假边界，每个分支都要拿真实日历测一遍才能放上线。还有个不起眼但容易踩的坑：很多人用element-plus的日期选择器时忘了配置value-format，提交出去的是Date对象而不是字符串，后端接收时就爱出格式错误。

5.5 登录态过期与权限失效的处理

Token过期是后台管理系统最常遇到的问题。我的处理是axios响应拦截器里判断401，调用refreshToken接口换取新Token，刷新成功则重放原请求，刷新失败则清空登录态跳转登录页。需要注意并发请求时会同时触发多个刷新请求，所以要用一个isRefreshing变量加请求队列做并发锁，避免Token被刷新多次导致后端校验异常。

还有一个权限失效的隐蔽场景：管理员的角色被修改后，旧Token里还带着旧角色信息。解决方法是退出重新登录，或者后端在Token里只放用户ID，角色权限每次从数据库读取，这样管理端改权限后立即生效。我把这个逻辑写在了项目的公共模块里，后续所有页面都从Pinia里的userStore读权限码，不在组件里自己存，数据源唯一，权限就不会出现各页面不一致的情况。

这套系统从设计到落地前后花了一个多月，后来企业又提了自动排班、对接企业微信打卡、月度工资条PDF推送这些需求，技术上都不难，难的是第一步把考勤口径和绩效系数和HR对齐。我自己的体会是，做这类管理系统，业务规则永远比技术重要，先把四类角色坐在一起把"迟到怎么算""绩效怎么评""工资怎么发"谈清楚，再回去写代码，效率至少高一倍。如果后面有机会，我打算把考核指标库和薪酬配置做成可视化后台，让HR自己改公式，不用每次动代码，也欢迎大家交流各自的踩坑经验。