群晖NAS部署hat.sh：浏览器本地文件加密解密工具自托管指南

1. 项目概述与核心价值

最近在折腾NAS上的文件安全方案，发现一个挺有意思的开源工具——hat.sh。这玩意儿本质上是一个运行在浏览器里的本地文件加密解密工具，但它最大的亮点是支持自托管。这意味着你可以把它部署在自己的群晖NAS上，通过内网或者安全的公网访问来使用，所有加密解密操作都在你的浏览器里完成，文件数据压根不上传到任何第三方服务器。对于像我这样，既想把一些敏感文件（比如合同扫描件、家庭照片备份、项目资料）安全地存到NAS里，又或者需要加密后分享给特定伙伴，但又对网盘服务商不那么放心的人来说，hat.sh提供了一个非常轻量且优雅的解决方案。

它的核心逻辑很简单：你通过浏览器访问部署在NAS上的hat.sh网页，上传文件，选择用密码或者更安全的公钥/私钥对进行加密，加密过程完全在你的电脑浏览器里利用JavaScript完成，生成一个加密后的文件让你下载。解密时同样，把加密文件上传回这个页面，输入正确的密码或私钥，文件就在浏览器里被还原了。整个过程，你的原始文件内容和密钥从未离开过你的本地环境，NAS上的hat.sh服务只是提供了一个交互界面和必要的算法库。这种“服务器只提供工具，数据不出本地”的模式，在隐私越来越受重视的今天，显得格外靠谱。

我选择在群晖上部署，一方面是看中了NAS 7x24小时在线的特性，随时可用；另一方面，群晖的Docker环境（现在叫Container Manager）成熟稳定，部署这种开源应用几乎是一键式操作。部署好后，你不仅可以在家里局域网用，配合DDNS或者内网穿透，在外面也能安全地访问自己的加密工具，实用性直接拉满。接下来，我就详细拆解一下在群晖DSM系统上，从零开始部署、配置到深度使用hat.sh的全过程，并分享一些我踩过坑才总结出来的实操技巧。

2. 部署环境准备与核心组件解析

2.1 为什么选择Docker部署？

在群晖上部署第三方应用，主要有几种方式：直接安装SPK套件、通过第三方社区套件源、或者使用Docker。hat.sh官方并没有提供SPK套件，因此Docker成了最主流、最干净的选择。Docker部署的优势非常明显：环境隔离。hat.sh及其依赖的所有库（比如它核心依赖的libsodium加密库）都被打包在一个独立的容器里，不会污染你群晖宿主机的系统环境。以后升级、降级或者删除，直接操作容器或镜像即可，清理得彻彻底底。群晖的Container Manager对Docker的图形化支持做得不错，大大降低了命令行操作的门槛。

这里需要明确一个关键点：我们部署的shdv/hat.sh:latest镜像，里面包含的是一个提供Web界面的静态文件服务器（比如Nginx）以及hat.sh的所有前端JavaScript代码和资源。它本身不负责加密运算。加密解密这个最核心、最消耗资源的任务，是由访问这个网页的客户端浏览器，通过加载并运行页面中的JavaScript代码来完成的。服务器容器只是“送水工”，把工具（代码）送到你手上，具体“砍柴”（加密）的活儿是你的浏览器CPU在干。这种架构决定了它对NAS的性能要求极低，哪怕是最入门的机型也毫无压力。

2.2 群晖系统前提检查

在开始之前，请确保你的群晖NAS满足以下条件：

1. DSM版本：建议为DSM 7.0或以上版本。DSM 6.x的Docker套件（Docker）和DSM 7.x的Container Manager在核心上一致，但界面和部分功能有差异，本文以DSM 7.x的Container Manager为例进行说明，DSM 6.x用户操作逻辑类似。
2. Container Manager套件：确保已安装。可以在“套件中心”直接搜索“Container Manager”进行安装。这是群晖官方维护的Docker管理工具，是后续所有操作的基础。
3. 存储空间：在某个存储卷（如volume1）上，需要有一个用于存放Docker配置和数据的目录。通常群晖会默认在docker共享文件夹下管理，但我们最好为自己创建独立的应用文件夹。
4. 网络环境：你的NAS需要能够连接互联网以下载Docker镜像。同时，你需要知道NAS的内网IP地址（如192.168.1.100）。

