企业官网建设流程全解析

简介：面向 Qt 开发者与软件授权相关人员的试用期设置演示包，聚焦试用天数、使用次数、永久授权等常见场景，给出基于配置文件与加密手段管理软件权限的完整落地思路。压缩包共 38 个文件、约 18.8MB，其中 25 个 dll 提供 Qt 运行环境，9 个 qm 为多语言界面翻译，3 个 exe 用于启动与测试演示，1 个 xml 记录试用状态，结构简洁、开箱即可运行。试用逻辑覆盖 30 天倒计时、启动次数阈值等典型限免策略，并展示如何通过 usage.xml 与 Base64/AES 组合防止简单篡改；对想快速搭建授权验证原型、理解 Windows 注册表与 XML 配置差异的读者有直接参考价值。包内保留可修改的配置模板，便于在此基础上做二次开发，把试用期机制迁移到真实 Qt 项目中。已有 1503 人学习下载，适合产品经理、独立开发者和 Qt 客户端开发者在设计付费策略或试用机制时作为基础模板。

1. 先闹明白“试用期设置”在解决什么问题：客户要 30 天试用，怎么给才不翻车

典型场景：某公司把模拟项目X的演示版发给客户，约定试用 30 天。一周后运维发现客户的授权文件被复制到另一台机器；又过了两周，客户改系统时间绕过了到期锁定。产品经理从别人那里拿到一个叫“试用期设置.rar”的压缩包，里面是时间戳脚本、授权签发工具和一堆配置说明，扔给你说“照着跑一遍”。这篇文章要解决的，正是这个压缩包背后的机制问题：试用期到底拿什么做时间基准、状态存在哪里、怎么让客户试完不能赖账。它适合给桌面工具或内部系统开试用通道的独立开发者、交付型小团队，也适合正在评估“要不要自己做试用期”而不是买现成授权组件的人。下面先把三个基本盘立住，再逐段给可抄的脚本和参数，最后说五个绕不过去的坑。

2. 试用期机制的三个基本盘：时间源、状态存储与身份锚点怎么选

很多打包工具自带的试用期功能，本质上都在处理同一件事：你凭什么相信“这台机器上的这个用户”已经用了多少天。答案不外乎三个基本盘——时间源、状态存储、身份锚点。三选错一个，后面全是救火现场。

2.1 时间源：为什么只读本地时钟必然翻车，回拨检测该怎么落

最常见的错误实现是程序第一次运行时在注册表里写一个时间，之后每次启动拿“现在的本地时间”减去那个时间。问题在于，客户端时间可以被改。改成两周前，减去之后剩余天数反而变多了；断网加改时间，可以把 30 天试用无限续杯。

正确做法分两层。第一层，所有记录都用 unix epoch（UTC 秒数），程序内部不跟“2025-03-01 08:00”这种带时区的字符串打交道，避免不同机器时区不同导致到期时间漂移。第二层，增加一个“最近一次合法运行时间”的水印：每次启动把当前 epoch 和上次记录的 epoch 比一次，如果发现当前时间比上次还小（允许几小时的时钟漂移误差），就判定发生了时间回拨，按回拨处理。

import time def check_time_rollback(state_store): # state_store 是封装好的状态读写对象，下面带占位实现 now = int(time.time()) last = state_store.load("last_run_ts") if last is not None and now + 3600 < last: # 留1小时误差，防止时区/NTP误差误判 return True state_store.save("last_run_ts", now) return False

逻辑说明：last_run_ts是上一次确认过“合法”的运行时间，只在通过回拨检查后才更新。回拨判定留 1 小时容差，是为了避免用户偶尔把系统时间调错几分钟都被锁死；容差太大则又给手动改时间留了空间。这里把存储封装成state_store，是因为实际项目里时间水印和首次运行时间往往放在同一个存储层里，后面 3.1 会给具体实现。

参数说明：3600这个值在桌面工具里通常取 0～24 小时。保守产品取 300 秒，只容忍 NTP 校准抖动；管理类软件可以放宽到 24 小时，但代价是用户每天最多能“合法”回拨一天，试用期实际会拉长。我一般默认 1 小时，既能容忍时区切换，又不会放大手动改时间的漏洞。

完成回拨检查只解决“时间被往回改”。另一条防线是联网时间校准：程序有机会联网时，用公开的时间接口对一次表，如果本地与服务器偏差超过阈值，下次启动进入受限模式。这个做在服务端校验里更合适，本地只做提示。注意，这里只提示“请校准系统时间”，不要把判定逻辑讲给用户听。

