试用期设置包：从数据模型到审批流的HR系统落地指南

简介：一套面向软件开发者的Qt试用期授权管理示例资源包，涵盖试用天数、使用次数限制及永久授权切换的实现思路，适合产品经理与C++/Qt开发者学习参考。包体共38个文件，含25个dll运行库、9个qm语言翻译文件、3个exe演示程序及1个xml配置文件，整体大小18.8MB。其中exe程序可直接运行观察试用逻辑，xml记录授权参数，dll则提供完整的Qt运行环境支撑。资源重点展示了利用注册表、XML配置和Base64编码来存储试用信息，并提示了这类方式可能被篡改的风险以及结合AES等更强加密的必要性。通过对照演示程序与配置文件，读者可以快速理解试用期、使用次数和永久授权之间的管理差异，并借鉴其在Qt框架下的落地写法。已有1502人学习下载，适合需要为产品加入试用限制或完善授权机制的开发人员研究。

1. 试用期设置包到底装的什么：一场由转正日期算错引发的重构

“试用期设置.rar”这个标题在我接手某公司HR系统时，第一反应是某个离职同事留下的配置备份。解压之后才发现，它是一整套关于试用期管理的可落地配置方案，涵盖数据表结构、计算逻辑、审批流和消息通知。当时我们正被一个问题折磨：同样入职三个月，有人第89天收到转正提醒，有人第92天才收到，转正日期完全对不上。这套设置包的价值在于，它把试用期从“HR手工记日期”变成了“系统自动算、自动提醒、自动流转状态”，从业者拿来就能对到自己系统里改，省掉从头设计的功夫。适合谁：企业内部系统实施人员、HR模块的开发维护者，以及正在搭建人事流程的团队。

2. 把试用期拆成可配置的数据模型：基础表与状态机设计

试用期设置的核心问题不是“存一个日期”，而是“如何让不同角色在同一套数据上达成一致”。我见过太多翻车案例，原因都是各模块各存各的：入职登记表里有一列试用期工资，合同模块里有一个试用期截止日，审批流里又写死了90天。等到转正当天，三处数据对不上，谁也说不清哪个是准的。这套设置包的做法是，单独建一张试用期记录表，让所有模块都引用同一份数据，状态流转也统一在这一张表上完成。

2.1 试用期记录表：字段设计与状态流转的两种建模方式

建表时首先要解决的是“试用期记录”和“员工主档”的关系。常见做法有两种：一种是在员工主表上直接加试用期字段，简单粗暴，但历史记录会被覆盖；另一种是独立的试用期记录表，一员工可有多条记录，保留每次试用与转正的历史轨迹。做长期维护，我一般选后者，因为试用期延期、提前转正、二次约定这些场景，都会产生多条记录。

表的核心字段大致是：员工ID、入职日期、约定试用天数、试用期截止日、实际转正日期、当前状态、操作人、操作时间。状态字段是整个设计的枢纽，我用“0待生效、1进行中、2已转正、3已延期、4未通过、5已离职”六种状态，避免用中文裸字符串当状态值，否则后续改字面量时到处要改SQL。

