企业官网建设流程全解析

这两年我给不少中小企业做过内部管理系统，从零散的需求对接到真正落地跑起来，踩过的坑比写过的代码还多。这套“python基于flask基于微信小程序的企业员工绩效薪资管理系统”，就是其中一个比较完整的项目案例。它解决的是很多公司实际存在的痛点：绩效考核停留在Excel表格，薪资核算靠人工反复核对，员工查工资条还要找HR单独要，整个流程既不透明也容易出错。所以这套系统核心就做了两件事：把绩效打分和薪资核算搬到线上，同时让员工在小程序端就能查看自己的考核结果和工资明细。

这篇文章我会把这套系统的完整设计思路、数据库结构、后端接口实现、小程序端开发要点、部署上线流程以及实际运行中遇到的坑，一次讲清楚。适合正在做类似毕业设计、想学Flask+小程序前后端联调、或者公司内部确实需要一套轻量级人事薪资管理工具的同学参考。

1. 项目整体设计与技术选型思考

1.1 为什么后端选 Flask 而不是 Django

这个系统后端是纯API服务，前端页面全部由微信小程序承担，所以后端不需要渲染模板，也不需要内置Admin后台这类重量级功能。选Flask最直接的原因就是它轻，一个轻量级服务端框架，上手快，部署简单，几行代码就能跑起一个接口服务。相比Django自带ORM、Admin、Migration全家桶，Flask只保留核心路由和请求处理，其余能力按需扩展，对小型企业管理系统来说已经足够。

当然，选Flask也不是没有代价。Flask本身没有强制性的项目结构，路由、model、配置都需要自己组织清楚。如果代码写成一坨，后期扩展会很痛苦。我在项目里用Blueprint（蓝图）把路由按模块拆分，比如auth、employee、performance、salary、approval几个蓝图，每个模块路由各自维护，App入口只负责注册。这样项目结构清晰，后续加接口也不容易互相干扰。

提示：Flask 2.x之后推荐使用app.factory模式创建应用实例，配合.env管理环境变量，开发环境和生产环境切换起来非常方便。

1.2 小程序端为什么不做成 H5 或 App

员工绩效薪资系统使用频率不算高，但要求随时随地能用，比如主管在出差路上审批员工绩效，员工月底查看工资条。这种场景下，App需要安装、更新成本高，H5体验又相对粗糙。微信小程序恰好卡在中间：无需安装、打开即用、还能通过微信的订阅消息推送通知。所以前端选小程序是产品层面的合理选择。

小程序端我直接用原生框架开发，没有用uni-app。原因有两个：一是这个系统的前端逻辑不算复杂，原生小程序足够覆盖；二是原生在调试时问题定位更直接，不会出现uni-app跨端编译后行为不一致的情况。如果你后续想把代码复用到支付宝小程序或者App端，可以考虑uni-app重构，但就这个项目而言，原生是性价比更高的选择。

1.3 系统核心功能模块总览

整套系统按角色划分，核心模块大致如下：

每个模块之间数据是联动的。员工只有被管理员录入系统并且绑定微信openid之后才能登录小程序；绩效评分结束后才会参与薪资计算；薪资计算完成后才能生成工资条。这个链路必须保证状态清晰，否则一个环节的数据不对，后面全跟着错。

2. 数据库设计与核心表结构解析

2.1 员工与账户体系设计

员工表是整套系统的地基。正常来说，员工信息字段包括工号、姓名、手机号、部门ID、职位、职级、入职日期、状态（在职/离职）等。需要特别注意的一点是：员工表不应该和微信用户表耦合在一起，而是把openid作为员工表里的一个可空字段。

为什么这么做？因为不是每个员工都会主动登录小程序，有些年纪偏大的生产线员工可能压根不用微信登录，但他们的绩效和薪资数据依然要录入系统。所以员工信息必须在系统内独立存在，openid只是“绑定微信账号”的附加字段，员工绑定后就能在小程序端登录查看自己的数据，没绑定的员工由HR代录。

账户体系上，我用了双重方案。员工端：小程序内通过微信登录获取openid，映射到员工ID，系统直接识别身份。管理端：单独的账号表，管理员通过用户名密码登录，不依赖微信授权。这样做的好处是管理端不受微信接口波动影响，哪怕微信登录逻辑出现问题，HR依然能够正常操作系统。