2.2 状态存储与身份锚点：注册表、授权文件、机器码怎么搭

试用期状态如果只存一个位置，用户删掉它就等于获得一次重置机会。常见做法是散落三份：首选写入注册表，同时在ProgramData下放一个授权状态文件，再在用户目录下放一个隐藏文件。程序启动时以两份以上一致为准，任何一份缺失都触发完整性检查，而不是自动重新计算首次运行时间。

身份锚点解决的则是“换台机器算不算新设备”的问题。常见做法是采集磁盘序列号、主板 UUID、第一块活动网卡的 MAC，拼起来算一个 SHA-256，取前 32 位作为设备指纹。注意不是所有硬件数据都稳定：USB 网卡换了就变，虚拟机的磁盘序列号可克隆，某些主板的 UUID 字段为空。所以指纹生成要用降级策略——某个字段取不到就剔除，但剔除后的指纹组合必须写在状态文件里，不然下次取到不同字段组合会算出新指纹。

表里三处组合的关键不是“哪个更安全”，而是“删掉任何一两个都凑不齐完整状态”。完整性标记可以用一个不透明的校验值，三个副本互相印证，这比单点存储稳妥得多。

2.3 三套方案横向对比：本地计时、离线激活码、在线验证的取舍

试用期机制大体有三档做法。单纯本地计时成本最低，但只能挡“手欠”的用户；离线激活码多一次签名和校验的开发量，挡的是“较真”的用户；在线验证最稳，但要求产品必须联网，很多交付型工具在客户内网里根本跑不起来。

注意：如果客户环境普遍在隔离内网，在线验证方案直接出局；如果产品是纯演示用，本地计时也够。选定方案后不要中途频繁换，试用期机制最怕的是上线后改时间基准，存量用户的状态全部作废。

我的默认推荐是“本地计时骨架 + 离线激活码”。本地计时负责日常使用，激活码负责把到期时间、功能等级、设备指纹绑死。这套组合离线可用，又能挡住授权文件被复制和到期时间被修改这两类最常见的事故。第 3 章先跑通本地计时部分，第 4 章再补离线激活码，正好是压缩包里最常见的内容结构。

3. 把压缩包里的脚本跑通：首次运行时间戳与机器码的本地落地

这类压缩包里最常出现的三样东西：首次运行时间戳脚本、机器码生成脚本、剩余天数校验工具。下面按顺序把三样都跑通，代码可以直接抄进项目里改数再用。

3.1 首次运行时间戳落地：注册表写入、文件副本与回拨检测（PowerShell）

我一般先把首次运行时间写到注册表 HKCU 下，再额外写两个文件副本。为什么要多副本：用户重装系统、清理注册表、误删 ProgramData，任何一个动作如果只影响一处，试用期都不该被重置。只有三份全丢，才认为确属新环境。

$vendor = 'DemoVendor' $product = 'DemoProduct' $regPath = "HKCU:\Software\$vendor\$product\Trial" if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force | Out-Null } $firstRun = (Get-ItemProperty -Path $regPath -Name FirstRun -ErrorAction SilentlyContinue).FirstRun if (-not $firstRun) { $firstRun = [DateTimeOffset]::Now.ToUnixTimeSeconds() Set-ItemProperty -Path $regPath -Name FirstRun -Value $firstRun } $copy1 = Join-Path $env:ProgramData "$vendor\state.dat" $copy2 = Join-Path $env:USERPROFILE ".$($product.ToLower())_state" New-Item -ItemType Directory -Force (Split-Path $copy1) | Out-Null Set-Content -Path $copy1 -Value $firstRun Set-Content -Path $copy2 -Value $firstRun

逻辑说明：脚本先检查注册表里是否已有FirstRun，没有则取当前 UTC 秒数写入，再同步到两个文件副本。三处内容一致，校验时以多数一致的结果为准。ProgramData副本放在厂商目录下，普通用户一般不会主动翻；用户目录副本用点开头隐藏文件，避免被一眼看到。

参数说明：HKCU是按当前用户维度存，换 Windows 账户会重新计试用期；如果要绑机器，应改为HKLM并给写权限。$copy2用.product_state这类隐藏名，属于防君子不防小人，它的价值是让“删一个文件重置试用期”这种操作变得需要动三处，而不是真的能做到不可删除。

