简介这份资源围绕软件试用期限制与授权管理展开面向从事桌面软件开发的程序员、产品经理及需要设计收费策略的Qt开发者帮助解决试用天数与使用次数控制、授权信息防篡改等实际问题。压缩包共38个文件、约18.8MB以25个dll动态库、9个qm多语言翻译文件、3个exe可执行程序和1个xml配置文件为主dll与exe构成可运行的Qt演示程序qm提供多语言界面支持usage.xml则用于记录和读取试用状态构成一套完整的可编译参考实例。已有1506人浏览学习。资源将试用期机制落到具体代码层面读者可据此了解如何借助XML配置文件而非注册表保存剩余天数与使用次数并通过Base64等编码手段对配置内容做基础保护同时结合Qt框架的跨平台特性扩展授权模型便于在自己的项目中快速搭建可验证的试用授权雏形。1. 试用期设置不是加个 if先看清这个 rar 里到底有什么包发出去第三天用户甩来一张截图把系统时间往前调两天试用期重新开始计时了。这类返工在桌面小工具里太常见试用期设置这件事难点从来不是写个 if 判断到期而是把「用户能想到的所有绕过手法」提前堵上。这个叫「试用期设置.rar」的资源包做的就是把这堆容易出问题的事收进一个 Qt 模块首启时间写入磁盘、使用次数原子计数、功能权限按位下发、机器码绑定、授权文件验签试用到期或次数用尽后统一走一套状态机全程不依赖在线服务。适合做单机工具、内网部署客户端、要发试用版给客户试的付费软件。如果你正被「用户改时间绕过限制」或者「试用版和正式版两套代码分支」折腾它的价值在于边界情况已经替你踩过一遍。2. 时间基准试用期天数怎么算才不被系统时间牵着走试用期设置最容易踩的坑是把「到期」定义得太随意。同一个 30 天在不同实现里可能是 30 个自然日、30×24 小时、30 个有效使用日三种口径对用户的心理预期完全不同也决定了你能不能用单调时间兜底。先把口径定死再谈怎么存。2.1 三种口径的取舍自然日、运行时长、有效使用日自然日算法最简单首启当天记一个日期之后每次QDate::currentDate()减一下超过 30 就到期。副作用是用户装完放着不用也会过期对「先装后试」的用户不友好但商业上最常见的也是它。运行时长算法累计程序真正跑过的秒数装完放一个月也依然有 30 天额度用户体验好代价是你必须有一个不受墙钟影响的时间源否则用户挂机就能刷时长。有效使用日介于两者之间一天内启动过就算消耗一天同一台机器反复启动不重复扣。实现上要维护一个「最后一次计费日期」跨天时自增多实例并发时又要回到原子写的问题。我一般的做法是双轨以自然日为主口径判定到期同时累计运行时长做交叉校验。两个值出现明显矛盾比如自然日只过了 2 天累计运行时长却记了 20 天基本可以判定墙钟被动过这时候走人工复核分支而不是直接封死避免误伤。口径落盘字段抗改时间能力用户接受度适用场景自然日first_run 时间戳弱需交叉校验中商业试用、限时活动累计运行时长acc_uptime 秒强高工具类、按用量计费有效使用日last_bill_date中高SaaS 客户端本地缓存2.2 三个时间源交叉首启时间、最后可见时间、累计运行时长只存一个「首启时间」是不够的因为它是只写一次的常量用户只要找到它改掉就重置了。真正有用的组合是三个字段first_run首次运行写入之后只读用于算自然日。last_seen每次退出或心跳时更新用于判断「本次墙钟比上次记录还早」。acc_uptime累计运行秒数用单调时钟增量累加用于兜底。判定逻辑分三步。第一步看now last_seen - 容差墙钟倒退直接标记异常。第二步看now first_run - 容差连起点都被改到未来同样异常。第三步用now - last_seen的差值累加到acc_uptime但单次增量要设上限我给 86400 秒防止用户把时间往前调一个月然后跑一次一次性刷进 30 天。容差给多少合适我习惯给 120 秒。笔记本电池耗尽、虚拟机快照恢复、NTP 校时、跨时区出差都会造成几秒到几十秒的墙钟回退容差太小会误杀正常用户太大又给绕过留下窗口。提示跨时区场景不要用本地时间做判断全部换成 UTC 秒。用户从东八区飞到西五区本地时间倒退 13 小时用本地时间算就是一次「时间回拨」。2.3 代码实现写入磁盘时机和一次完整的判定QSettings是最省事的存储但它的sync()必须显式调用很多人写完setValue就以为数据已经保存到磁盘程序一崩数据全丢用户重启后试用期重置。下面这段是工程里的核心判定可以直接照着改。// trialclock.cpp #include trialclock.h #include QSettings #include QDateTime #include QStandardPaths // 容差小于这个值的墙钟回退视为校时/时区导致不算篡改 static constexpr qint64 kSkewTolerance 120; // 单次最多承认一天的墙钟增量防止一次性把时间往前调一个月 static constexpr qint64 kMaxStep 86400; TrialClock::State TrialClock::check() { // IniFormat UserScope落到用户配置目录Windows 下是注册表以外的独立文件 QSettings s(QSettings::IniFormat, QSettings::UserScope, m_key, trial); const qint64 now QDateTime::currentSecsSinceEpoch(); // 全程 UTC 秒 const qint64 first s.value(first_run, 0).toLongLong(); const qint64 last s.value(last_seen, 0).toLongLong(); const qint64 uptime s.value(acc_uptime, 0).toLongLong(); if (first 0) { // 首次运行三个字段一次性落地 s.setValue(first_run, now); s.setValue(last_seen, now); s.setValue(acc_uptime, 0); s.sync(); // 关键不 sync 就是没写 return State::FirstRun; } // 1) 墙钟倒退检测比上次记录早或比首启时间还早 if (now kSkewTolerance last || now kSkewTolerance first) { s.setValue(tamper_flag, true); s.sync(); return State::RollbackDetected; } // 2) 累加增量单次封顶负数钳到 0 const qint64 delta qBoundqint64(0, now - last, kMaxStep); m_elapsed uptime delta; s.setValue(last_seen, now); s.setValue(acc_uptime, m_elapsed); s.sync(); // 3) 双轨判定自然日超期 或 累计运行时长超期任一命中即到期 const qint64 daysByWall (now - first) / 86400; if (daysByWall m_trialDays || m_elapsed m_trialDays * 86400LL) return State::Expired; return State::Normal; }代码里有三个参数值得单独说。kSkewTolerance决定误杀率我给 120 秒如果你的用户里有大量虚拟机用户可以放宽到 300 秒。kMaxStep决定单次刷时长的上限一天是折中值设太大等于把漏洞留着设太小则长时间关机再开机的用户会少算时长。m_key是产品标识QSettings用它拼路径换产品必须换 key否则两个产品会互相覆盖试用数据。还有一个细节State::RollbackDetected不要直接弹「检测到作弊」然后退出。真实环境里误判不少正确做法是降级——限制高级功能提示用户联网校验或者联系支持同时把first_run、last_seen、now三个值写进日志方便后面排查。3. 次数与权限把「能做几次」和「能做什么」拆成两个模型试用期和试用次数经常被混成一个东西结果代码里到处是if (daysLeft 0 used 50)越写越乱。这两件事的判定周期完全不同到期是按时间判次数是按动作扣权限是按功能点查。拆成「计数 权限位」两个独立模型后面加功能才不至于改一处崩三处。3.1 次数计数为什么必须原子写最直觉的写法是「读文件 → int 1 → 写回文件」本地单实例跑起来没问题一遇到多开就翻车。两个实例同时启动都读到 19都写回 20实际用了两次却只扣了一次。更隐蔽的问题是掉电写到一半断电文件变成空或者半截数字toInt()返回 0用户的次数直接清零这种问题在工控机上一个月能遇到好几次。解决分两层。写层面用QSaveFile它内部是写临时文件再renamerename在同一文件系统上是原子的要么是新内容要么是旧内容不会出现半截文件。读改写层面用QLockFile做进程间互斥锁的粒度覆盖整个「读-判-写」区间。// counter.cpp #include QFile #include QSaveFile #include QLockFile #include QDir // limit 0 表示不限次数正式授权 bool bumpCounter(const QString dir, const QString name, int limit, int *used) { QDir().mkpath(dir); QLockFile lock(QDir(dir).filePath(name .lock)); lock.setStaleLockTime(5000); // 5 秒没释放视为僵尸锁 if (!lock.tryLock(3000)) // 等 3 秒拿不到就当并发冲突 return false; const QString path QDir(dir).filePath(name .cnt); // 1) 读当前值文件不存在按 0 处理 int n 0; QFile in(path); if (in.open(QIODevice::ReadOnly)) { n in.readAll().trimmed().toInt(); // 内容损坏时 toInt 返回 0 in.close(); } // 2) 先判上限再自增顺序不能反 if (limit 0 n limit) { if (used) *used n; return false; } // 3) QSaveFile写临时文件 rename掉电不会写出半截文件 QSaveFile out(path); out.setDirectWriteFallback(true); // 网络盘不支持 rename 时降级 if (!out.open(QIODevice::WriteOnly)) return false; out.write(QByteArray::number(n 1)); if (!out.commit()) return false; if (used) *used n 1; return true; }setStaleLockTime(5000)是血泪经验程序被任务管理器强杀时锁文件留在磁盘上不设过期时间的话用户从此再也打不开。tryLock(3000)的超时也要给否则第二个实例会卡死在这里。setDirectWriteFallback(true)是为网络盘和某些国产文件系统准备的它们不支持原子 rename宁可牺牲一点原子性也要能写进去。计数文件放哪也有讲究。放程序安装目录普通用户没写权限QStandardPaths::AppDataLocation是更稳妥的默认位置要防止用户删配置目录重置次数就得再往注册表或者某个业务数据文件里写一份副本启动时比对两个值取大的那个。这是典型的「防君子不防小人」但对绝大多数用户够用。3.2 权限位设计一份 Policy 覆盖试用版和正式版权限别用一堆 bool 堆着加功能就要改结构体、改序列化、改所有读取点。用位掩码一个quint32能装 32 个功能点序列化成一个整数存授权文件、存注册表、走网络协议都方便。// policy.h #include QString enum class Feature : quint32 { None 0, ExportPdf 1u 0, BatchRun 1u 1, PluginLoad 1u 2, ApiAccess 1u 3, CustomTheme 1u 4, }; struct Policy { int trialDays 30; int maxRuns 20; // 0 表示不限 quint32 mask 0; // 当前生效的权限位 bool has(Feature f) const { return (mask static_castquint32(f)) ! 0; } void grant(Feature f) { mask | static_castquint32(f); } void revoke(Feature f){ mask ~static_castquint32(f); } // 试用版策略只给非核心功能次数受限 static Policy trial() { Policy p; p.trialDays 30; p.maxRuns 20; p.grant(Feature::ExportPdf); p.grant(Feature::CustomTheme); return p; } // 正式版策略全开、不限次 static Policy pro() { Policy p; p.maxRuns 0; p.mask 0xFFFFFFFFu; return p; } };用位掩码有个隐性好处授权文件里只存一个整数mask以后新增功能点只要占一个还没用过的位老授权文件依然能读不会因为结构体字段变多而解析失败。这一点在给客户做了几十份授权之后再改需求时能省下大量售后。调用侧统一成一个入口别在每个功能点里各写各的判断// 业务代码里唯一的权限判断入口 if (!g_policy.has(Feature::BatchRun)) { ui-batchBtn-setEnabled(false); ui-batchBtn-setToolTip(QStringLiteral(当前授权不含批量处理)); return; }注意 UI 禁用只是体验层真正的拦截必须在执行函数的第一行再做一次。用户能改配置文件把mask改大所以授权文件必须验签第 4 章而 UI 层的灰化只是减少无效点击。3.3 机器码生成与绑定的边界机器码的作用是把授权锁到一台设备上。常见做法是取几个硬件标识拼起来做哈希取前 16 位十六进制。Qt 里有现成的QSysInfo::machineUniqueId()Windows 下取的是 MachineGuidLinux 下读/etc/machine-idmacOS 走 IOPlatformUUID跨平台基本够用。#include QCryptographicHash #include QSysInfo #include QNetworkInterface QString machineCode() { // 盐值必须换掉且只存在于客户端用于让不同产品的机器码不可互推 const QByteArray salt QByteArrayLiteral(replace-me-with-your-own-salt); QByteArray uid QSysInfo::machineUniqueId(); if (uid.isEmpty()) { // 兜底部分精简 Linux 没有 machine-id退到第一块物理网卡 MAC for (const QNetworkInterface ni : QNetworkInterface::allInterfaces()) { if (ni.flags().testFlag(QNetworkInterface::IsLoopBack)) continue; if (ni.hardwareAddress().isEmpty()) continue; uid ni.hardwareAddress().toUtf8(); break; } } if (uid.isEmpty()) uid QSysInfo::prettyProductName().toUtf8(); // 最后的兜底不推荐 QCryptographicHash h(QCryptographicHash::Sha256); h.addData(salt); h.addData(uid); return QString::fromLatin1(h.result().toHex().left(16)).toUpper(); }这段代码的边界要清楚。换主板、重装系统MachineGuid 会变、克隆虚拟机都会导致机器码变化用户的授权直接失效。所以正式产品里必须留一个「授权迁移」通道比如允许每年免费重置两次或者后台人工换绑别把用户堵死在一台机器上这是售后成本的大头。另一个坑是虚拟机快照。用户在快照 A 激活回滚到快照 B 再激活等于一份授权跑了两台环境。要堵这个就得在授权里记录激活时间戳并做单调校验或者干脆限制同一机器码的激活次数。4. 授权文件与激活签名校验落到 Qt 工程的四个接口试用期设置走到正式授权这一步核心诉求就一个客户端不能自己造授权。任何把密钥、算法、判定逻辑全放在客户端的方案本质都是提高门槛而不是绝对防住。所以设计目标是「让改造成本高于购买成本」而不是追求理论上的不可破解。4.1 授权文件结构载荷与签名分离授权文件用 JSON 做载荷签名单独一个字段两者一起序列化。字段顺序必须固定因为签名算的是规范化之后的字节串字段顺序一变签名就废。字段类型参与签名说明productstring是产品标识防止 A 产品授权用在 B 产品machinestring是机器码空串表示不绑定设备expirestring是到期日格式 yyyy-MM-dd空串表示永久maskuint32是权限位maxRunsint是次数上限0 表示不限issuedAtint64是签发时间戳用于防重放sigstring否Base64 编码的签名值{ product: demo-tool, machine: 9F3A1C7B2D5E8046, expire: 2026-12-31, mask: 31, maxRuns: 0, issuedAt: 1767225600, sig: 5m8Xk...Base64 }issuedAt这个字段很多人会省掉省掉之后就没法做吊销——用户把系统时间调到签发之前或者拿一份旧授权覆盖新授权你都无从判断。有了它客户端只要记住「本机见过的最大 issuedAt」比它小的授权文件一律拒绝回滚攻击就失效了。4.2 验签实现为什么必须用常数时间比较轻量场景用 HMAC-SHA256 就够Qt 自带QMessageAuthenticationCode不用引第三方库。但要注意两点一是规范化函数必须和签发端逐字节一致二是比较签名时用compare()而不是。#include QMessageAuthenticationCode #include QCryptographicHash #include QJsonObject #include QJsonDocument // 规范化字段顺序、分隔符、日期格式全部写死签发端必须用同一份实现 static QByteArray canonical(const QJsonObject o) { return QStringLiteral(%1|%2|%3|%4|%5|%6) .arg(o.value(product).toString(), o.value(machine).toString(), o.value(expire).toString(), QString::number(o.value(mask).toInt()), QString::number(o.value(maxRuns).toInt()), QString::number(static_castqint64(o.value(issuedAt).toDouble()))) .toUtf8(); } bool verifyLicense(const QByteArray fileBytes, const QByteArray key, QJsonObject *out) { QJsonParseError err{}; const QJsonDocument doc QJsonDocument::fromJson(fileBytes, err); if (err.error ! QJsonParseError::NoError || !doc.isObject()) return false; const QJsonObject o doc.object(); const QByteArray sig QByteArray::fromBase64(o.value(sig).toString().toUtf8()); const QByteArray want QMessageAuthenticationCode::hash( canonical(o), key, QCryptographicHash::Sha256); // compare 是常数时间比较避免按字节短路带来的时序侧信道 if (!QMessageAuthenticationCode::compare(sig, want)) return false; if (out) *out o; return true; }canonical()是整套方案里最容易出问题的地方。服务端用 Python 拼的字符串客户端用 Qt 拼中间多一个空格、日期格式从2026-12-31变成2026-12-31T00:00:00签名就永远对不上。我的做法是把规范化函数单独抽成一个文件服务端和客户端各自实现一份然后用同一组固定测试向量交叉验证两边输出必须逐字节相同。compare()和的区别在于前者不会在第一个不同字节处提前返回时间开销恒定。本地单机场景这个风险不高但既然是现成 API没有理由不用。4.3 激活流程的四个接口与状态机工程里把授权相关的逻辑收在一个LicenseManager里对外只暴露四个接口业务代码不碰文件路径和 JSONclass LicenseManager { public: // 1) 启动时调用决定本次运行跑试用还是正式 Policy boot(); // 内部调 verify trialClock.check // 2) 用户输入激活码/导入授权文件 bool activate(const QString codeOrPath, QString *errMsg); // 3) 每次消耗性动作前调用扣次数 bool consumeRun(int *left); // 4) 导出诊断信息给售后用 QString diagnostics() const; };boot()里的判定顺序不能乱先验签授权文件通过就以授权文件为准不通过再看试用状态试用状态里如果带篡改标记降级到受限模式。反过来先判试用就会出现「用户已购买但试用期过了仍被拦」的投诉。状态机一共五个状态Unlicensed、Trial、TrialExpired、Licensed、Tampered。前四个是正常流转Tampered是异常兜底它不锁死程序只关掉高价值功能并提示联系支持原因是误判太常见了。4.4 离线激活码怎么防重放没有服务端的场景激活码只能离线算。常见做法是让用户把机器码念给你你用工具生成一串「机器码 到期 权限」的签名用户粘回去。这里要防的是同一串激活码被贴到第二台机器上所以在签名载荷里必须包含机器码客户端验签后再比对本地机器码不一致直接拒绝。更省事的做法是让激活码自带校验位把机器码前 8 位、到期日、一个随机盐拼起来做 HMAC取前 12 位当校验段。这样即使激活码被转发第二台机器算出来的校验段也对不上。代价是激活码会比较长一般 40 字符以上用户手输容易错所以工程里同时提供「粘贴导入」和「文件导入」两条路。5. 避坑与排查五条踩过的记录下面五条都是真实翻车现场按「现象 → 原因 → 解决」整理遇到同类问题时可以对照着查。5.1 用户改系统时间试用期直接重置现象用户把时间往前调两天程序启动后试用天数回到第 1 天。 原因只存了first_run一个字段程序每次启动都用now - first_run算天数时间往前调差值变小。 解决加last_seen做单调校验now last_seen - 120判定为回拨同时累计acc_uptime用单调累加值做第二道判定。两个值取「更严格」的那个作为最终状态改时间只能让它更早到期不能延后。5.2 优化软件清一次垃圾试用次数自动重置现象用户装了清理工具清完缓存后本来剩 3 次的试用次数变回 20 次。 原因计数文件放在AppDataLocation被清理工具当成缓存目录整个删掉读不到文件就按 0 处理。 解决多处副本交叉。主副本放AppDataLocation备份副本写进注册表或者业务数据文件的一个隐藏字段启动时读两处取较大值并记录「本次是否检测到副本丢失」。副本丢失本身就是一个信号可以降级到受限模式。另外把计数文件改成带校验位的格式次数|HMAC删了文件重建也会因为校验不过而暴露。5.3 多开程序次数少扣了一次现象用户双击两次图标开了两个窗口各跑一次批量任务次数只减了 1。 原因读改写没有互斥两个进程都读到同一个旧值。 解决QLockFile把「读-判-写」整段包住锁文件放同一目录setStaleLockTime设 5 秒防止强杀留下僵尸锁。另外用QSharedMemory做单实例也行但要注意共享内存段在某些容器环境下会被清理掉反而不如文件锁可控。5.4 授权文件明明是对的验签就是不过现象服务端生成的授权文件用户在客户端导入提示「授权无效」但用文本编辑器打开看内容完全正常。 原因三种情况最常见。一是 Windows 记事本保存时加了 UTF-8 BOMJSON 解析之后字符串前面多了三个不可见字节二是用户在聊天软件里复制粘贴末尾多了换行或空格三是服务端序列化时字段顺序变了。 解决读文件后先做一次清洗去掉 BOM、去掉首尾空白、把\r\n统一成\n。规范化函数单独抽出来服务端和客户端用同一组固定向量交叉验证。导入入口同时支持文件和粘贴粘贴路径额外做一次 Base64 解码前的空白字符清理。5.5 Debug 构建里打了密钥Release 忘了关现象逆向分析发现二进制里能直接搜到 HMAC 密钥用户据此自己签了一份永久授权。 原因开发阶段为了排查方便在验签失败分支里qDebug() key这个分支在 Release 里依然存在。 解决密钥不进客户端——离线方案里客户端只放公钥用非对称签名RSA 或 Ed25519校验私钥只在签发工具里。如果规模小只能用 HMAC那就在.pro里加DEFINES QT_NO_DEBUG_OUTPUT并且把所有含密钥的日志用#ifdef QT_DEBUG包起来。上线前用strings或十六进制编辑器搜一遍可执行文件确认搜不到密钥片段这个动作我每次都做。6. 上线前一周把授权模块当黑匣子做回归授权模块的特点是「平时不出声出事就是一片投诉」。它不像普通功能那样有明确的输入输出用户报障时你拿到的是「打不开了」四个字没有现场数据就只能靠猜。所以在发版前留一周把它当黑匣子跑一遍回归比事后救火划算得多。回归清单不用复杂关键是覆盖状态迁移而不是功能点。我习惯按下面这几项走一遍每项都手动验证测试项操作手法期望结果首次启动清空配置目录后启动写入 first_run状态 Trial时间回拨系统时间往前调 1 天再启动状态 Tampered 或受限不重置时间前调系统时间往前调 30 天再启动到期acc_uptime 单次增量不超过 1 天次数耗尽连续跑满 20 次第 21 次被拦计数文件内容为 20并发计数同时启动两个实例各跑一次次数减 2锁文件正常释放授权导入导入正确授权文件状态 Licensed权限位全开授权篡改手工改 JSON 里的 mask 后导入验签失败回落试用授权回滚导入一份 issuedAt 更小的旧授权被拒提示授权已失效强杀恢复计数过程中任务管理器强杀重启后计数不丢不乱机器迁移换一块硬盘后启动机器码变化授权失效提示迁移流程清单里最容易被跳过的是「强杀恢复」和「机器迁移」。前者要么在虚拟机里手动杀进程要么在计数函数里加一个可配置的延迟开关写完文件后QThread::msleep几百毫秒方便在这个窗口期杀掉。后者至少要在一台备份机上验证一次否则用户换硬件时你才知道自己的迁移通道根本没写。再补一个实用技巧给授权模块加一个诊断串导出。用户报问题时让他点一下「复制诊断信息」把这一串贴过来你就能还原大半现场。QString LicenseManager::diagnostics() const { // 单行、可粘贴、不含敏感密钥末尾带 8 位校验防止用户手改后你误判 const QString body QStringLiteral( v1;product%1;machine%2;state%3;first%4;last%5;uptime%6;runs%7;mask%8) .arg(m_product, machineCode(), stateName(m_state)) .arg(m_firstRun).arg(m_lastSeen).arg(m_uptime) .arg(m_usedRuns).arg(m_policy.mask); const QByteArray sum QCryptographicHash::hash( body.toUtf8(), QCryptographicHash::Sha256).toHex().left(8); return body ;crc QString::fromLatin1(sum); }这段代码有两点值得注意。一是诊断串里绝对不能带密钥或完整授权文件否则等于把攻击材料送给用户二是末尾的crc是给自己看的用户改了state想让你以为他是正式版校验位就对不上一眼能看出来。诊断串长度控制在 200 字符以内方便用户在聊天窗口里一次性贴完。最后说个习惯。我以前觉得授权模块就那么几百行写完随手测两下就发了结果有一次acc_uptime的单位写成了毫秒30 天的试用期 43 分钟就到期一晚上收到十几条投诉。从那以后我每次发版前都强制走一遍上面那张表哪怕只改了一行日志代码也要把「时间回拨」和「次数耗尽」两项手动跑一次。希望帮到你。本文还有配套的精品资源点击获取