2.2 绩效与薪资核心表

绩效表设计上，我拆了两层：绩效模板表（performance_template）和绩效评分表（performance_score）。

模板表定义考核周期、考核指标、指标权重，比如“工作完成度，权重40%”“团队协作，权重30%”“工作态度，权重30%”这样的结构。评分表则记录每个员工在一个考核周期内，每个指标的自评分和主管评分，最后汇总折算出一个绩效总分。换算关系需要明确：绩效总分 = Σ(指标得分 × 指标权重)，这个分数后续会映射到绩效等级和绩效系数。

薪资这块，我建议别把薪资设计成一张简单的“工资表”，而是设计成两张表：薪资配置表（salary_config）和薪资流水表（salary_slip）。

薪资配置表保存员工当前月薪结构，比如底薪、岗位工资、绩效工资基数、餐补、交通补贴、住房补贴、五险一金基数等，这些字段是“变动”的。薪资流水表保存每个月实际计算出的工资明细，包括应发合计、各项扣款、实发金额、发放月份、计算状态。关键点在于：工资流水是历史快照，它不能直接关联员工的当前薪资配置，否则员工调薪之后，历史月份的工资条数据就会被破坏。所以，薪资流水表要把当时的底薪、绩效工资、扣款等字段全部冗余存储，这样才能保证历史工资单随时可查且结果不变。

2.3 审批流与消息通知表

审批流不能只用单个状态字段搞定。我在审批表设计里加入了一张独立的审批记录表（approval_log），每一条审批操作记录审批人、审批角色、审批动作（同意/驳回）、审批意见、操作时间。主表则维护当前审批状态，比如待主管审核、主管已通过、HR确认中、已生效、已驳回。

这样设计的价值在于审批可追溯。员工绩效被驳回时，能看到是谁在哪个节点驳回了、驳回理由是什么，而不是只看到一个“已驳回”的干巴巴状态。对企业管理来说，这个过程数据很多时候比最终结果更重要。

消息通知方面，除了系统内的站内信表，我还接了微信小程序订阅消息。比如绩效评分生效后、工资条发布后，通过模板消息推送给员工。这里要特别提醒：小程序订阅消息是一次性订阅，用户每次授权只能推送一条，不能长期订阅。所以逻辑上要在必要节点主动引导用户授权，比如员工提交绩效后弹出授权窗口，授权后天推送“评分完成”的通知，这样既合规又不会让用户反感。

3. 后端核心功能实现与实操要点

3.1 登录鉴权与用户状态管理

小程序端的登录流程是：前端调用wx.login()拿到临时code，传给后端，后端拿着code调用微信的jscode2session接口换取openid。拿到openid不是直接放行，而是先去员工表查这个openid是否已绑定员工，绑定了就写入员工信息并返回token，没绑定则返回一个特殊错误码，提示用户联系管理员绑定。

Token方案上我没有用JWT，而是用简单的token + Redis缓存。生成一个随机字符串作为token存进Redis，设7天有效期，value是员工ID和角色信息。每次请求时前端带Authorization: Bearer <token>，后端校验通过后从Redis取用户身份。为什么不用JWT？因为这种系统需要能及时封禁某个账号的权限，JWT的无状态特性在“主动吊销token”这件事上比较麻烦，而Redis方案一条DEL就搞定了。

注意：如果部署环境没有Redis，也可以把token存数据库表里，性能差点但功能没问题。小规模公司员工几百人，数据库查token也没什么压力。

3.2 薪资计算规则的落地

薪资计算是这套系统最核心、最不能出错的模块。我把工资计算拆成几个函数步骤，方便单元测试和财务核对。

每月发薪规则如下：

应发工资 = 底薪 + 岗位工资 + 绩效工资基数 × 绩效系数 + 各类补贴 - 事假扣款 - 五险一金 - 个税

绩效系数由绩效总分映射而来，我用的规则是：

举个例子：员工小王，底薪5000元，岗位工资2000元，绩效工资基数3000元，本月绩效总分92分（对应系数1.2），餐补与交通补贴合计500元，五险一金个人部分1500元，个税80元。

那么应发工资 = 5000 + 2000 + 3000×1.2 + 500 - 1500 - 80 = 9510元。这里的“3000×1.2”就是绩效工资基数乘以绩效系数。如果绩效只有C级（系数0.8），绩效工资就变成2400元，差距还是很明显的。这个计算逻辑我用Python内置的decimal.Decimal来做，绝不直接使用float。