注意：如果你的群晖是“黑群晖”或处于特殊网络环境，请确保其网络通畅，并且你对其有管理员权限。本文所有操作均在正版群晖及合法网络环境下进行，不涉及任何系统破解或网络穿透的违规内容。

2.3 创建专属的Docker应用目录

虽然Container Manager可以自动处理很多路径，但养成良好的习惯——为每个Docker应用创建独立的目录，对于后期管理和备份至关重要。这里我强烈建议不要直接使用默认的docker共享文件夹根目录。

通过群晖的“File Station”文件管理器，我通常在docker共享文件夹下，为每个应用新建子文件夹。对于hat.sh，我创建了路径：/docker/hat_sh（注意，路径中避免使用空格和特殊字符，用下划线连接更稳妥）。 这个hat_sh文件夹将用于存放我们稍后编写的Docker Compose配置文件。虽然hat.sh这个镜像本身是无状态的（不保存用户数据），但将配置文件集中管理是个好习惯。你可以根据自己喜好选择其他位置，只要在Container Manager中能正确指向即可。

3. 使用Container Manager部署hat.sh

群晖的Container Manager支持通过“项目”功能来部署基于Docker Compose的多容器应用。对于hat.sh这样的单容器应用，使用“项目”方式来管理同样方便，因为它能通过一个docker-compose.yml文件来定义所有服务配置，清晰且易于版本管理。

3.1 编写Docker Compose配置文件

打开File Station，进入刚才创建的/docker/hat_sh目录。点击“新增” -> “新建文本文件”，创建一个名为docker-compose.yml的文件。用文本编辑器（如群晖自带的Text Editor，或下载Synology Office套件）打开它，输入以下配置内容：

version: '3.8' services: hat-sh: image: shdv/hat.sh:latest container_name: hat-sh restart: unless-stopped ports: - "3991:80" # 可选：如果你希望将容器内的某些日志或临时文件映射出来，可以取消注释以下行 # volumes: # - ./logs:/var/log/nginx

现在，我们来逐行解析这个配置文件的关键点：

• version: '3.8'：指定Docker Compose文件的格式版本。‘3.8’是一个较新且广泛兼容的版本。
• services:：定义服务的开始。
• hat-sh:：这是我们自定义的服务名称，在Compose文件中引用。
• image: shdv/hat.sh:latest：指定要拉取的Docker镜像。shdv/hat.sh是官方镜像在Docker Hub上的仓库名，:latest标签表示总是拉取最新的稳定版。出于稳定性考虑，在生产环境你可以考虑指定一个具体的版本号标签（如shdv/hat.sh:v2.1.0），避免自动更新可能带来的意外变化。
• container_name: hat-sh：为即将创建的容器指定一个易于识别的名字，方便在Container Manager界面中管理。
• restart: unless-stopped：这是容器重启策略。unless-stopped意味着除非你手动停止这个容器，否则无论它因何原因退出（比如进程崩溃、NAS重启），Docker都会自动重新启动它。这保证了服务的持续可用性。
• ports: - "3991:80"：这是端口映射，是整个配置的核心之一。它将容器内部的80端口（hat.sh Web服务默认监听的端口）映射到NAS宿主机的3991端口。这意味着，你通过浏览器访问http://你的NAS内网IP:3991时，流量就会被转发到容器内的hat.sh服务。端口号3991可以自定义，只要不与NAS上其他服务（如DSM管理端口5000/5001，或其他Docker应用端口）冲突即可。常用可选端口如8080、8888、9000等，请根据实际情况调整。

3.2 通过“项目”功能部署

1. 打开Container Manager，在左侧导航栏点击“项目”。
2. 点击“新增” -> “从URL添加”。虽然我们是从本地文件创建，但这里选择“从URL添加”后，在下一个界面可以选择“上传”。
3. 在“项目名称”处，输入一个易于识别的名字，例如HatSh-File-Encryptor。
4. 在“项目路径”处，点击“浏览”，选择我们刚才创建并保存了docker-compose.yml文件的目录，即/docker/hat_sh。
5. 最重要的一步：在“源路径”处，Container Manager应该会自动识别出该目录下的docker-compose.yml文件并显示。如果没有，请手动点击“选择”，然后定位到/docker/hat_sh/docker-compose.yml文件。
6. 点击“下一步”。Container Manager会解析你的YAML文件并显示预览。确认服务名、镜像、端口映射等信息无误。
7. 继续点击“下一步”，这时Container Manager会开始从Docker Hub拉取shdv/hat.sh:latest镜像。拉取速度取决于你的网络环境。
8. 镜像拉取完成后，点击“完成”。Container Manager会自动根据配置创建并启动容器。