接产品时，启动流程里先跑回拨检测（2.1 的检查逻辑），再读三处状态取多数，最后算剩余天数。三处一致但值不同时，以最早的时间为准——也就是给用户算更短的试用期，防止“把旧副本删了留下新副本”这种延长操作。

3.2 机器码生成：把磁盘序列号、主板 UUID 与 MAC 算成 32 位指纹

身份锚点是给授权码用的。第 4 章签发激活码时会把机器码写进授权串里，所以这里要先有一个稳定可复现的生成脚本。

$disk = (Get-CimInstance Win32_DiskDrive | Where-Object { $_.Index -eq 0 }).SerialNumber $bios = (Get-CimInstance Win32_ComputerSystemProduct).UUID $mac = (Get-NetAdapter | Where-Object { $_.Status -eq 'Up' } | Select-Object -First 1).MacAddress $parts = @() if ($disk) { $parts += $disk } if ($bios) { $parts += $bios } if ($mac) { $parts += $mac } $raw = $parts -join '|' $sha = [System.Security.Cryptography.SHA256]::Create().ComputeHash( [System.Text.Encoding]::UTF8.GetBytes($raw)) $fp = [System.BitConverter]::ToString($sha).Replace('-', '').Substring(0, 32) $fp

逻辑说明：先取三样硬件信息：第一块磁盘序列号、主板 UUID、第一块活动网卡 MAC。任一项取不到就把它剔除，剩下的拼接后用 SHA-256 计算，取前 32 位十六进制字符。注意拼接顺序必须固定，且取不到字段时不能补空字符串占位，否则不同机器可能拼出同样的原始串。

参数说明：Index -eq 0在有多块磁盘的机器上选系统盘，换系统盘会导致指纹变化，交付时要有预期；Status -eq 'Up'选当前活动的网卡，USB 网卡和禁用网卡都会导致结果不稳定。更强的指纹还可以加 CPU ID、VolumeID，但越深的硬件信息越容易在虚拟机里读到空值。我的习惯是磁盘序列号 + 主板 UUID 两个字段作主指纹，MAC 做备选，出现两次不一致才报警。

3.3 接进产品的剩余天数函数：一个最小的 Python 校验点

状态和指纹都有了，最后是产品侧三天两头要调的剩余天数函数。它只管一件事：给定首次运行时间和试用期天数，算出还剩几天，顺便把“到期后”的大致动作留给调用方。

import os, time def remaining_days(first_run_ts, trial_days=30): elapsed = time.time() - float(first_run_ts) left = trial_days - elapsed / 86400 if left < 0: left = 0 return left def read_first_run(paths): # paths: 三个状态文件路径，按时间最早者生效 values = [] for p in paths: if os.path.exists(p): try: values.append(float(open(p).read().strip())) except ValueError: pass if not values: return None return min(values)

逻辑说明：remaining_days把剩余天数压到不小于 0，调用方根据返回值分三档处理：大于 3 天正常提示、0 到 3 天给续费引导、等于 0 进入第 6 章的宽限期状态机。read_first_run读多份状态文件并取最小值，等于天然实现了 3.1 里“以最早时间为准”的规则。

参数说明：trial_days默认 30，可以做成配置项而不是硬编码；状态文件路径传入而不是在函数里拼死，是为了方便线上做不同客户给不同天数的测试。这个函数只做计算，不做写入，写入统一收敛在启动初始化处，避免产品代码到处改状态文件导致副本不一致。

4. 离线激活码的签发与校验：从生成密钥对到最小可跑实现

本地计时这套骨架到了产品正式售卖阶段就不够用了：授权文件可以被复制，到期时间可以被手工修改。离线激活码在这两个点上是真正的补强手段。

4.1 为什么离线激活码比单纯时间戳高一个等级：签名与篡改

离线激活码的核心不是“把时间加密藏起来”，而是签名。客户端内置一把公钥，签发方拿私钥对授权信息签名；用户拿到授权串后，客户端先验签、再解析、再比对。验签通过才认为授权信息确实是签发方给的，任何手动修改授权串里的到期日期都会导致验签失败。这就是为什么它能挡住“较真”的用户：你可以看见授权串里写的到期时间，但你改不动它。

私钥管理是这个方案里唯一需要当作秘密对待的东西。私钥只放在签发机器上，不放进产品代码，不出现在任何一份交付物里；公钥反之，随便内嵌在客户端里。密钥泄漏就等于整个授权体系失效。

4.2 签发端：用 Python 给试用授权串签名的最小实现

