简介：Sqlite加密插件QtCipher是一份面向Qt开发者的SQLite加密工程资源，基于sqlitecipher库为SQLite数据库提供文件级加密能力，帮助在桌面、移动或嵌入式应用中保护敏感数据，同时维持SQLite的轻量特性。压缩包共23个文件，以cpp、pro、h等工程源码为核心，附带conf配置文件、md说明文档、license授权信息、json工程配置及pri工程包含文件，整体大小仅2.43MB，结构简洁便于移植。目前已有140人浏览学习。通过该资源，开发者可借助QtCreator编译生成插件并安装到对应Qt插件目录，快速获得加密数据库支持；工程内还提供demo演示项目、test_plugin测试工程以及CHANGELOG、README文档，有助于理解sqlitecipher的加密机制、集成步骤和密钥管理要点。对于希望在不引入重型数据库的前提下增强SQLite安全性的开发者，这份资源提供了可实践的参考实现，也适合作为评估加密插件方案时的备选资料。
1. Sqlite加密插件QtCipher：别让数据库文件变成第二个密码本
做桌面端或嵌入式工具时，很多人辛辛苦苦把业务逻辑跑通，最后发布的却是一个可以直接拖进编辑器看光的 SQLite 文件。之前有个项目把客户资料存在本地库里，交付后没两天就被对方用 DB Browser for SQLite 打开，所有字段一览无余。SQLite 数据库文件能否加密，这个问得最多的问题，答案不是“能”或“不能”那么简单：标准 SQLite 本身确实不带加密，但通过 QtCipher 这类加密插件，你可以在不换数据库引擎、不改业务 SQL 的前提下，把整个数据库文件变成密文。这篇文章就是围绕这个插件，从原理、编译、参数到排错，把一条能直接复现的落地方案讲清楚。
2. 先看懂 SQLite 为什么默认不加密：明文文件结构与插件介入的边界
2.1 一条 sqlite update 语句背后，文件里留下的是什么
标准 SQLite 的存储模型非常直白：一个数据库就是一个文件，内部按页（page）组织，默认页大小通常是 4096 字节。你执行一条 sqlite update 语句，本质上是把某个页里的旧记录标记为删除，再在合适位置写入新记录。这个过程中，SQLite 不会对内容做任何变换，也就是说，凡是你能用 SQL 写进去的字符串，都能在文件里被十六进制工具直接看到。更麻烦的是，即使你执行了 DELETE，旧数据所在的页也不会立刻被物理清空，而是被标记为“空闲页”，在后续复用之前，内容就一直留在磁盘上。这意味着删除不等于消失，明文残留时间比你想象的长很多。
有人会想，那把字段做一层 Base64 或简单异或再存进去，是不是就能挡住普通用户？这类做法属于应用层伪装，能防住双击打开文件的好奇用户，却防不住稍微懂一点 SQLite 文件布局的人。因为 SQLite 的页结构、表结构、索引 B+ 树都有固定格式，只要对方知道文件头偏移量，就能把自定义编码字段抽出来慢慢分析。真正的加密插件走的是另一条路：在 SQLite 的页缓存和磁盘 I/O 之间加一层密码学变换，整个文件落盘前先加密，读文件时再整体解密。对 SQLite 引擎本身来说，它看到的仍然是一页一页的“普通数据”，业务层不需要关心加密细节。这也就是 QtCipher 这类插件能保持 SQL 兼容的根本原因。
从这里也能看出一个结论：加密插件解决的是“文件被人拿走”这个威胁模型，它解决不了“程序运行时内存被 dump”或“密钥被直接写在源码里”的问题。后两者属于密钥管理和运行环境安全，不在数据库插件能力范围里。所以选型之前，先明确你要防的人是谁：防普通用户直接拿文件看，插件加密就够了；防分发后的逆向分析，你还得配合代码混淆和密钥保护，不能把密码硬编码成一串常量。
2.2 QtCipher 的加密模型与 SQLCipher 的差别：选型先看这个
业内聊 SQLite 加密，绕不开的老牌方案是 SQLCipher，它在 SQLite 源码之上做了一套完整的加密封装，采用 AES-256-CBC 加 HMAC 校验，每个页有独立的初始化向量（IV），并且有专门的页头标记。QtCipher 走的是另一条实现路线：它不是一个对 SQLite 源码的完整 fork，而是以 Qt 的 SQL 驱动插件形式存在，利用 Qt 自带的 QSQLite 驱动作为基础，在驱动层拦截数据库文件的读写过程。常见做法是编译一个独立的驱动插件（比如 qsqlcipher 或 qtciphersqlite 之类的插件名），然后在 QSqlDatabase 的连接选项或打开数据库时传入密码。
这个差别决定了三件事。第一，集成方式不同：SQLCipher 需要你在编译 SQLite 时替换源文件或链接它的库，Qt 程序里往往要重新编一次 QSQLITE 驱动；QtCipher 类插件通常提供一个 Qt 插件文件，放进 Qt 的 plugins/sqldrivers 目录就能用，常规应用不需要重编整个 Qt。第二，加密算法和密钥派生参数不同，SQLCipher 的 KDF 迭代次数、HMAC 算法都有公开规范，而 QtCipher 这类插件的具体参数取决于实现，升级插件版本时更要注意兼容性。第三，SQLCipher 因为被 iOS、Android 以及各种桌面端大量采用，跨端联调时的“大家认这个格式”是优势；QtCipher 的优势则是“在 Qt 工程里改造成本低”，如果你的项目本来就是 Qt Widgets / QML / Qt Quick，用同生态的插件更省事。
我一般会这样提醒刚入手的同事：别只看加密强度，先确认你的部署环境有没有权限放额外插件文件。如果目标机器是精简的嵌入式 Linux，只放了一个裁剪过的 Qt 运行时，那么 SQLCipher 这类需要重编驱动的方案可能更痛苦，而 QtCipher 这类插件化方案反而更容易塞进去。反过来，如果团队里有人用非 Qt 语言（比如 Flutter、C#）也要读同一个库文件，那就要认真评估格式互通性。SQLCipher 的加密库格式有社区跨语言支持；QtCipher 若只有 Qt 驱动实现，其它语言就很难打开，这未必是坏事，但一定要提前摆到桌面上谈。
2.3 加密不是替换 SQLite：插件层与应用层各自该做什么
一个常被误读的问题是：加了加密插件，是不是就能把 SQLite 当作一个“带密码的数据库服务器”来用？不是。无论是 SQLCipher 还是 QtCipher，它们加密的都是静态文件。一旦你的程序打开数据库并执行查询，解密后的页会进入内存，这一过程对应用完全透明，但同时也意味着“连接保持期间”的安全性取决于你的进程内存防护。插件不会替你处理并发写冲突，也不会改变 SQLite 单写多读的并发模型。也就是说，业务层面的锁竞争、WAL 模式是否开启、事务粒度怎么控制，这些仍然是你需要自己操心的事。
应用层真正该做的，是把密钥管理和连接生命周期管好。常见做法是在程序启动时从外部密钥源读入密码（比如系统钥匙串、配置服务或用户输入的口令），拼进连接字符串或作为驱动选项传给 QSQLITE，用完及时清理内存中的密码副本。不要把密码写在 QSettings 明文配置里，也不要写死在源码里——这不是插件能帮你解决的。另一个容易忽略的点是：插件只加密数据文件和 WAL 文件（如果开了 WAL），临时文件、回滚日志的加密情况要单独验证。有些插件实现只加密主文件，journal 模式下的回滚日志仍然可能暴露部分明文。所以真要对敏感数据较真，要么显式关闭 WAL 和 journal 模式，要么在代码层面确认插件对附属文件的覆盖范围，再决定是否使用。
3. 用 QtCipher 在本地工程跑通最小加密库：从下载到首次写入
3.1 编译集成 QtCipher 插件：三个关键配置项
拿到 QtCipher 这类插件源码后，第一件事不是急着写业务代码，而是把它编成与你 Qt 版本匹配的驱动插件。如果你用的是 qmake 工程，常见做法是在插件源码目录下执行 qmake 和 make，之后会在 plugins/sqldrivers 下生成一个带 sqlite 和加密标识的插件文件。用 CMake 工程的话，需要把插件目标的输出路径指到 Qt 的插件目录，或者打包时把插件文件放到可执行文件旁的 sqldrivers 子目录。这一步的坑集中在三个配置项上：
- 套件版本：必须和你的应用完全一致。用 Qt 5.15.2 编的应用，装一个 Qt 6.5 编的驱动插件，运行时必然报 “driver not loaded” 或 symbol 找不到。
- 编译器 ABI：MSVC 和 MinGW 的插件不能混用，编译器和运行库不一致，加载时会直接拒绝。Linux 下则要留意 glibc 版本，尤其是跨发行版部署。
- SQLite 编译参数：有的插件实现允许你在编译时决定是否启用 WAL、是否启用扩展，这些会影响后续你能否在连接里执行 ATTACH、JSON 函数等 SQL。
下面是一个典型的 qmake 命令行构建过程，在实际执行前请把路径替换成你自己的 Qt 安装目录：
cd /path/to/QtCipher # 插件源码目录 export QTDIR=/opt/Qt/5.15.2/gcc_64 export PATH=$QTDIR/bin:$PATH qmake CONFIG+=release make -j4 # 构建产物一般在 plugins/sqldrivers 下 ls -l plugins/sqldrivers/这里做两件事：第一，通过环境变量让 qmake 找到对应的 Qt 工具链；第二，指定 release 模式，避免调试版运行时依赖额外的 debug 运行库。构建后你会在 sqldrivers 目录下看到类似libqsqlcipher.so或qsqlcipher.dll的文件，文件名后缀可能因实现不同而略有区别。确认插件文件出现后，把它复制到你应用的sqldrivers目录。如果这一步就报错，先回看 qmake 输出的 Qt 版本路径，百分之八十的情况是环境变量指向了错误的 Qt。
3.2 用代码创建并打开加密数据库
插件编好之后，写一个最小示例验证全链路。这里的关键是让 Qt 的 QSqlDatabase 使用你新加的驱动名，而不是默认的 “QSQLITE”。具体驱动名以插件实现为准，常见的是QSQLCIPHER或QCIPHER，下面以QSQLCIPHER作示范，实际使用时请替换成你编译出来的驱动标识。密码通常通过setConnectOptions传入，不同实现的选项写法不同，我一般会先在源码 README 或驱动默认代码里确认选项关键字，再填密码：
#include <QSqlDatabase> #include <QSqlQuery> #include <QSqlError> #include <QVariant> #include <QDebug> bool createEncryptedDb(const QString &filePath, const QString &password) { // 使用加密驱动的连接，名称随意，保证唯一即可 QSqlDatabase db = QSqlDatabase::addDatabase("QSQLCIPHER", "cipher_conn"); db.setDatabaseName(filePath); // 传入密码：具体选项名以插件实现为准 db.setConnectOptions(QString("QSQLCIPHER_PASSWORD=%1").arg(password)); if (!db.open()) { qCritical() << "open failed:" << db.lastError().text(); return false; } QSqlQuery query(db); query.exec("CREATE TABLE IF NOT EXISTS user_info (" "id INTEGER PRIMARY KEY AUTOINCREMENT," "name TEXT NOT NULL," "token TEXT NOT NULL)"); query.prepare("INSERT INTO user_info(name, token) VALUES(?, ?)"); query.addBindValue("demo_user"); query.addBindValue("s3cr3t-token-value"); if (!query.exec()) { qCritical() << "insert failed:" << query.lastError().text(); db.close(); return false; } db.close(); return true; }这段代码做了三件事：创建带密码的数据库连接，建一张表，写入一条包含敏感字段的记录。addDatabase的第二个参数是自定义连接名，避免和全局默认连接冲突；setConnectOptions负责把密码注入驱动；后续QSqlQuery的用法与标准 SQLite 完全一致。如果你在db.open()阶段就报driver not loaded，说明插件没被找到，先检查可执行文件旁边的sqldrivers目录，再检查插件文件名是否带 Qt 版本号后缀（比如qsqlcipher.dll与qsqlcipherd.dll，debug 与 release 不能混用）。
打开成功后，用一个十六进制工具或文本编辑器查看生成的.db文件。不要直接拉文件头部看，先看前 100 个字节是否有可读的 SQLite 明文头。如果插件生效，文件头会变成随机字节，字符串SQLite format 3消失，插入的s3cr3t-token-value也不会以明文形式出现。如果文件头还能看到明文头，说明你的密码选项没被驱动接受，或者驱动根本没参与文件写入，这一条是判断插件是否真正工作的黄金标准。
3.3 验证加密文件：用 DB Browser for SQLite 打开看看会报什么
文件生成完之后，建议马上做一次反向验证。用 DB Browser for SQLite 打开这个加密库，什么都不输入直接点击“打开数据库”，它通常会弹出一个错误说文件不是 SQLite 数据库，或者文件头损坏。这个报错是预期效果——它恰好说明普通工具已经无法直接读取你的文件。接下来再在 DB Browser 里输入你设置的密码重新打开，看是否能正常浏览表结构和数据。如果输入密码也打不开，但你的程序能打开，优先检查两件事：第一，DB Browser 对加密格式的支持是否与你插件一致；第二，密码选项在代码里是否真的原样传给了驱动，而不是被转义或截断了。
这一步的价值在于确认“加密不是只对自家程序生效”。如果只有你的程序能打开，其它工具一律无法打开，那你要想清楚后续数据导出、应急恢复的路径。很多团队上线加密库后，遇到运营要拉数据报表，才发现所有内部工具都连不上了。常见的应对方案是在项目里保留一个独立的明文导出工具，用同一个插件库打开加密库后执行ATTACH或逐表查询，再写进一个新的明文库。这个工具本身要放到内网或受控环境，不要随客户端分发，否则等于把门锁和钥匙放一起。我一般会在工程里单独建一个db_export_tool子模块，编译产物不进发布包，只在开发机和运维机上使用。
4. 常用接口与参数调整：密钥、页面大小、兼容性边界
4.1 密钥长度与迭代轮数：安全性和启动耗时的平衡
加密插件的安全性不只取决于算法名称，更取决于你喂给它的密钥策略。QtCipher 这类插件通常支持用户直接传一串密码进去，驱动内部会用密钥派生函数把密码扩展成加密密钥。这里有个关键点：同样的密码，配置的迭代轮数不同，最终膨胀出的密钥和初始化向量就不同。很多人在开发环境用一个固定密码，编译进程序，上线后觉得“反正文件是密文了”，但真正的风险往往出在密码强度太弱。
如果密码是123456这种级别，插件做得再好也没意义。遍历字典依然是破解这类加密库最快的方式。常见做法是让最终用户的输入口令经过至少一万次以上的 PBKDF2 或同类派生，如果插件允许配置迭代次数，尽量选 10000 到 200000 之间的值。代价是打开数据库时会有几百毫秒到一两秒的延迟，这个延迟只在连接建立时发生，后续查询不受影响。如果你发现每次sqlite update都很慢，基本可以排除迭代次数的影响，问题更可能出在每次执行都重新建立连接上——那等于把派生开销重复付了 N 遍。
还有一点容易被忽略：密钥不要直接以 QString 的明文形式长期保存在内存里。Qt 的 QString 在 debug 模式下的隐式共享、拷贝赋值都会留下多份副本。我一般会在打开数据库后立刻对保存密码的局部变量做清零，或者用QByteArray承载密码并在用完调用fill(0)。这不是玄学，是内存取证里很实际的对抗手段。插件本身不背这个锅，但应用层不做清理，等于把密钥平白多放了几份在进程地址空间。
4.2 加密库与标准 SQLite 工具的兼容性：sqlite 文件用什么打开才不踩坑
很多人买了加密插件后问的第一个问题是：原来那些明文的.db文件，用什么工具还能打开？答案是：加密后的库，标准 SQLite 工具链（包括 sqlite3 命令行、DB Browser for SQLite 的普通模式、各种 C# 和 Android Studio 里用的 SQLite 驱动）默认都打不开，因为它们按明文页格式解析文件头，第一步就失败了。这不是坏了，而是插件改变了文件层的编码，标准工具没有解密能力。
因此，团队里要提前约定一套“加密库协作规范”。比如：开发环境统一用一个内部工具打开加密库；需要导出数据时，用公司内部维护的导出命令，而不是让运营自己找破解工具。还要注意一点：SQLite 的ATTACH语法和sqlite update语句在加密驱动下通常都支持，但如果ATTACH了另一个加密库，副库是否继承主库的密码，不同插件实现差别很大。我遇到过一个案例，代码里 ATTACH 了一个同密码的库，切换插件版本后副库报错，排查半天才发现新版插件要求ATTACH ... KEY ...显式传入密码。这类差异没法提前预判，只能在升级插件后把带 ATTACH 的用例全部回归一遍。
兼容性的另一个边界是文件后缀。加密库文件要不要改成.dbc或任何自定义后缀，都不影响文件内容，但会影响用户双击时的打开方式。如果产品需要用户自己管理数据文件，推荐在上层 UI 里做文件选择过滤，同时在错误提示里明确写“这个文件可能是加密数据库，请使用软件内置的导入功能”。不要把后缀当作安全手段，它只是防误操作，不防分析。
4.3 升级 Qt 与数据库迁移：保留原始数据的三步操作
Qt 版本升级、插件版本升级，最怕的不是编译失败，而是升级后旧加密库打不开。加密格式的版本绑定关系往往比预期严格：密钥派生参数、页加密算法、文件头标记，任何一个变了，旧库就无法被新版本驱动读取。所以迁移前必须做三件事：备份原库文件、确认新旧版本都能用旧密码打开、准备好明文转储再加密的链路。
第一步，用旧版本驱动打开原库，逐表执行SELECT *并导出为 SQL 文件或临时明文库。第二步，用新版本插件创建一个新库，把导出的数据逐表写回。第三步，对比两张表的记录数和关键字段的哈希校验值，确认一致后再删除旧文件。这套流程看起来笨重，但确实是最可靠的迁移方式。如果你的数据量很大，几十个 G 的库逐行迁移会非常慢，那就要评估是否真的需要立即升级。我一般会把升级窗口放在业务低峰期，并且在迁移脚本里加入PRAGMA journal_mode=OFF等临时性优化，迁完再改回来。
另外，迁移脚本本身也必须考虑安全性。如果你先生成中间明文 SQL 文件再导入新库，这个 SQL 文件就是瞬时的明文泄露点。稳妥做法是在同一个进程里完成：打开旧库读数据、写新库、中途不落盘明文。若实在需要两个程序协作，至少保证明文文件所在目录权限是 700，并在退出前用shred或 Qt 的QFile::remove删除。很多人只在意最终库文件有没有加密，把中间产物晾在/tmp下，这属于典型的“锁了门忘了关窗”。
5. QtCipher 常见问题避坑与排查：现象、原因、解决
5.1 打开加密库时报“file is not a database”
这是最常见的报错，没有之一。现象很统一：代码里db.open()返回 false，lastError().text()里出现 “file is not a database”。第一次遇到的人第一反应往往是“加密库坏了”，但实际原因通常是以下四种之一：
第一，驱动名写错，导致 Qt 退回普通 QSQLITE 驱动打开加密文件。你在addDatabase里填的驱动标识必须与编译出的插件一致，比如插件叫QSQLCIPHER，你写成QSQLITE，Qt 会加载标准明文驱动，读密文文件头自然失败。第二，密码选项没被驱动解析。很多插件的选项名区分大小写，QSQLCIPHER_PASSWORD写成qsqlcipher_password就可能被忽略，驱动把它当没有密码，按默认密钥尝试，失败。第三，文件本身不是由当前插件写的，换了插件版本，密钥派生参数变了。第四，文件路径指向了一个空文件或非 SQLite 文件。
排查顺序建议：先打印QSqlDatabase::drivers()，确认插件驱动在列表里；再检查插件文件是否在sqldrivers目录；接着打印db.connectOptions()确认密码字符串没有被 Qt 的字符串处理截断；最后用十六进制看文件头前 16 字节，如果还有SQLite format 3，说明文件根本没被加密，问题出在写入环节。
5.2 程序升级后打不开旧库：密钥参数不一致
这个坑极具迷惑性，因为不是编译期报错，而是运行期打开失败。现象是：旧版本程序写出的加密库一切正常，换新版本程序后，同样的密码、同样的文件路径，打开却报file is not a database或file is encrypted or is not a database。直接怀疑密码被改通常是方向错了，密码没变，变的是密钥派生参数。比如旧插件用 SHA1 做派生，新插件换成 SHA256，或者迭代次数从 1000 调到 10000，旧库的密钥就完全对不上了。
解决思路是不要把新旧版本做成无缝兼容，而是走数据迁移。项目里长期维护一个“兼容旧格式导出工具”很有必要。具体做法：在发布新版之前，保留旧版插件副本，用一个独立小工具完成旧库导出，再用新版导入。如果你已经升级了又发现打不开旧库，也别慌，把旧版本程序或旧插件文件找回来，在新版机器上单独跑一个旧插件的连接导出即可。这件事再次说明：升级插件前先备份旧插件文件和旧库文件，是所有人的血泪经验。
5.3 加了加密后性能衰减明显：I/O 放大的排查方向
加密库写性能下降是必然的，但下降到让业务无法接受，就值得排查了。常见场景是批量sqlite update或大量INSERT时，速度比明文库慢了十几倍。第一反应不要怪插件，先看是否每一条语句都自动提交。明文库你可能没注意自动提交，加密库因为每个页都要做加解密和校验，事务提交的代价被放大，于是逐条提交的写法就会暴露严重性能问题。
解决方法是把批量写包进显式事务。你在代码里用BEGIN...COMMIT把几千条INSERT包起来，提交次数从几千次降为一次，性能恢复明显。如果已经包了事务还是慢，第二步看PRAGMA page_size是否与插件推荐值一致。加密插件通常对页面大小有要求，默认为 4096 的库如果被改得太小，每个页的固定开销占比会变大。第三步检查是否开启了 WAL。WAL 模式下加密插件对-wal文件的处理方式差异很大，有些插件实现里 WAL 文件的加密和不加密会带来双倍 I/O，必要时关掉 WAL 回归 default journal 模式，对比一下数据变化。
还有一个隐蔽因素：磁盘本身。加密写入的随机性更强，对闪存设备的随机写性能更敏感。如果加密库跑在机械硬盘上，性能衰减会比 SSD 上明显得多。上线前务必在目标硬件上做一次基准，不要在开发机上测完就当结论。
5.4 部分读取正常但写操作失败：页面大小与文件头标记问题
有个案例，加密库能正常SELECT，但一执行sqlite update就报database disk image is malformed。这个现象的原因常常是插件写入时页大小不匹配：库文件由一个工具创建时用了 1024 字节页，而当前驱动打开时按 4096 字节去解析页偏移，读到了错误位置。SELECT 能查出来是因为数据量小、表结构刚好落在前几页，写入时涉及页分裂或空闲页复用，问题才暴露。
解决方法是统一创建库和打开库的插件参数。不要用明文 sqlite3 工具先建表、再用加密插件打开写数据，两个工具的页大小默认值不一定一致。最稳的做法是：加密库从创建到日常读写，固定用同一套插件、同一套连接参数，从不混用。如果库已经建错了，那就导出重建。另有一个小参数量值得记录：PRAGMA page_size最好在建表之前设置，建表之后再改页大小，在加密插件下往往不会真正生效，这也是“改了半天没变化”的常见原因。
6. 验证加密数据库的读写性能：一份可以直接抄的压测脚本模板
加密库上线前，最忌讳拍脑袋说“性能应该差不多”。我给自己的团队定了一条规矩：任何接入加密插件的模块，必须跑过一轮读写对比，记录明文与密文在不同操作类型下的耗时差异，产出一张对比表再决定是否上线。这里的核心不是追求加密后更快，而是确认性能衰减是否在业务可接受范围内，以及定位瓶颈究竟在 CPU 加密还是在磁盘 I/O。
压测模板可以分成三段：第一段建表和批量插入，第二段走一条带索引的按主键查询，第三段做一万次sqlite update随机改值。用QElapsedTimer计时，注意连接建立和首次打开不包含在正式统计里，先预跑一轮把热数据准备好。测试代码不必做得太复杂，关键是变量控制：同一台机器、同一个库文件路径、同一套数据量、明文库和加密库分别测三轮取中位数，而不是只跑一次就下结论。如果加密后插入耗时从 1 秒变 8 秒，先不要慌，把每批提交数从 1 调到 100，再测一次，很多“加密导致慢”的问题其实是被自动提交放大的。
并发读写的验证更复杂一点。SQLite 本身是单写者模型，加密插件不会改写这个约束，所以并发测试重点应该放在“多线程读、单线程写”的场景。常见做法是开两到三个线程做查询，一个线程做定时写入，观察是否出现database is locked。如果频繁出现，先看是否有连接未关闭、是否有事务长时间未提交，这两点在加密驱动下和明文驱动下表现一样。真要踩到并发瓶颈，优先考虑调整busy_timeout并把写操作串行化，而不是换加密插件。
加密方案选定后，最好把压测脚本留在工程里，作为回归测试的一部分。以后升级 Qt、升级插件、更换部署设备，都重跑一遍，数据变动立刻能看出来。我现在每接手一个新版本插件，都会保留旧版插件的后路，再跑一轮对比，确认没有回归才敢合入发布分支。这既是对用户负责，也是给自己留后悔药。希望这篇文章能帮你把 QtCipher 这条加密路线一次走通，少踩几个我已经踩过的坑。
本文还有配套的精品资源，点击获取