回到Container Manager的“容器”界面，你应该能看到一个名为hat-sh（或你在container_name中指定的名字）的容器，其状态应为“运行中”。

3.3 验证部署与初步访问

部署完成后，我们需要验证服务是否正常运行。打开你电脑的浏览器，在地址栏输入：http://你的群晖内网IP:3991。例如，如果你的NAS IP是192.168.1.100，那么就访问http://192.168.1.100:3991。

如果一切顺利，浏览器将加载出hat.sh的Web界面。界面通常很简洁，会有语言选择（支持中文）、以及明显的“加密”和“解密”按钮区域。首次加载可能会需要一点时间，因为浏览器要下载并缓存一些JavaScript资源。

实操心得：如果访问时出现“无法连接”或“连接被拒绝”的错误，请按以下步骤排查：

1. 检查容器状态：回到Container Manager，确认hat-sh容器的状态是绿色的“运行中”。如果不是，点击容器名称查看“日志”输出，通常会有错误信息提示（比如端口冲突）。
2. 检查防火墙：确保群晖DSM的“控制面板” -> “安全性” -> “防火墙”没有设置规则阻止了3991端口的入站连接。可以临时关闭防火墙测试，或者添加一条允许3991端口的规则。
3. 检查端口冲突：使用群晖的“资源监控”工具或SSH登录后使用命令netstat -tunlp | grep :3991，查看3991端口是否已被其他程序占用。如果占用，修改docker-compose.yml中的端口映射，比如改为- "3992:80"，并重新部署项目（在Container Manager的“项目”中，找到对应项目，选择“操作”->“重新创建”）。

4. hat.sh核心功能深度使用指南

成功访问Web界面只是第一步，hat.sh的强大之处在于其提供的两种加密方式和针对大文件的优化处理。理解并正确使用这些功能，是保证安全性和体验的关键。

4.1 加密操作：密码模式与公钥模式

在hat.sh界面点击“加密”，你会被引导上传一个或多个文件。上传后，核心的选择来了：加密方式。

1. 密码加密模式这是最简单直接的方式。你输入一个强密码，hat.sh使用这个密码派生出加密密钥对文件进行加密。

• 优势：简单易用，无需管理密钥文件。分享时，你只需要把加密文件和密码（通过安全渠道）告诉对方即可。
• 劣势：安全性完全依赖于密码的强度。如果密码较弱，容易被暴力破解。此外，密码需要在双方之间安全传输，这本身可能成为一个风险点。
• 操作要点：
  • 密码强度：务必使用高强度密码，建议长度12位以上，混合大小写字母、数字和特殊符号。避免使用生日、常见单词等。
  • 密码确认：hat.sh通常会要求输入两次密码以防止输错，请仔细核对。
  • 记住密码：加密后，密码必须妥善保存。一旦丢失，文件将永久无法解密。建议使用密码管理器（如Bitwarden，也可部署在NAS上）来存储这类密码。

2. 公钥加密模式这是一种非对称加密方式，更安全，也更适合需要频繁安全通信的场景。你需要生成一对密钥：公钥和私钥。

• 公钥：可以公开分享给任何人。他们用你的公钥加密文件，加密后的文件只有你用对应的私钥才能解开。
• 私钥：必须绝对保密，存放在本地，绝不能泄露。它是解密的唯一凭证。
• 操作流程： a. 在hat.sh界面找到“生成密钥对”功能（通常在设置或高级选项里）。点击后，浏览器会生成一对密钥。 b.立即备份私钥！hat.sh可能会以文本形式显示私钥，或者提供下载选项。你必须将私钥保存到一个安全、离线的地方（如加密的U盘、打印出来物理保存）。浏览器刷新或关闭后，生成的私钥可能丢失！c. 将公钥复制或发送给需要向你发送加密文件的人。 d. 对方在加密时，选择“公钥加密”模式，并粘贴你的公钥。 e. 加密后的文件发回给你，你使用自己保存的私钥进行解密。
• 优势：无需交换密码，公钥可以公开。私钥永不泄露，安全性极高。可以一对多通信（多人用你的公钥加密，只有你能解密）。
• 劣势：密钥管理稍复杂，需要安全备份私钥。如果私钥丢失，所有用对应公钥加密的文件都无法解密。

