电脑送修或借人前，私密文件为什么适合放进本地保险箱

电脑要借给别人、送去维修，或者临时让同事操作一下时，最麻烦的往往不是“有没有加密软件”，而是文件太散。

桌面有临时资料，下载目录里有证件扫描件，聊天软件收过合同，相册备份又在另一个文件夹。真到要把电脑递出去的时候，再手动搜索、移动、删除，基本来不及，也容易漏。

从 Windows 桌面程序的角度看，这个问题不应该只理解成“把文件加密”。用户真正需要的是一个平时能正常使用、需要时能收起来的本地文件空间。

为什么不太建议自己做一套加密文件格式

自己设计加密文件格式，看起来很直接：读文件，加密，写回。可真实使用里，文件不是一段静态数据。

Word 会生成临时文件，图片编辑器可能覆盖保存，很多程序会先写中间文件再重命名。用户也不会只通过你的应用操作文件，他会从资源管理器拖进去，从另一个软件里“另存为”，或者直接改名。

如果应用自己维护一套虚拟文件列表，就要重新适配这些操作。做得轻了，不像普通磁盘；做得重了，几乎是在补一个小型文件系统。

一个更稳的分工：VHDX、NTFS、BitLocker

我更倾向于把本地文件保险箱拆成三层：

保险箱文件 -> 挂载为虚拟磁盘 -> 使用 NTFS 保存普通文件 -> 用 BitLocker 做卷级加密 -> 应用程序负责打开、锁定和卸载

VHDX 负责容器。它把一组文件装进一个虚拟磁盘文件里，不需要应用自己发明文件布局。

NTFS 负责普通文件系统体验。复制、保存、改名、临时文件和异常退出后的文件系统一致性，都继续交给 Windows 熟悉的机制处理。

BitLocker 负责锁定状态下的卷级加密。它不是应用里的一个按钮，而是一段生命周期：创建、挂载、解锁、使用、锁定、卸载和恢复。

程序要管的是边界，不是把所有动作塞进界面

涉及虚拟磁盘和 BitLocker 时，桌面界面不适合自己执行所有高权限动作。更稳的做法，是让 UI 提交有限请求，由后台服务重新校验目标和状态。

用户界面 -> 提交结构化请求 -> 后台服务校验目标、权限和当前状态 -> 调用 Windows 虚拟磁盘与 BitLocker 能力 -> 返回稳定结果

示意代码可以很简单：

return request.Kind switch { "QueryVaultStatus" => QueryVaultStatus(request), "OpenVault" => ValidateThenOpenVault(request), "LockVault" => ValidateThenLockVault(request), _ => Result.Rejected("unsupported_command") };

重点不是这几行代码，而是服务端只接受有限命令集。管道只是传输层，不是信任边界；请求来自本机，也不等于一定可以执行。

错误提示也要分开给人和程序看

保险箱打不开，可能是容器不存在、密码错误、卷被占用、服务不可用、操作超时，或者用户取消。只返回一段字符串，后面很容易变成 UI 在匹配错误文本。

public sealed record VaultResult( bool Success, string Code, string UserMessage, string? DebugDetail);

Code 给程序判断，UserMessage 给普通用户看，DebugDetail 留给日志和排查。密码、恢复材料、用户文件路径这些内容，不应该直接出现在普通弹窗里。

回到电脑借人和送修这类场景

对普通用户来说，这套设计最后服务的是很具体的时刻：电脑送修前，先把照片、证件和合同收进一个地方；电脑临时借人时，不用翻遍每个目录；办公室电脑里同时有工作文件和私人文件时，长期分开保存；临时离开座位时，再配合其它快速保护动作处理屏幕内容。

我们做超级看门狗 SuperWatchDog 时，也是按这个方向取舍的。用户看到的是 .dogvault 保险箱文件，底层用固定大小 VHDX + NTFS + BitLocker 承接长期私密文件；另外再配合手动、快捷键、USB 拔出、蓝牙断开等触发方式，处理突然离开或有人靠近电脑时来不及整理屏幕的问题。

它不是重新发明加密算法。更准确地说，是把 Windows 已有的加密、虚拟磁盘和本地触发能力整理成普通用户能理解的流程。