用云密码管理器用了这么多年，LastPass 今年又出一次安全事件之后，我才真的开始重新想这件事。

不是”云密码管理器不行”这种泛泛的判断。而是我开始问自己一个很具体的问题：我有多少条密码，实际上是我自己说了算的。答案可能比多数人愿意承认的要少很多。

这篇文章分享我把云密码管理器换成本地密码库的完整过程，包括哪些坑值得提前知道，哪些代价其实是合理的。

本地密码库到底在管什么

云密码管理器的逻辑很简单：注册账号，密码存厂商服务器上，任何设备登录，密码就在那。省事，代价是你的全部数字身份，押在一个你无法审计的第三方身上。

本地密码库反过来：

• 所有密码、笔记、安全事件记录都存在你自己设备上的一个 .kdbx 文件里
• 主密码是你唯一的钥匙，没有”找回主密码”这种选项（因为厂商根本不知道它是什么）
• 文件可以放哪儿就放哪儿，完全由你决定

KeePassXC 是我选的具体实现，但同样的思路也适用于其他本地密码库工具。

主密码：这是整个体系里唯一真正的弱点

本地密码库的安全性上限，几乎完全取决于你设的那个主密码。

云密码管理器里，主密码被泄露了，你还有账号找回流程兜底——虽然那个流程本身也依赖邮箱和手机号。本地库里，主密码泄露等于全库泄露，没有任何补救路径。

我用的是一条 18 位的随机密码，没有任何可以记忆的规律。用系统自带生成器就行，关键是别选那种你觉得”记得住”的——记得住的东西，通常也是别人猜得出来的那类。

另外一个实操建议：把主密码本身也写进 3-2-1 备份，写在离线介质上，放两个不同的物理位置。数据库文件丢了、主密码忘了，这两种灾难性场景里这就是唯一的救命绳。

多设备同步：Syncthing 是答案，但不是唯一答案

本地密码库最大的日常摩擦点，就是同步。

我目前的同步方案

1. 主库文件放在 Syncthing 同步目录里
2. 笔记本、台式机、备用笔记本电脑三个设备通过 Syncthing 保持同步
3. 手机用 KeePassDX（Android）或 Strongbox（iOS）直接读取 .kdbx 文件，不经过中间服务器

这套方案最核心的好处，同步链路不经过任何厂商服务器，全在设备之间直连传输。代价是初始配置稍微麻烦，移动端尤其如此。

替代方案：加密网盘

不想折腾 Syncthing 的话，加密网盘也可以：把 .kdbx 文件放进端到端加密的网盘目录，效果和直连同步差别不大，只是多经过一个节点。

备份：3-2-1 规则在这里特别适用

本地密码库文件本身很小（几百 KB 到几 MB 不等），但丢了的后果不可接受。我按 3-2-1 备份：

具体做法

• 三份：本机一份、Syncthing 同步副本一份、加密硬盘一份
• 两种介质：SSD 和机械硬盘
• 一份离线：那盘加密硬盘不接在任何网络里，只在需要的时候才挂载

别忘了测试恢复

定期测试能不能真的打开这个文件。备份不做恢复测试等于没备份，这句话在密码库这里尤其成立，你无法承受”密码库丢了，备份也打不开”这种双重失败。

哪些场景下我仍然用云密码管理器

说实话，本地密码库不是无脑更好，它是有明确取舍的：

• 需要跨团队协作共享密码，本地库在多人协作场景下明显不如云方案，KeePass 数据库靠定期分发，不适合高频协作
• 只用手机，没有稳定桌面设备，移动端本地密码库的体验远不如云方案流畅
• 懒得维护备份和同步，”懒得”不是性格缺陷，是客观约束；云方案的价值就在于把维护成本外包了

如果你的场景落在这三条里，云密码管理器仍然合理，只是选型时得认真看它的安全审计记录，不能只看”方便”。

总结

从云密码管理器换到 KeePassXC，本质上是信任位置的转移：从”我信任这家公司的安全团队”，变成”我信任自己管好这个文件和这条主密码”。

这个转移没有绝对的对错，只看你更信哪个。但有一个通用的判断标准：你有没有能力、有没有意愿，为自己的全部数字身份承担最后那层责任。有的话，本地方案值得；没有的话，云方案的便利是有价值的，只是要把安全记录当作选型的硬性门槛，不能只图省事。