重要注意事项：无论哪种模式，hat.sh的加密过程都在你的浏览器内存中进行。加密完成后，浏览器会生成一个加密文件让你下载。原始的未加密文件并不会自动从你的电脑或浏览器缓存中删除。你需要在加密操作完成后，手动清理浏览器上传的文件缓存，并在本地安全地删除原始文件（如果必要），这才是完整的加密流程。

4.2 大文件处理与分块加密机制

hat.sh宣传支持大文件，这得益于其内置的“分块处理”机制。对于体积巨大的文件（比如几个GB的视频备份），直接加密可能会耗尽浏览器内存导致标签页崩溃。

hat.sh的解决方案是将大文件分割成较小的块（例如每块64MB），然后逐块进行加密，最后再合并成一个完整的加密文件。这个过程对用户是透明的，你只需要像处理小文件一样操作即可。

• 体验：在上传一个超大文件时，界面可能会显示进度条，或者浏览器看起来“卡住”了一会儿，这正是在进行分块处理，属于正常现象。请保持页面打开，不要刷新或关闭。
• 性能影响：加密/解密的速度主要取决于你电脑的CPU性能、可用内存以及文件大小。对于特大文件，请耐心等待。建议在进行此类操作时，关闭其他占用大量CPU的网页或程序。
• 浏览器兼容性：由于重度依赖现代JavaScript API和WebAssembly（用于高性能加密运算），请确保使用较新版本的Chrome、Firefox、Edge或Safari浏览器。过时的浏览器可能无法正常工作。

4.3 解密操作与常见问题

解密是加密的逆过程。点击“解密”，上传.enc后缀的加密文件，然后根据加密时采用的方式，输入正确的密码或选择并加载对应的私钥文件。

这里有几个非常关键的细节，直接关系到解密成败：

1. 文件后缀的重要性：hat.sh加密后的文件默认会带有.enc后缀（例如my_document.pdf.enc）。这个后缀是hat.sh识别文件为加密格式的重要标志。虽然在某些情况下，重命名去掉.enc后缀后，hat.sh仍然可能通过文件头信息识别并解密（如参考文章中提到.jpg的例子），但这并非官方保证的行为，存在风险。最佳实践是保留.enc后缀，以确保解密工具能100%正确识别。

2. 通过微信等社交工具传输加密文件：这是很多人会遇到的实际场景。参考文章中提到，将加密文件（如photo.jpg.enc）重命名为无后缀文件后，通过微信的“图片”方式发送可能会失败，因为微信服务器会检测图片格式。正确的做法是：始终使用微信的“文件”功能来发送加密文件。在微信聊天框中，选择“文件” -> “手机中的文件”（或从电脑选择），然后选中你的.enc文件。这样发送的是原始文件流，数据不会经过微信的转码或压缩，保证了文件的完整性。接收方保存后，文件依然是完整的加密文件，可以正常用hat.sh解密。

3. “密码错误”或“解密失败”：

   • 密码模式：请百分百确认输入的密码与加密时设置的完全一致，包括大小写、空格和特殊符号。一个字符的错误都会导致失败。
   • 公钥模式：确认你加载的私钥文件与加密时使用的公钥是配对的一对。一对密钥是唯一的，用A公钥加密的文件，绝不能用B私钥解开。
   • 文件损坏：如果文件在传输或存储过程中损坏，解密也会失败。可以尝试重新获取源加密文件。

5. 进阶配置与安全加固

基础部署完成后，我们可以从网络访问、持久化和更新维护几个角度，让这个自托管的hat.sh服务更安全、更易用。

5.1 配置反向代理与HTTPS访问（强烈推荐）

直接通过IP:端口访问（如http://192.168.1.100:3991）虽然简单，但不够优雅，也不安全（HTTP是明文传输）。更专业的做法是配置反向代理，并通过HTTPS访问。群晖的Web Station和反向代理服务器可以轻松实现这一点。

目标：实现通过一个子域名（如https://hat.yourdomain.com）安全地访问hat.sh服务。

前提：你拥有一个域名，并且已经在群晖的“控制面板” -> “登录门户” -> “应用程序门户”中配置过反向代理，或者熟悉Nginx/Apache配置。同时，你还需要为域名配置SSL证书（群晖内置的Let‘s Encrypt免费证书就很好用）。