签发端跑在内部机器上，输入是产品标识、机器码、到期时间和功能等级，输出是一段授权串。这里用常见的cryptography库，RSA-2048、PKCS1v15、SHA-256，是对桌面授权场景比较稳妥的组合。

import base64, json, time from cryptography.hazmat.primitives import hashes, serialization from cryptography.hazmat.primitives.asymmetric import padding, rsa def generate_key_pair(): key = rsa.generate_private_key(public_exponent=65537, key_size=2048) return key def issue_license(private_key, product, machine_code, days=30, level="trial"): payload = { "product": product, "machine": machine_code, "expire": int(time.time()) + days * 86400, "level": level } body = base64.urlsafe_b64encode(json.dumps(payload).encode()).rstrip(b"=") sig = private_key.sign(body, padding.PKCS1v15(), hashes.SHA256()) sig_b64 = base64.urlsafe_b64encode(sig).rstrip(b"=") return body.decode() + "." + sig_b64.decode()

逻辑说明：payload是明文的，不要担心它被看到，安全不靠隐藏而是靠签名。把 json 序列化结果做 base64 得到body，用私钥对body签名，再把body和签名拼成“点分隔”的授权串。客户端拿到后，先拆出body和签名，用公钥验签，再解码body读取字段。

参数说明：days=30是试用周期，level="trial"是功能等级，后续可以扩展成pro、enterprise等，用于区分不同授权档位。expire存的是 unix epoch，不要在签发端转成日期字符串，日期字符串在不同时区的机器上会产生 8 小时级别的偏差，这正是第 5 章要讲的坑之一。

4.3 校验端：验签、机器码比对与到期判断的三个检查点

校验端跑在客户机器上。顺序是死的：先验签，再比对机器码，最后比对时间。三个检查点顺序不能换，否则可能出现“信息有效但被伪造”或“信息被篡改但先被业务逻辑拦住”的混乱。

import base64, json, time def verify_license(license_str, machine_code, public_key): body_b64, sig_b64 = license_str.split(".") body = json.loads(base64.urlsafe_b64decode(body_b64 + "==")) sig = base64.urlsafe_b64decode(sig_b64 + "==") public_key.verify(sig, body_b64.encode(), padding.PKCS1v15(), hashes.SHA256()) if body["machine"] != machine_code: raise RuntimeError("机器码不匹配") if time.time() > body["expire"]: raise RuntimeError("授权已过期") return body

逻辑说明：public_key.verify抛异常即验签失败，不需要额外判断返回值。验签通过后body里的内容才能被信任；machine_code从 3.2 的指纹脚本实时计算，不信任用户自己提供的任何标识。expire与本地当前时间比较，这里又回到了时间源：即使验签通过，用户把系统时间回调，time.time()也会变小，所以第 2 章的回拨检测必须跑在这一切之前。

公钥加载的完整代码量不大：从public_key.pem文件用serialization.load_pem_public_key读入即可。我倾向于把公钥连同产品证书一起内嵌进安装包，这样换公钥只需要更新一个配置文件，不需要重新编译客户端。

5. 试用期设置避坑指南：五个翻车现场与排查套路

这套机制里没有一个环节是“配置完就不用管”的。下面五个坑我都见过实际项目踩过，按现象、原因、解决的顺序写，方便对号入座。

5.1 时间与状态相关的坑：改时钟、删状态、跨时区

坑一：客户改系统时间，试用期永远用不完。 现象：授权状态文件显示首次运行在一个月前，但系统时间被改到一个月前，剩余天数始终有 20 多天。 原因：只读本地时钟，没有回拨检测，也没有联网校时。 解决：先把 2.1 的回拨水印跑上，再把第 4 章的授权校验放在水印之后。最好再加一个联网校时策略：程序检测到本地时间与服务器时间偏差超过 5 分钟时，进入受限模式并提示“请校准系统时间后重试”。注意这里只说“校准”，不要给出具体原因，避免给较真的用户提供绕过思路。

坑二：删注册表或重装系统，试用期自动重置。 现象：演示机重装系统后再装产品，又是完整 30 天试用。 原因：首次运行时间只写在了注册表里，注册表跟着系统一起没了；又没有跟机器码绑定，所以无法识别“这是那台已经用过的机器”。 解决：3.1 的三副本只是降低误删概率，真正防重置靠的是“机器码 + 服务端记录”。客户端每次校验通过后，把机器码、首次运行时间、最近一次运行时间上报；重装后再装，服务端认机器码，直接返回该机器原有的首次运行时间。完全离线的产品至少要做到：状态副本缺失时进入受限模式，而不是自动开新试用期。

