KeePassXC 2.8.0 是本地密码管理器，Windows 便携包 70348471 字节，解开 155 个文件共 144075777 字节，主程序 KeePassXC.exe 6195288 字节。
它要解决的是：密码不能只靠脑子记，也不能交给浏览器保存。整套数据放在 1 个加密文件里，文件本身随便扔进网盘或 U 盘，没有账号体系也没有云端同步，谁也拿不到。
这次量了 3 个指标：启动到窗口出现要多久，它最关键的旋钮——按目标解密时间校准的密钥派生函数——四档设置各要多少转换次数、建库和开库各花多少时间。
155 个文件，144075777 字节
官方的 x64 便携包是 70348471 字节，解开是 155 个文件，合计 144075777 字节。压缩比 2.05，大头是 Qt 的 DLL 和一份 VC 运行库安装包。
| 文件 | 字节 | 说明 |
|---|---|---|
| KeePassXC-2.8.0-x64.zip | 70348471 | 便携包，免安装 |
| 解压后合计 | 144075777 | 155 个文件 |
| KeePassXC.exe | 6195288 | 图形界面主程序 |
| keepassxc-cli.exe | 2755672 | 命令行版本，独立可用 |
| vc_redist.x64.exe | 18731992 | 微软运行库安装包，占 13% |
| botan-3.dll | 加密库 | KDBX 的算法实现 |
vc_redist 占了七分之一体积
18731992 字节的 vc_redist.x64.exe 是给没装运行库的机器用的，装在便携包里只是为了离线可用。系统已经有 VC++ 运行库时，删掉它可以省 18 MB，程序照跑。
图形界面和命令行是两个 exe
KeePassXC.exe 6195288 字节、keepassxc-cli.exe 2755672 字节，两者读同一份 kdbx 文件。命令行版本不需要图形界面，可以挂在脚本里自动取密码、导出条目。
窗口 628 毫秒出来
三次启动分别测到 809、628、628 毫秒，第一次慢是因为从磁盘冷读 6195288 字节的主程序和一堆 Qt DLL。
| 轮次 | 首帧（毫秒） |
|---|---|
| 1 | 809 |
| 2 | 628 |
| 3 | 628 |
628 毫秒里有一半是 Qt 初始化
155 个文件里 Qt6 相关的 DLL 有 7 个，启动时要全部映射进内存。同一个包里的命令行版本只加载需要的部分，起得更快。
首帧是欢迎页不是主窗口
628 毫秒出来的是「新建数据库 / 打开数据库」的欢迎页，密码库真正打开还要再等一次 KDF 计算，那部分时间由下面的设置决定。
按目标时间校准密钥派生
建库时可以指定 1 个目标解密时间，程序先跑一遍基准测试，算出需要多少次转换才能刚好卡在这个时长上。这是它和大多数密码管理器最大的区别：安全强度跟着机器性能走，而不是写死一个迭代数。
| 目标解密时间 | 实际写入的转换次数 | 建库耗时 |
|---|---|---|
| 100 毫秒 | 8108108 | 458 毫秒 |
| 500 毫秒 | 40540540 | 1267 毫秒 |
| 1000 毫秒 | 83333336 | 2329 毫秒 |
| 3000 毫秒 | 243243232 | 6337 毫秒 |
| 建库比目标多出的部分 | 260 到 340 毫秒 | 四条都落在这个区间 |
> keepassxc-cli db-create -p -t 500 demo.kdbx
以 500 毫秒延迟对密钥派生函数进行基准测试。
为密钥派生函数设置 40540540 转换次数。
已成功创建新数据库。
转换次数和目标是线性关系
100 毫秒要 8108108 次，1000 毫秒要 83333336 次，正好是 10 倍。3000 毫秒要 243243232 次，是 100 毫秒档的 30 倍。这说明单次转换的耗时被估得很准，档位之间没有非线性惩罚。
同一档两次测得的结果不完全一样
| 轮次 | 写入的转换次数 |
|---|---|
| 第一次 | 40540540 |
| 第二次 | 39473684 |
| 相差 | 2.7% |
500 毫秒档第一次算出 40540540 次，另一次算出 39473684 次，差 2.7%。基准测试本身要跑一小段时间，CPU 频率波动和后台进程会让结果有几百毫秒级的偏差，这就是它按时间算而不是按次数算的原因。
建库耗时约等于目标时间的两倍
100 毫秒档建库 458 毫秒，500 毫秒档 1267 毫秒，3000 毫秒档 6337 毫秒，四条都符合「目标 × 2 加 260 到 340 毫秒」。多出来的一倍是因为基准测试跑完还要真正做一次加密写出，再加约 300 毫秒的进程启动。
开库耗时几乎等于目标时间
用同样的口令打开四个库，实测 270、661、1197、3208 毫秒，和目标设置几乎重合，差的那部分是一次进程启动的开销。
| 目标 | 打开耗时 | 差值 |
|---|---|---|
| 100 毫秒 | 270 毫秒 | 加 170 |
| 500 毫秒 | 661 毫秒 | 加 161 |
| 1000 毫秒 | 1197 毫秒 | 加 197 |
| 3000 毫秒 | 3208 毫秒 | 加 208 |
170 到 208 毫秒是进程开销
四个差值集中在 161 到 208 毫秒之间，这部分和 KDF 无关，是命令行程序加载 DLL、解析参数、读文件的时间。图形界面版本打开库时不需要重新起进程，会省掉这一块。
3000 毫秒的档位日常不推荐
每次开库等 3.2 秒，一天开十次就是半分钟。500 毫秒档开库 0.66 秒，手感上刚好，而它写入的 40540540 次转换是 100 毫秒档的 5 倍。
一个空库在 1.5 KB 上下
四档建出来的空库分别是 1358、1886、1390、1486 字节，都在 1.5 KB 上下，和加密强度无关。
| 目标 | 库文件大小 |
|---|---|
| 100 毫秒 | 1358 字节 |
| 500 毫秒 | 1886 字节 |
| 1000 毫秒 | 1390 字节 |
| 3000 毫秒 | 1486 字节 |
| 折合 | 1.3 到 1.8 KB |
| 最大与最小相差 | 128 字节 |
大小差异来自元数据而不是密文
1486 和 1358 差 128 字节，这点差别来自 XML 头的字段长度和填充，不是加密强度。四档都是空库，只有一条记录都没放的状态。
整个密码库可以塞进任何地方
1.5 KB 意味着一个装满几千条密码的库也就几百 KB，扔进网盘、邮件附件、U 盘都行。它本身是加密的，传输通道不重要，口令强度才重要。
8 个文件占掉大半体积
144075777 字节里，前 8 个文件分别从 6.5 MB 到 20.6 MB，加起来约 93 MB，占整个目录的 65%。剩下 147 个文件一共才 50 MB 出头。
| 文件 | 字节 | 作用 |
|---|---|---|
| opengl32sw.dll | 20637784 | Qt 的软件 OpenGL 回退实现 |
| vc_redist.x64.exe | 18731992 | VC++ 运行库离线安装包 |
| dxcompiler.dll | 14260824 | DirectX 着色器编译器 |
| Qt6Core.dll | 10361944 | Qt 核心 |
| Qt6Gui.dll | 9544792 | Qt 图形基础 |
| botan-3.dll | 7147608 | 加密算法库 |
| Qt6Widgets.dll | 6495320 | Qt 控件 |
| KeePassXC_UserGuide.html | 6487158 | 离线用户手册 |
| 这 8 个合计 | 约 93 MB | 占 144075777 字节的 65% |
| 目录文件总数 | 155 个 | 其余 147 个共约 50 MB |
| translations 目录 | 5741666 | 语言包合计 |
| share 目录 | 29175819 | 手册、图标与默认配置 |
20637784 字节的软件渲染器
opengl32sw.dll 是单文件里最大的一项，作用是显卡驱动不给力时用 CPU 跑 OpenGL。它也让窗口走 GPU 合成路径，这就是为什么抓窗口位图拿到的是黑屏，必须抓屏幕。
translations 只占 5741666 字节
155 个文件里语言包加起来 5.7 MB，比一个 Qt6Core.dll 还小。中文界面就在这里面，删掉其他语言能省 5 MB，但主程序会缺翻译文件。
share 目录 29175819 字节
share 里放着用户手册、图标主题和默认配置，其中手册一份 6487158 字节。不查文档的人可以把 share 里的大件删掉，程序本身照常启动。
几个真踩过的点
下面三条在这次测试里真实出现，附当时的处理方式。
| 现象 | 原因 | 处理 |
|---|---|---|
| 管道喂口令后提示「输入的凭据无效」 | db-info 要交互式输入，不走标准输入 | 用 db-create 或图形界面，命令行读库改用参数传口令 |
| 建库命令打印一大段英文帮助 | 参数名写错，短选项不存在 | 加条目用 --url / --username 全称，别用 -l |
| 窗口截图全黑 | Qt6 走 GPU 渲染，抓不到位图 | 用命令行版本截图，或改用屏幕抓取而不是窗口抓取 |
如果口令是从管道喂进去的，db-info 会直接失败并返回「输入的凭据无效」，此时改用密钥文件模式加 --no-password 才能跑通。参数写成 -l https://example.com 这种短形式时，add 不会报错，而是把整段帮助打印出来，写成 --url 全称才不触发。
目标时间设成 3000 毫秒以上时，开库会超过 3 秒，脚本里循环调用会因超时而失败；把 -t 降到 500 毫秒，同一条命令的耗时落到 0.66 秒，才算适合放进自动化。
参数名必须写全称
add 的短选项里没有 -l，写成 -l https://example.com 会直接打印帮助而不是报错。它只认 --url、--username 这样的全称。
命令行版本不读管道口令
建库能通过管道喂两次口令，但 db-info、ls、add 这些要解锁已有库的命令不认管道输入，会判定凭据无效。脚本里用它们要么配 --no-password 的密钥文件模式，要么换图形界面。
什么场景值得上
密码数量超过二十个、又不想把它们交给浏览器或云端服务时，一个一千多字节的加密文件是最省心的方案。
| 场景 | 合适度 | 说明 |
|---|---|---|
| 管理几十上百个账号 | 高 | 库文件 1.5 KB 起，随条目线性长 |
| 多台设备同步 | 高 | 把 kdbx 放网盘即可，加密在文件层 |
| 脚本里自动取密码 | 中 | 要用 keepassxc-cli 加密钥文件模式 |
| 团队共享凭据 | 中 | 共享库能做，但权限粒度不如服务端方案 |
| 替代浏览器保存密码 | 高 | 不依赖浏览器，换浏览器不丢 |
它不做云端同步
没有服务器、没有账号、没有同步协议。2 台以上设备用同一个库文件，同步交给 Dropbox 或坚果云这类通用网盘，冲突要自己处理。这是它的设计取向，不是缺陷。
授权与费用
GPL-2.0 与 GPL-3.0 双许可，个人和商业环境都不收费。源码在 GitHub 上，主要语言 C++，带 Qt 图形界面和独立的命令行版本。