CREATE TABLE probation_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, employee_id BIGINT NOT NULL COMMENT '员工ID，关联员工主档', hire_date DATE NOT NULL COMMENT '入职日期', agreed_days INT NOT NULL COMMENT '约定试用天数', due_date DATE NOT NULL COMMENT '试用期截止日（含最后一天）', actual_confirm_date DATE NULL COMMENT '实际转正日期', status TINYINT NOT NULL DEFAULT 1 COMMENT '0待生效/1进行中/2已转正/3已延期/4未通过/5已离职', extension_days INT NOT NULL DEFAULT 0 COMMENT '累计延期天数', approver_id BIGINT NULL COMMENT '最终审批人ID', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_employee (employee_id), KEY idx_due_date (due_date, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='试用期记录表';

这块表的几个设计用意：due_date 直接存“含最后一天”的截止日而不是“满月日”，是因为一线HR习惯按“哪天到期”理解，避免每个人用不同的口径推日期。extension_days 单独存累计延期天数，是为了审批时一眼看出这个人已经延过几次，防止超期。idx_due_date 这个联合索引是为后面定时任务扫“即将到期”的记录准备的，不然每天全表扫一遍，数据量大了会很吃力。

状态流转怎么做？我建议做成显式的状态机，而不是在代码里散落 if 判断。状态机的节点就五条：进行中→转正，进行中→延期，延期→转正，延期→未通过，进行中→离职。每个流转动作都记录到一张状态变更日志表，字段就是记录ID、原状态、新状态、操作人、时间、备注。原因很简单：转正纠纷发生时，你得能回答“为什么这个人从进行中变成了延期”，没有日志就全是口径之争，成了黑匣子。

2.2 关联员工主档与合同模块：用视图统一三处数据口径

数据模型建好后，还要解决“多处引用同一份数据”的问题。最省事的方案是做一张宽表视图，把员工主档、合同信息、试用期记录拉平，后续查询、报表、导出都用这张视图。

CREATE OR REPLACE VIEW v_employee_probation AS SELECT e.employee_id, e.name, e.dept_id, e.position, p.id AS probation_id, p.hire_date, p.agreed_days, p.due_date, p.status AS probation_status, CASE p.status WHEN 1 THEN DATEDIFF(p.due_date, CURDATE()) WHEN 2 THEN 0 ELSE NULL END AS remain_days, c.contract_end_date FROM employee_master e LEFT JOIN probation_record p ON e.employee_id = p.employee_id LEFT JOIN contract_info c ON e.employee_id = c.employee_id;

视图的价值在于，把“试用期还剩多少天”这个高频计算放在数据库层做，所有查询方拿到的口径一致。remain_days 用 DATEDIFF 实时算，比每天凌晨跑批更新字段更可靠——批处理一旦失败，显示的剩余天数就错了，用实时计算反而少一个故障点。注意这里 DATEDIFF 是按自然日算的，不排除节假日，后面避坑章我会专门讲这个差异。

2.3 查不到记录时的兜底：老员工的试用期数据回填

系统上线时最大的坑，是存量员工根本没有试用期记录。如果不处理，所有老员工在视图里都查不到试用期数据，定时提醒一跑，把全公司的人都当成“无试用期”，该提醒的没提醒。常见做法是写一个一次性回填脚本，按入职日期和约定天数补生成记录，状态直接置为“已转正”。

INSERT INTO probation_record (employee_id, hire_date, agreed_days, due_date, status) SELECT e.employee_id, e.hire_date, 90 AS agreed_days, DATE_ADD(e.hire_date, INTERVAL 90 DAY) AS due_date, 2 AS status FROM employee_master e WHERE e.hire_date < CURDATE() AND e.employee_id NOT IN (SELECT DISTINCT employee_id FROM probation_record);

回填时 agreed_days 按 90 写死是偷懒做法，实际应该从合同模块取，合同里没有的再走默认值。而且老员工的 due_date 如果已经过去，状态必须置 2，否则定时任务会把这批历史人当成“试用期进行中”，第一天跑批就把全公司提醒一遍，非常尴尬。这个脚本上线前建议先 SELECT 预览一遍数量，确认影响范围再执行。

3. 落地核心计算逻辑：试用期天数怎么算才对

数据表建好之后，真正的博弈在“天数计算”上。试用期 3 个月到底是多少天？有人按 90 天算，有人按“下月同日减一天”算，有人按工作日算。这套设置包里的核心思路是：把计算规则配置化，而不是写死在代码里，这样每家公司的口径都能通过配置切换。

3.1 三种日期口径的取舍：自然日、工作日、节假日顺延

业内对试用期截止日有几种常见算法，我把它们优缺点列出来：

我一般建议中小团队用自然日，不是因为它精确，而是因为节假日顺延的规则在转正场景里容易引发争议。举例：截止日是周六，按“顺延到周一”算，那试用期实际多了一天；但按“到期即到期”算，周六当天系统就该转正。两种逻辑都有道理，但没有统一标准时，定时任务的结果就会被人质疑。设置包的做法是支持配置一个顺延开关：顺延到下一个工作日，或不顺延，由业务方拍板，开发只做配置，不背这个锅。

3.2 写一个每天扫描到期记录的定时任务：从SQL到调度配置

计算口径定好后，需要一个每天固定时间扫描的定时任务，把“即将到期”“已到期未处理”“已超期”三条队列拉出来。这个任务的 SQL 核心逻辑就是查视图里 remain_days 在某个范围内的记录。

def scan_probation_queue(): today = date.today() # 即将到期：剩余 7 天内，且状态为进行中 soon = session.query(VEmployeeProbation).filter( VEmployeeProbation.probation_status == 1, VEmployeeProbation.remain_days >= 0, VEmployeeProbation.remain_days <= 7 ).all() # 已到期未处理：剩余天数 < 0，且状态仍为进行中 overdue = session.query(VEmployeeProbation).filter( VEmployeeProbation.probation_status == 1, VEmployeeProbation.remain_days < 0 ).all() # 分别走通知与升级逻辑 notify_upcoming(soon) notify_overdue(overdue)

这段逻辑看起来简单，真正要调的是两处：一是 remain_days 的边界值到底用 0 还是 1，因为视图里 DATEDIFF 返回的是“今天距截止日还差几天”，截止日当天返回 0，这个边界不确认清楚，到期当天的提醒会晚一天或早一天；二是 overdue 队列的处理，不要发完提醒就完事，应该在 overdue 里再按超期天数分级，超期 1 天和超期 30 天必须走不同的通知对象和处理流程。调度频率建议每天上午 9 点和下午 3 点各一次，只跑一次容易漏掉当天新入职的人的记录。

3.3 转正当天的状态切换：事务边界与幂等控制

到期自动转正，是所有设置里最危险的一段逻辑。危险在哪？如果定时任务在转正当天跑了两次，或者手动点了两次“确认转正”，会不会产生重复记录、重复发通知？所以状态切换必须做成幂等的——无论调用多少次，结果都一样。

def confirm_probation(record_id, operator_id): with db.transaction(): record = get_probation_record(record_id) # 状态校验：只有进行中才允许转正 if record.status != 1: raise BizException('当前状态不允许转正') old_status = record.status record.status = 2 record.actual_confirm_date = date.today() record.approver_id = operator_id db.add(record) log_status_change(record_id, old_status, 2, operator_id, '自动转正') db.commit()

这里用数据库事务保证“改状态”和“写日志”要么同时成功要么同时失败。幂等的关键是第一行校验：状态为 1 才允许转正，当任务重复执行第二次时，状态已经是 2，直接抛异常，不会再产生第二次日志。另一个值得注意的点是操作人字段这里传入的是定时任务的服务账号，而不是某个具体员工，后期审计时才能区分“系统自动转正”和“人工手动转正”，这两类操作在合规检查里的性质完全不同。如果你用的是 MySQL，注意默认隔离级别下先 SELECT 再 UPDATE 有并发问题，建议对记录行加 FOR UPDATE 锁，或者退一步用 UPDATE ... WHERE status=1 这种条件更新来保证原子性。

4. 审批流与消息通知：试用期设置包的关键联动配置

试用期不是“到期自动转正”就结束了。实际业务里，试用期结束前要经过用人部门评价、HR 复核、负责人审批，审批不过的还要走延期或解除。这一章在整个设置包里承上启下，处理的是“系统算出的日期，怎么变成人的决策流程”。

4.1 审批节点怎么设计：三个角色的五级审批链

审批流设计上，我见过的常见方案是三级：直属上级评价 → 部门负责人复核 → HR 备案。如果部门负责人和直属上级是同一个人，节点自动跳过。这套设置包里把审批链做成了可配置的 JSON，这样流程调整时不需要发版，只要改数据库配置。

{ "probation_approval_flow": { "trigger_time": "due_date_minus_7_days", "nodes": [ { "node_id": "direct_manager", "node_name": "直属上级评价", "approver_type": "by_relation", "relation": "direct_manager", "allow_skip": true, "timeout_action": "remind_daily" }, { "node_id": "dept_head", "node_name": "部门负责人复核", "approver_type": "by_relation", "relation": "dept_head", "allow_skip": true, "timeout_action": "escalate_to_hr" }, { "node_id": "hr_confirm", "node_name": "HR复核确认", "approver_type": "by_role", "role_code": "hr_specialist", "allow_skip": false, "timeout_action": "escalate_to_hr_manager" } ] } }

上面 JSON 里的两个关键设计：allow_skip 表示同一人兼任两个角色时自动跳过节点，避免一个人审批两次；timeout_action 定义了超时行为，直属上级超过 24 小时未处理就每天提醒，超过 48 小时升级到 HR，这种“提醒升级”机制是保证流程不卡死的命门。trigger_time 用了 due_date_minus_7_days，意思是到期前 7 天启动流程，给审批留出足够缓冲，而不是到期当天才发起。

4.2 消息通知模板：占位符与三通道推送的注意点

通知模板的坑在于，不同角色的消息必须不一样。给直属上级发的，要带员工信息和评价链接；给 HR 发的，要带审批超时状态。用占位符拼模板是最灵活的做法。

通知直属上级： 员工 {employee_name} 的试用期将于 {due_date} 到期，请于 {deadline} 前完成试用期评价。 评价结果将作为转正/延期的依据。 通知HR： 员工 {employee_name} 试用期审批已超过 {overdue_hours} 小时未处理。 当前节点：{current_node}，请及时跟进。

占位符的设计要克制，不要搞二三十个变量。实际常用的就六个：员工姓名、部门、入职日期、试用期截止日、剩余天数、审批链接。链接里的 token 参数要带签名，防止员工互相猜链接看到别人的审批详情。推送通道上，这套配置包里一般做三个：站内信、邮件、企业微信/钉钉机器人，但不要三个都发同样的内容，站内信发完整内容，邮件发摘要加链接，IM 只发提醒，否则会被当成垃圾消息。这里有血泪教训：全量推送时模板里某个字段为空，比如部门为空，所有通知都会变成“员工 的试用期将于...”，生产中这种低级错误很伤信任。

4.3 审批结果回写：延期与提前转正的状态变更

审批流跑完后，结果要回写到试用期记录表。这里容易遗漏的场景是“提前转正”：员工表现优秀，入职 45 天就审批通过了，这时 due_date 还是 90 天后的日期，必须把实际转正日期、新状态同步更新，同时把原审批流程终止掉。

这张表的价值在于提醒你，每个结果都不是单点更新，而是连带一串动作。延期尤其要注意：due_date 改完后，原定时任务的待办队列要刷新，否则系统会再按旧日期发一遍到期提醒。之前某次上线就翻车在这个地方，延期后旧提醒照发，员工收到矛盾信息，HR 的工单被打爆。回写逻辑建议放在审批流回调里统一处理，不要散在多个接口里各改各的。

5. 试用期设置包绕不开的五个坑：定时任务边界、转正纠纷与数据一致性

每一套试用期设置方案上线后，真正让人头疼的都不是主体流程，而是边界场景。这些坑不踩一遍，你永远不会觉得自己漏了什么。我把最常见、最典型的五条放在这里，每一条都是从实际故障里捞出来的。

5.1 现象一：截止日当天不提醒，第二天才提醒

某次上线后，HR 反馈“今天到期的人没收到提醒，隔天才收到”。查日志发现，定时任务每天 9 点跑，当天到期记录（remain_days=0）确实被查出来了，但通知模块里过滤条件是 remain_days > 0，等于把当天到期的记录全排除了。

原因：通知模块沿用了旧逻辑，认为“0 表示还没到期”，没有跟视图里的口径对齐。解决：统一过滤条件的边界值，即 remain_days >= 0 AND remain_days <= 7 为即将到期，把 0 归属到“当天到期仍需提醒”的区间，并针对 remain_days = 0 单独加日志标签，便于查询历史。

5.2 现象二：节假日顺延后，到期日永远差一天

业务方提出“试用期到期日如果在节假日，顺延到下一个工作日”。开发在 due_date 上直接加了一天，结果国庆假期顺延完，实际天数超过约定天数，员工发起劳动仲裁时公司处于不利地位。

原因：顺延逻辑加错了位置。顺延应该是“通知和处理日期顺延”，而不是“试用期截止日顺延”——试用期约定多少天就是多少天，截止日不变，变的只是发起审批的日期。解决：把顺延加到定时任务触发条件里，遇到节假日让任务次日再处理，不修改 due_date 字段。这条直接决定了合规性，改动前务必跟法务确认口径。

5.3 现象三：审批流卡死，超时升级不生效

审批流配置里的 timeout_action 写了，但实际超时后没有任何升级动作。排查发现，定时器扫描“超时未处理”用的是审批流的创建时间，而审批流被驳回修改过，创建时间是旧的，导致超时计算错误。

原因：没有区分审批流的创建时间与最后更新时间。解决：在审批流表里增加 updated_at 字段，超时判定用 updated_at 而不是 created_at；同时驳回重提时重置 updated_at，保证超时计时从最新一次提交开始算。

5.4 现象四：离职员工还在收转正提醒

员工月底离职，但离职流程没有同步状态到试用期记录表，离职当天定时任务照样给这位员工和他的上级发送转正提醒，造成尴尬。

原因：离职流程和试用期模块是两个独立系统，离职归档时没触发试用期记录的联动。解决：在离职归档接口里加一个事件，把该员工的 probation_record.status 置为 5，并注释取消所有待办提醒。如果系统不支持事件机制，就在定时任务的查询 SQL 里 JOIN 员工主档的离职日期字段，用离职日期做过滤。建议两种都做，前者保证实时性，后者兜底防漏。

5.5 现象五：手动修改 due_date 后，提醒逻辑全部错乱

HR 手动把某员工的试用期从 90 天改成 60 天，但系统里仍有一堆定时任务按旧值在跑：转正日期提醒按新日期发了，但工资模块还在按 90 天算试用期工资，两套数据打架。

原因：试用期记录表的 due_date 被修改后，没有广播出去给工资、考勤、合同模块。解决：对 due_date 的更新做一个统一入口，比如一个 update_due_date 函数，内部事务里更新记录表、写变更日志、推消息队列给下游模块。实践中我甚至建议直接禁止手动改库，只允许通过审批流或变更接口修改，改库这条口子一开，数据一致性就很难保障了。

6. 进阶玩法：用一套验收脚本给试用期配置做回归测试

配置上线后怎么验证？靠人工点一遍太慢，靠线上观察又太被动态，我习惯在测试环境写一套验收脚本，每次改动后自动跑一遍，确认该过的场景全过。

def test_probation_flow(): # 场景1：入职当天创建试用期记录，状态为进行中 emp = create_employee(hire_date='2025-06-01', agreed_days=90) rec = get_probation_record(emp.id) assert rec.status == 1 assert rec.due_date == date(2025, 8, 29) # 6月1日 + 90天 # 场景2：到期前7天，系统发起审批流 mock_today('2025-08-22') tasks = get_pending_approval_tasks(emp.id) assert len(tasks) == 1 # 场景3：审批通过，状态自动转正 approve_task(tasks[0].id, operator='tester') rec = get_probation_record(emp.id) assert rec.status == 2 assert rec.actual_confirm_date == date(2025, 8, 29) # 场景4：审批延期，到期日顺延30天 approve_extension(tasks[0].id, extra_days=30) rec = get_probation_record(emp.id) assert rec.status == 3 assert rec.due_date == date(2025, 9, 28)

这套验收脚本的精髓在于 mock_today——把系统时间固定到某个日期，才能稳定验证“提前7天触发”“到期当天转正”这些依赖日期的逻辑。不 mock 的话，每次跑脚本的日期都不同，断言根本写不进去。另一个关键点是场景之间要隔离，每个测试用例都创建新的员工数据，不要复用，避免上一轮的审批状态污染下一轮。

我再补充一个容易忽略的验证维度：并发测试。模拟两个任务同时对同一条记录发起转正操作，确认只有一个成功，另一个拿到“状态不允许转正”的异常。这个测试不需要复杂的工具，用多线程脚本同时调接口就行。并发问题在试用期模块里很常见，因为定时任务和人工操作可能在同一秒触达同一条数据，不测一下总觉得心里不踏实。整个设置包我建议每季度做一次回归，配合新版上线一起跑，这套脚本是我唯一不删的配置。希望帮到你。

本文还有配套的精品资源，点击获取