348条密码乱成团？记一次 Bitwarden 密码库优化实战

前言

事情是这样的。Bitwarden 用了好几年，陆陆续续往里塞了一堆密码、API Key、SSH 登录信息，不知不觉攒了 348 条。回头一看 —— 全堆在「No Folder」下面，找个东西得靠搜索框硬搜。

更要命的是，翻了一下发现有 20 多个条目把密码、API Key、备份码直接写在 Notes 明文里。这在自托管的 Vaultwarden 上虽然没泄露风险，但万一哪天导出数据到别处，这就成了隐患。

于是决定花一个下午把密码库彻底收拾一遍。

问题诊断

先列一下翻出来的问题：

敏感数据明文存 Notes。 12 个条目把 Anthropic API Key、Cloudflare R2 Token、各个 VPS 的 Recovery Code 直接写在 Notes 里。Notes 字段是明文存储的，导出时一目了然。

重复条目不少。 粗略一扫有 10 组疑似重复 —— 同一个邮箱服务 mail.mifsh.com 出现 9 次，localhost 出现 4 次，还有一些内网 IP 各出现 2-3 次。

没有文件夹分类。 348 条全在 No Folder 下，SSH 密钥、API 密钥、社交账号、域名 DNS 全部混在一起。

IP 地址命名。 16 个条目直接用 IP 命名，完全看不出是什么服务。192.168.3.166 是 NAS 还是路由器？光看名字不知道。

优化计划：四个 Phase

把问题理清楚后，制定了四阶段执行计划，按优先级排序：

Phase目标涉及条目风险
1. 安全加固敏感数据从 Notes 迁入 Hidden 自定义字段~12 条低
2. 去重检查并删除真重复条目~28 条中（删除操作）
3. 建文件夹分类到 8 个文件夹348 条低
4. 规范命名IP 条目改成「服务 - 用途」格式~16 条低

文件夹结构设计：

📁 服务器 & SSH    → 所有 SSH 密钥和登录信息
📁 VPS & 面板       → VPS 商家的控制面板登录
📁 邮箱             → 各类邮箱账号
📁 域名 & DNS       → Cloudflare、Namesilo 等
📁 API & 密钥       → API Key、Token
📁 开发工具         → GitHub、Docker、Vercel 等
📁 国内服务         → 阿里云、腾讯云等
📁 其他             → 不好分类的

执行过程

Phase 1：安全加固 ✓

用 Bitwarden CLI（bw）逐个处理 12 个条目。每个条目的操作流程：

  1. bw get item <id> 取出当前内容
  2. 在 JSON 里添加 type: 1（Hidden）的自定义字段，把敏感值迁移过去
  3. bw encode | xargs -0 bw edit item <id> 更新

实际需要迁移的只有 Ali-Frp 的 Token、claude.funai.cloud 的 Anthropic API Key、DigitalOcean 的 Recovery Codes 等。还有几个条目 Notes 里的内容其实只是备注（比如「不续费了，慢」），不需要迁移。

12 条全部搞定，没问题。

Phase 2：去重 ✓

排查了 10 组疑似重复，结果大部分不是真重复 —— 比如 mail.mifsh.com 的 9 个条目其实是 9 个不同用户的邮箱账号。最终只删了 1 条真重复。

教训：名字相同不代表是重复，得打开看 username 和 uri 才能判断。

Phase 3：建文件夹 ⚠️ 93%

这是工作量的重头。用 Python 脚本生成迁移映射表（条目名 → 目标文件夹 ID），再通过 bw CLI 逐条 edit。

关键踩坑：300+ 条目的批量操作不能一口气跑完。 Bitwarden 的 session 在大批量写操作后会过期。跑了 100 多条就发现后面的全失败。

后来改成分批，每处理 15 条执行一次 bw sync 刷新 session，问题解决。

最终结果：322 / 347 成功迁移，26 条顽固失败。失败的多数是重名条目 ——bw CLI 按名字匹配时找到的不是我们想要的那条。这种用手动拖拽就行，打开 Web UI 搜名字拖到对应文件夹，比脚本快。

Phase 4：规范命名 ⚠️

16 个 IP 命名的条目需要确认实际用途。按 服务-用途@位置 格式重命名，比如 NAS-QNAP@客厅、Proxmox@书房。

但这步需要用户逐条确认 IP 对应什么服务 —— 我不可能知道 192.168.3.194 是你家的哪个设备 —— 所以脚本只处理了 6 / 13 条，剩下 7 条需要用户手动确认。

额外收获：zcblog 的 GitHub PAT

优化过程中顺便给 zcblog 博客项目创建了两个独立的 GitHub Personal Access Token：

  • ARTICLES_PAT — 用于拉取 / 提交博客文章
  • DISPATCH_PAT — 用于触发 GitHub Actions 工作流

以前复用个人 Token，现在项目有独立凭证，权限更清晰，也存进了 Bitwarden 的「API & 密钥」文件夹。

总结

整个优化完成度约 93%，一个下午搞定。几个经验：

  • bw CLI 适合少量操作，大量条目用 Web UI 拖拽更快。 脚本写迁移逻辑、Web UI 动手执行是最佳分工。
  • 大数量批量操作必须分批 sync。 每 15 条 sync 一次是这次试出来的安全值，多了容易 session 过期。
  • 删除操作逐条确认，不批量。 哪怕用户说了「都删」，也得把每一条对比结果摆出来。
  • 密码库定期体检。 养成习惯，半年翻一次，看看有没有敏感数据还在明文、有没有新增重复。

没做完的收尾工作：26 条顽固条目手动拖进文件夹 + 7 条 IP 改名确认。花 10 分钟就能搞定。