操作步骤概览：

1. 规划端口：我们让hat.sh容器继续使用3991端口，但不对公网暴露。我们在NAS内部再创建一个安全的访问通道。
2. 配置反向代理：
   • 进入群晖“控制面板” -> “登录门户” -> “高级” -> “反向代理服务器”。
   • 点击“新增”。在“常规”选项卡中：
     • 描述：Hat.sh Secure Access
     • 来源：协议HTTPS，主机名hat.yourdomain.com，端口443。
     • 目的地：协议HTTP，主机名localhost，端口3991。（这里localhost指NAS本机，因为容器映射到了宿主机的3991端口）。
   • 在“自定义标题”选项卡，可以点击“新增”添加一个X-Forwarded-Proto标题，值为https，这有助于某些应用识别原始协议。
   • 点击“确定”保存。
3. 配置SSL证书：
   • 在“控制面板” -> “安全性” -> “证书”中，为你域名hat.yourdomain.com签发或导入SSL证书。
   • 在反向代理规则中，来源选择HTTPS后，系统通常会关联已有的证书。
4. 路由器/防火墙设置：确保你的路由器将443端口的入站流量转发到了群晖NAS的内网IP。
5. 访问：完成以上设置后，你就可以通过https://hat.yourdomain.com安全地访问hat.sh了。所有通信都是加密的，即使你在外网使用公共Wi-Fi，传输内容也无法被窥探。

安全警告：即使配置了HTTPS，hat.sh的加密解密运算仍在客户端浏览器完成，密钥和文件内容不经过你的服务器，这符合其安全设计。但HTTPS保护了“访问hat.sh网页”这个通道的安全，防止了中间人攻击篡改网页代码（例如注入恶意脚本窃取你的密钥）。

5.2 容器数据持久化与日志管理

默认的hat.sh镜像不需要持久化存储用户数据，因为状态都在客户端。但有时我们可能希望持久化Web服务器的访问日志，便于排查问题。

修改docker-compose.yml文件，添加一个数据卷映射：

services: hat-sh: image: shdv/hat.sh:latest container_name: hat-sh restart: unless-stopped ports: - "3991:80" volumes: - ./nginx_logs:/var/log/nginx # 将容器内Nginx日志映射到宿主机

然后在/docker/hat_sh目录下创建一个nginx_logs文件夹。这样，容器内Nginx产生的访问日志和错误日志就会保存在NAS的/docker/hat_sh/nginx_logs目录下，即使容器重建，日志也不会丢失。

5.3 版本更新与容器维护

当hat.sh发布新版本时，你可以通过以下步骤安全更新：

1. 在Container Manager的“项目”页面，找到你的HatSh-File-Encryptor项目。
2. 点击“操作” -> “重新创建”。
3. Container Manager会重新拉取shdv/hat.sh:latest镜像（如果本地镜像已是最新，则跳过），并使用新的镜像基于原有配置重新创建容器。
4. 这个过程通常很快，且不会丢失你的反向代理等宿主机构置。

如果你想回退版本，或者锁定某个特定版本，只需修改docker-compose.yml中的image标签，例如改为shdv/hat.sh:v2.0.1，然后再次“重新创建”项目即可。

6. 应用场景延伸与局限性探讨

部署好自托管的hat.sh后，它的用武之地其实很广，但也要清楚其边界。

典型应用场景：

1. NAS本地文件加密归档：将NAS上一些敏感但又不常访问的文档、扫描件加密后存储。即使NAS账户被盗或遭遇勒索软件，没有密码/私钥，这些加密文件也是一堆乱码。
2. 安全文件分享：需要将一份合同草案发给同事审阅，但又不想通过微信、邮箱明文传输。你可以用同事的公钥加密文件，发给他。他收到后，只有用自己的私钥才能打开。你也可以设置一个复杂密码，通过电话或加密通讯工具告知对方。
3. 云端备份前的本地加密：在将文件同步到公有云盘（如Google Drive, Dropbox）之前，先用hat.sh加密。这样，云服务商存储的只是加密后的密文，即使云端数据泄露，你的原始内容依然安全。解密密钥掌握在你自己手里。
4. 跨平台加密解密：由于hat.sh是Web应用，只要有一个现代浏览器，无论是在Windows、macOS、Linux，甚至是手机和平板上，都能访问你的NAS进行加密解密操作，非常灵活。