坑三：到期时间跨时区漂移，上午还能用下午就锁了。 现象：同一份授权在 A 机器还剩 1 天，在 B 机器还剩 0.4 天；B 机器下午 3 点就进入到期提示。 原因：签发端用了本地时间字符串，不同时区机器解析出来的 epoch 不同；或者状态文件混用了2025-03-01 08:00这种带时区的格式。 解决：全链路只用 unix epoch。签发端expire用int(time.time()) + days*86400，客户端比较也用time.time()，时间显示层才转成本地日期字符串。如果历史版本已经在用字符串格式，迁移办法是在客户端里加一层解析兼容，解析失败时按过期处理，别给用户留口子。

5.2 授权与部署相关的坑：授权码复制、克隆机与过期不触发

坑四：授权码复制到另一台机器直接能用。 现象：客户把激活成功的授权串拿给隔壁同事，同事粘贴后直接进入已激活状态。 原因：payload 里没绑机器码，或者机器码字段在产品代码里写死、校验根本没读。 解决：机器码必须从 3.2 的脚本实时计算，且参与签名（4.2 的machine字段）。校验时先验签，再比对machine与实时计算值。虚拟机场景要特别说明：克隆虚拟机后网卡和磁盘序列号都会复制，机器码相同，等于授权也被复制。防御手段是加入主板 UUID 与 CPU ID 做联合指纹，但代价是克隆后的合法新虚拟机也需要重新激活，取舍要提前定。

坑五：试用到期后不锁定，或者隔天才锁。 现象：授权明明过期，客户说“还能继续用”，查看日志发现最后一次校验时间在昨天。 原因：只在主界面启动时做了一次校验，客户挂着程序过夜，跨过过期时间点后所有功能照常；或者宽限期设得过长，过期后还在正常使用。 解决：把校验点铺开——启动、打开工程、保存文件、调用核心算法时各校验一次，且校验周期不超过 5 分钟。可以做一个后台线程每分钟检查expire与当前时间，一旦跨过进入锁定流程，弹窗、禁用按钮、阻止保存三件事同时做。开发里养成一个习惯：测试时把系统时间调快 3 天，看程序在 5 分钟内有没有反应，这是最便宜的回归测试。

5.3 线上排查套路：给校验链路补三个时间点

排查试用期问题时，最快的路径不是翻代码，而是看日志里三个时间点：程序首次运行时间、最近一次校验时间、当前判定时间。三个点能对上，问题出在业务逻辑；对不上，问题出在状态存储或时间源。

先看now_ts与真实当前时间的差值，超过 5 分钟优先查回拨检测；再看last_check_ts是否随运行持续更新，如果停留在上次启动，说明校验线程挂了或者压根没跑；最后核对first_run_ts与安装日志的时间差，异常就查状态文件是不是被删过。这三个值一出来，九成问题不用猜。

6. 进阶：到期后的宽限期状态机与反绕过自查清单

到期处理做成“咔嗒一刀切”的产品体验很差。更稳的做法是把过期分成三个状态：试用期、宽限期、锁定态，给用户一个平滑的退出路径，也给销售留出沟通窗口。

6.1 宽限期状态机：试用、宽限、锁定三态怎么流转

状态流转规则如下表：

宽限期建议设 7 天，不可配置给用户看到。锁定态保留只读打开，是为了让客户还能把资料取出来，不至于因为一个到期判定把客户数据锁死。这个状态机做在客户端，逻辑层只管返回当前状态，界面层按状态渲染提示语，不要在产品代码里散落十几个“是否过期”的判断。

6.2 反绕过自查清单：六种常见手段对应哪个防御位

做完上面所有内容后，按这张清单自查一遍：改系统时间——回拨检测和联网校时是否生效；删除状态文件——三副本的一致校验是否触发；重装系统——机器码是否上报到服务端；复制授权码——payload 是否绑定机器码；克隆虚拟机——指纹是否包含主板 UUID 或 CPU ID；长期挂机跨过过期点——后台校验线程是否在跑。按清单逐项做一次手工测试，比写再多的防御代码都管用。我现在的习惯是：拿到任何一个试用期相关的包，第一个看的永远不是激活码签发脚本，而是它怎么处理时间源和状态副本。这两个点守住了，后面只是编码问题；没守住，后面全在救火。希望帮到你。

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