3.3 绩效填报与审批接口

绩效填报接口设计成状态机流转，核心状态有：草稿、待主管审核、待HR确认、已生效、已驳回。状态机的好处是能够强制约束操作顺序，防止员工在主管还没审核时就手动改成绩效分数。

后端接口方面，主要这几个：

• POST /api/performance/draft保存绩效草稿
• POST /api/performance/submit提交绩效，状态变为待主管审核
• POST /api/performance/review主管审核通过或驳回
• POST /api/performance/confirmHR确认，状态变为已生效

每个接口内部都做状态校验，比如submit接口只允许草稿状态调用，review接口只允许待主管审核状态调用，违反状态流转就返回40001错误码。有次我在现场测试时就发现，提交后又调用草稿保存接口会把状态重置掉，后面加了状态判断条件才解决。这类问题，靠接口文档提醒前端是不够的，后端一定要兜底。

4. 小程序端开发与联调过程

4.1 小程序页面结构与路由设计

小程序端按角色和使用频率，我把tabBar设置成四个主页面：首页、绩效、薪资、我的。

• 首页：展示当前考核周期状态、最新工资发布通知、待办审批提醒（主管可见）
• 绩效：绩效填报页面，员工选择当前考核周期，填写各项指标自评分并提交；主管登录后这里还会出现“待审核列表”
• 薪资：查最近6个月的工资条，点开看明细
• 我的：个人信息、绑定状态、意见反馈

页面跳转方面，工资条明细、审批详情这些子页面用普通路由跳转即可。要注意小程序页面栈限制是10层，不要做超过10层的跳转嵌套，否则会静默失败。我习惯用wx.navigateTo跳详情页，返回时用wx.navigateBack，尽量避免wx.redirectTo清理页面栈。

4.2 关键组件与交互实现

原生小程序开发里，有几个坑值得说说。

第一个是表单控件的值绑定。绩效填报页里绩效指标是动态生成的，所以不能用setData逐个更新，而是在onLoad时把指标列表拉下来，在JS里维护一个scoreMap，用户每改一个输入框，通过>from decimal import Decimal base_salary = Decimal("5000.00") performance_base = Decimal("3000.00") coefficient = Decimal("1.2") salary_after_perf = base_salary + performance_base * coefficient

强调两点：第一，Decimal构造时传字符串而不是float，也就是Decimal("3000.00")而不是Decimal(3000.00)；第二，最终存数据库前，统一格式化保留两位小数，并且数据库金额字段用DECIMAL(10,2)类型，绝不用FLOAT或DOUBLE。这一条写进了项目规范，后面再没出过金额对不上的问题。

6.3 性能优化与数据量增长

五百人规模的公司，每月产生几百条薪资流水，几千条绩效评分记录，对数据库压力不大。但有几个查询会随着时间增长越来越慢：查员工薪资历史列表、跑薪资核算时关联多张表、以及主管查询下属绩效记录。

我做了三件事优化：

第一，给查询字段加索引。employee_id + salary_month做联合索引，employee_id + period做联合索引，这几个查询秒回。

第二，列表接口加时间范围筛选，默认只查最近12个月，避免一次性查出所有历史数据。

第三，薪资历史列表接口用分页，前端滚动到底部自动加载下一页。分页参数我习惯用page和page_size，后端返回total字段告诉前端一共多少条，由前端计算是否还有下一页。这个模式简单好维护，小程序端配合onReachBottom事件，体验很顺滑。

这套系统从需求梳理到正式上线，前后大概用了五个星期。我个人的感受是，技术上没有特别高深的东西，Flask负责数据和业务逻辑，小程序负责展示和交互，两者通过JSON格式的API通信，关键是把业务规则理清楚、把状态流转控制住、把金额计算做严谨。绩效薪资系统最怕的就是数据不一致，所以我在写代码过程中一直要求自己：每一个状态变化都有记录，每一笔工资都有迹可循。

如果你正在做类似的系统，我的建议是先别急着写代码，把业务流程图画清楚：员工什么时候填报、主管什么时候审核、HR什么时候算薪、员工什么时候看工资条。流程理清了，数据库表和接口设计都是水到渠成的事。至于技术上遇到的坑，都是能解决的，真正的复杂度永远在业务逻辑里。