存在的局限性：

1. 浏览器依赖性：所有操作依赖浏览器环境。如果浏览器扩展、安全设置或网络问题导致JavaScript执行失败，功能将不可用。
2. 大文件性能：虽然支持分块，但加密/解密数GB以上的文件对客户端设备（尤其是手机）的CPU和内存仍是考验，可能耗时较长或导致浏览器无响应。
3. 无服务器端密钥管理：hat.sh的设计决定了它不管理密钥。密钥（密码或私钥）的生成、保存、分发、备份完全由用户自己负责。“密钥丢失即数据丢失”，这是使用任何加密工具都必须牢记的铁律。
4. 功能相对单一：它专注于文件的加密和解密，没有文件管理、版本历史、分享链接有效期设置等更高级的网盘功能。它是一个工具，而非一个完整的加密存储系统。

7. 故障排查与经验实录

即使按照步骤操作，在实际部署和使用中也可能遇到一些问题。以下是我和社区里朋友们遇到过的一些典型情况及解决方法。

问题1：访问Web界面时，页面空白或加载不全。

• 可能原因：浏览器缓存了旧版本的资源，或者网络问题导致部分JavaScript文件加载失败。
• 解决方案：
  1. 首先尝试强制刷新页面（Ctrl+F5 或 Cmd+Shift+R）。
  2. 清除浏览器缓存，然后重新访问。
  3. 打开浏览器的开发者工具（F12），切换到“网络”(Network)选项卡，刷新页面，查看是否有资源（.js, .css文件）加载失败（状态码为4xx或5xx）。如果有，可能是容器服务未完全启动，或者反向代理配置有误。检查容器日志。

问题2：加密/解密过程非常缓慢，甚至浏览器卡死。

• 可能原因：处理的文件过大，超出了客户端设备（特别是内存）的处理能力。
• 解决方案：
  1. 对于超大文件（>2GB），尝试在性能更强的电脑上操作。
  2. 确保在操作期间，关闭其他不必要的浏览器标签页和后台应用，释放内存和CPU资源。
  3. 考虑将大文件分割成更小的部分，分别加密，然后再合并管理（虽然麻烦，但能降低单次操作压力）。

问题3：通过反向代理域名访问时，页面样式错乱或功能异常。

• 可能原因：反向代理配置中，没有正确传递某些HTTP头，或者Web应用的根路径（Base URL）设置有问题。
• 解决方案：
  1. 在反向代理规则中，确保添加了常见的代理头，如：

     X-Forwarded-Proto: https X-Forwarded-Host: hat.yourdomain.com X-Real-IP: $remote_addr

  2. 检查hat.sh的Web应用是否有地方需要配置根路径。对于官方Docker镜像，通常不需要。如果问题依旧，尝试直接通过IP:端口访问，如果正常，则问题基本确定在反向代理配置上。

问题4：Container Manager拉取镜像失败，提示“网络错误”或“超时”。

• 可能原因：Docker Hub镜像仓库网络连接不稳定，或者群晖DNS设置有问题。
• 解决方案：
  1. 检查群晖“控制面板” -> “网络” -> “常规”中的DNS服务器设置，可以尝试更改为8.8.8.8和1.1.1.1等公共DNS。
  2. 在Container Manager的“注册表”设置中，尝试切换镜像下载源（如果有可选项）。
  3. 如果网络环境特殊，可以考虑在能正常访问Docker Hub的机器上，通过docker pull shdv/hat.sh:latest命令拉取镜像，然后导出为文件，再导入到群晖中。具体命令为：
     • 在外部机器：docker save -o hat_sh_latest.tar shdv/hat.sh:latest
     • 将hat_sh_latest.tar文件传到群晖。
     • 在群晖Container Manager的“镜像”页面，点击“新增” -> “从文件添加”，选择该tar文件导入。

一个关键的实操心得：关于私钥备份的再次强调。我见过不止一个朋友因为疏忽而丢失了私钥。hat.sh在浏览器端生成密钥对时，务必、立刻、马上将私钥复制到本地的文本编辑器（如VS Code、记事本）中保存，并立即备份到至少一个离线设备（如U盘）。不要依赖浏览器的“记住”功能，也不要仅仅保存在浏览器的下载文件夹里。最好能打印一份纸质的，放在安全的地方。加密的价值在于密钥，密钥丢了，数据就相当于被你自己永久“勒索”了。