企业官网建设流程全解析

1. 从“打包”到“上锁”：Zip加密到底在解决什么问题

很多人第一次接触“Zip加密”这个概念，是在给客户发压缩包的时候。文件太大，压缩一下方便传输，但里面有些内容不想让无关的人看到，于是顺手在压缩软件里勾了个“设置密码”。这个动作看起来简单，背后其实涉及两个完全不同的技术层面：一个是压缩，一个是加密。C# 里做 Zip 加密，最容易踩的坑就是把这两件事混为一谈，以为调一个 API 就能同时搞定，结果要么加密强度不够，要么跨平台解不开，要么性能差到没法用。

先说清楚一个基本事实：Zip 格式本身是一个容器规范，它定义了文件如何被打包、目录结构如何组织、压缩算法如何标识。而加密，是在这个容器之上附加的一层保护机制。传统 Zip 加密用的是 ZipCrypto，这是一种比较古老的流加密方案，安全性在今天看来已经非常薄弱，存在已知的明文攻击风险。后来 WinZip 引入了 AES 加密，把 AES-256 作为 Zip 容器内的加密标准，这才让 Zip 加密真正达到了可用的安全级别。但问题在于，AES 加密的 Zip 并不是所有解压工具都支持，这就引出了 C# 开发中最常见的兼容性困境。

那为什么还要用 Zip 加密？直接对文件单独加密不行吗？当然行，但 Zip 加密有一个天然优势：它把多个文件和目录结构一起保护起来。你不需要先加密每个文件再打包，也不需要担心打包过程中临时文件泄露。对于批量文件传输、归档备份、自动化任务中的中间产物保护，Zip 加密是一个非常实用的选择。尤其是在 C# 这种经常用来写桌面工具、服务端批处理、自动化脚本的语言里，Zip 加密几乎是绕不开的一个需求点。

这篇文章面向的是已经会用 C# 做基本文件操作、但对加密细节不太熟悉的开发者。我会从 Zip 加密的底层原理讲起，然后重点拆解 .NET 生态里几个主流方案的选型逻辑，接着给出可直接复现的代码实现，最后分享一些我在实际项目中踩过的坑和总结出来的经验。目标很简单：看完之后，你能根据自己的场景选对方案，写出稳定可用的代码，而不是复制一段网上找来的代码然后发现各种奇怪问题。

2. ZipCrypto 与 AES-256：两种加密方式的本质差异

2.1 ZipCrypto 的加密流程与致命弱点

ZipCrypto 是 PKZIP 早期版本引入的加密方式，它的核心是一个基于 CRC32 校验值的密钥派生过程。具体来说，它用三个 32 位状态变量组成一个伪随机数生成器，密码经过一系列变换后初始化这三个状态，然后每加密一个字节就更新状态并生成一个密钥字节。解密时反过来操作，同时用 CRC32 来验证密码是否正确。

这个设计在三十年前是合理的，但今天看有几个致命问题。第一，它的密钥空间实际上受限于密码本身的强度，而且加密强度只有 96 位左右，现代算力下暴力破解并不困难。第二，它存在已知明文攻击：如果你知道压缩包里某个文件的原始内容，就可以推导出加密密钥流，进而解密其他部分。第三，它没有完整性校验机制，攻击者可以在不知道密码的情况下篡改压缩包内容，解密方无法察觉。

我见过不少项目为了“兼容老系统”还在用 ZipCrypto，结果安全审计直接亮红灯。如果你的场景涉及任何敏感数据，ZipCrypto 应该被彻底排除。

2.2 AES-256 在 Zip 容器中的工作方式

AES 加密的 Zip 并不是简单地把整个压缩包用 AES 加密一遍。它的做法是：每个文件条目单独用 AES-256 加密，加密后的数据前面附加一个盐值（salt）和密码验证值，后面附加一个 HMAC 校验值。盐值用于抵抗彩虹表攻击，密码验证值用于快速判断密码是否正确，HMAC 用于保证数据完整性。

这里有一个关键细节：AES 加密的 Zip 使用的是 CTR 模式（计数器模式），而不是常见的 CBC 模式。CTR 模式的好处是可以并行加密、不需要填充，非常适合流式处理。但 CTR 模式本身不提供完整性保护，所以必须配合 HMAC 使用。这也是为什么 AES Zip 的每个文件条目都会多出一些额外字节。

另一个容易被忽略的点是：AES Zip 的压缩和加密顺序。标准做法是先压缩再加密，因为加密后的数据熵值很高，再压缩几乎没有效果。但有些实现为了流式处理会先加密再压缩，这会导致压缩率极差。C# 里用 SharpZipLib 或 DotNetZip 时，这个顺序是库内部处理的，你不需要手动干预，但理解这一点有助于排查性能问题。

2.3 兼容性矩阵：你的解压方支持哪种

选加密方式之前，必须先确认解压方用什么工具。下面这个表格是我在实际项目中整理出来的，覆盖了常见场景：

这张表说明一个残酷现实：如果你要发给普通用户，AES Zip 大概率打不开。Windows 自带解压和 macOS 自带工具都不支持 AES。所以实际项目中，我通常建议：内部系统之间传输用 AES-256，对外分发用 ZipCrypto 加额外保护措施，或者干脆换一种加密方案。

3. C# 生态里的 Zip 加密方案选型

3.1 System.IO.Compression 为什么不能直接加密

.NET 从 4.5 开始内置了 System.IO.Compression 命名空间，提供了 ZipArchive 类。这个类用起来很方便，但它有一个硬伤：完全不支持加密。你可以创建、读取、更新 Zip 文件，但没有任何 API 可以设置密码。这是设计上的取舍，微软把加密功能留给了第三方库。

有些人会想：那我能不能先用 ZipArchive 打包，然后对整个 Zip 文件用 AES 加密？技术上可行，但这样做有几个问题。第一，解压方必须先解密整个文件才能读取目录，无法流式访问单个条目。第二，加密后的 Zip 文件不再是标准 Zip 格式，任何标准工具都打不开。第三，大文件场景下需要额外的临时空间。所以这种做法只适合“加密后只给自己的程序读”的场景，不适合通用文件交换。

3.2 SharpZipLib：老牌库的 AES 支持与坑点

SharpZipLib 是 .NET 生态里历史最悠久的压缩库之一，从 .NET Framework 1.1 时代就存在了。它支持 ZipCrypto 和 AES-256，API 相对底层但可控性强。用 SharpZipLib 做 AES 加密的典型代码是这样的：

using ICSharpCode.SharpZipLib.Zip; using (var zipStream = new ZipOutputStream(File.Create("output.zip"))) { zipStream.SetLevel(6); zipStream.Password = "your-password"; var entry = new ZipEntry("data.txt"); entry.AESKeySize = 256; zipStream.PutNextEntry(entry); var fileBytes = File.ReadAllBytes("data.txt"); zipStream.Write(fileBytes, 0, fileBytes.Length); zipStream.CloseEntry(); }

这段代码看起来简单，但有几个坑必须注意。第一，AESKeySize必须在PutNextEntry之前设置，设置晚了不生效。第二，SharpZipLib 的 AES 实现默认使用 1000 次 PBKDF2 迭代，这个次数在现代安全标准下偏低，但改不了，是硬编码的。第三，如果你加密的是空文件，某些版本的 SharpZipLib 会生成无法解压的条目，需要特殊处理。

还有一个更隐蔽的问题：SharpZipLib 的 AES Zip 在跨平台解压时，7-Zip 能正常打开，但某些在线解压服务会报错。原因是这些服务用的解析库对 AES Zip 的额外字段处理不一致。我遇到过客户反馈“你发的加密包我打不开”，最后发现是对方用的某个国产解压软件对 AES 支持不完整。

3.3 DotNetZip：API 友好但维护状态需关注

DotNetZip 是另一个曾经很流行的库，它的 API 设计比 SharpZipLib 更友好，加密操作只需要设置一个属性：

using (var zip = new Ionic.Zip.ZipFile()) { zip.Password = "your-password"; zip.Encryption = Ionic.Zip.EncryptionAlgorithm.WinZipAes256; zip.AddFile("data.txt", ""); zip.Save("output.zip"); }

DotNetZip 的优点是代码简洁，支持流式操作，对 AES 的支持也比较完整。但它的问题是：原版 DotNetZip 已经很久没有更新了。最后一次稳定版本停留在 2011 年左右，虽然后来有社区分支在维护，但选择时需要确认你用的是哪个分支。另外，DotNetZip 在处理大文件时内存占用较高，因为它默认会把条目内容缓存在内存里，对于几百 MB 以上的文件需要手动调整缓冲区策略。

3.4 选型决策：一张表说清楚

我的建议是：新项目优先考虑 SharpZipLib，因为它的维护状态更可靠，API 虽然底层但可控性强。如果只是快速原型或者内部工具，DotNetZip 的简洁 API 能省不少时间。至于内置 ZipArchive，它适合“不需要加密”的场景，加密需求请直接跳过。

4. 手把手实现一个可用的 Zip 加密工具

4.1 环境准备与依赖引入

我以 SharpZipLib 为例，完整走一遍实现过程。首先通过 NuGet 引入包：

dotnet add package SharpZipLib

当前稳定版本是 1.4.x，支持 .NET Standard 2.0 及以上，也就是说 .NET Framework 4.6.1+、.NET Core 2.0+、.NET 5/6/7/8 都能用。如果你用的是老项目，注意检查目标框架是否满足。

引入之后，在代码文件顶部添加命名空间：

using ICSharpCode.SharpZipLib.Zip; using ICSharpCode.SharpZipLib.Core;

这两个命名空间分别提供 Zip 操作和流处理辅助类。

4.2 加密压缩：从单个文件到整个目录

先看单个文件的加密压缩。下面这个方法是经过我多次调整后的版本，处理了空文件、大文件和异常情况：

public static void EncryptFile(string sourceFile, string outputZip, string password) { if (!File.Exists(sourceFile)) throw new FileNotFoundException("源文件不存在", sourceFile); if (string.IsNullOrEmpty(password)) throw new ArgumentException("密码不能为空", nameof(password)); using (var fs = File.Create(outputZip)) using (var zipStream = new ZipOutputStream(fs)) { zipStream.SetLevel(6); zipStream.Password = password; var entryName = Path.GetFileName(sourceFile); var entry = new ZipEntry(entryName) { DateTime = DateTime.Now, AESKeySize = 256 }; zipStream.PutNextEntry(entry); var buffer = new byte[8192]; using (var sourceStream = File.OpenRead(sourceFile)) { int bytesRead; while ((bytesRead = sourceStream.Read(buffer, 0, buffer.Length)) > 0) { zipStream.Write(buffer, 0, bytesRead); } } zipStream.CloseEntry(); } }

这段代码有几个关键点。第一，AESKeySize = 256必须在PutNextEntry之前设置，这是 SharpZipLib 的要求。第二，我用 8KB 缓冲区做流式读写，而不是一次性读入内存，这样处理大文件时内存占用稳定。第三，SetLevel(6)是压缩级别，0 到 9，6 是速度和压缩率的平衡点，加密场景下压缩级别对最终大小影响不大，因为加密后的数据很难再压缩。

如果要压缩整个目录，需要递归遍历：

public static void EncryptDirectory(string sourceDir, string outputZip, string password) { using (var fs = File.Create(outputZip)) using (var zipStream = new ZipOutputStream(fs)) { zipStream.SetLevel(6); zipStream.Password = password; var baseDir = Path.GetFullPath(sourceDir); var files = Directory.GetFiles(sourceDir, "*", SearchOption.AllDirectories); foreach (var file in files) { var relativePath = Path.GetRelativePath(baseDir, file) .Replace('\\', '/'); var entry = new ZipEntry(relativePath) { DateTime = File.GetLastWriteTime(file), AESKeySize = 256 }; zipStream.PutNextEntry(entry); var buffer = new byte[8192]; using (var sourceStream = File.OpenRead(file)) { int bytesRead; while ((bytesRead = sourceStream.Read(buffer, 0, buffer.Length)) > 0) { zipStream.Write(buffer, 0, bytesRead); } } zipStream.CloseEntry(); } } }

注意relativePath里的反斜杠替换成正斜杠，这是 Zip 规范的要求。Windows 上路径用反斜杠，但 Zip 内部统一用正斜杠，不替换的话在某些解压工具里会创建出奇怪的文件名。

4.3 解密解压：密码验证与异常处理

解密解压的代码相对直接，但异常处理要细致：

public static void DecryptZip(string zipFile, string outputDir, string password) { if (!File.Exists(zipFile)) throw new FileNotFoundException("压缩包不存在", zipFile); Directory.CreateDirectory(outputDir); using (var fs = File.OpenRead(zipFile)) using (var zipStream = new ZipInputStream(fs)) { zipStream.Password = password; ZipEntry entry; while ((entry = zipStream.GetNextEntry()) != null) { if (entry.IsDirectory) { Directory.CreateDirectory(Path.Combine(outputDir, entry.Name)); continue; } var outputPath = Path.Combine(outputDir, entry.Name); var outputDirPath = Path.GetDirectoryName(outputPath); if (!string.IsNullOrEmpty(outputDirPath)) Directory.CreateDirectory(outputDirPath); var buffer = new byte[8192]; using (var outputStream = File.Create(outputPath)) { int bytesRead; while ((bytesRead = zipStream.Read(buffer, 0, buffer.Length)) > 0) { outputStream.Write(buffer, 0, bytesRead); } } } } }

这里有一个重要细节：SharpZipLib 在密码错误时，GetNextEntry或Read会抛出ZipException。但异常信息可能不够明确，你需要自己捕获并给出友好提示：

try { DecryptZip(zipFile, outputDir, password); } catch (ZipException ex) { if (ex.Message.Contains("password") || ex.Message.Contains("AES")) { throw new InvalidOperationException("密码错误或压缩包已损坏", ex); } throw; }

另外，entry.Name可能包含路径分隔符，直接拼接有目录穿越风险。虽然 SharpZipLib 内部会做一些过滤，但稳妥起见，应该验证最终路径是否在输出目录内：

var fullOutputPath = Path.GetFullPath(outputPath); var fullOutputDir = Path.GetFullPath(outputDir); if (!fullOutputPath.StartsWith(fullOutputDir)) throw new InvalidOperationException("检测到非法路径");

4.4 性能优化：缓冲区、并行与内存控制

默认的 8KB 缓冲区在大多数场景下够用，但如果你要处理大量小文件，频繁的 I/O 操作会成为瓶颈。我实测下来，把缓冲区调到 64KB 或 128KB 能明显提升吞吐量，尤其是机械硬盘上。但也不要太大，超过 1MB 后收益递减，反而增加内存压力。

对于多文件场景，可以考虑并行压缩。但要注意：Zip 格式本身是顺序写入的，你不能并行写同一个 ZipOutputStream。可行的做法是先把文件读入内存或临时文件，然后顺序写入。如果文件很多但都不大，可以先用Parallel.ForEach预处理文件列表，计算好每个条目的元数据，再顺序写入。

内存控制方面，最重要的是避免一次性读取整个文件。我见过有人用File.ReadAllBytes然后zipStream.Write，小文件没问题，但遇到几百 MB 的文件直接内存爆掉。流式读写是必须的，这一点没有捷径。

5. 那些文档里不会写的踩坑记录

5.1 密码编码问题导致跨平台解压失败

这是我踩过最隐蔽的一个坑。SharpZipLib 默认用 UTF-8 编码密码，但某些解压工具（尤其是老版本）用系统默认编码处理密码。如果你的密码包含非 ASCII 字符，比如中文或特殊符号，就可能出现“同一密码在 A 工具能解开，在 B 工具解不开”的情况。

解决方案很简单：密码只用 ASCII 字符。字母、数字、常见符号的组合足够安全，没必要用中文密码。如果业务上必须支持中文密码，那就要在压缩时明确设置编码，并确保解压方也用同样编码。但跨平台场景下，这几乎无法保证，所以最稳妥的做法还是限制密码字符集。

5.2 大文件加密时的内存与临时文件陷阱

前面提到过流式读写，但还有一个隐藏问题：SharpZipLib 在 AES 加密时，需要先写入盐值和密码验证值，然后写入加密数据，最后写入 HMAC。这意味着它需要知道整个条目的数据才能计算 HMAC。对于超大文件，SharpZipLib 内部会使用临时文件来缓冲，默认路径是系统临时目录。

如果系统临时目录空间不足，或者权限受限，就会失败。我遇到过一次在容器环境里，临时目录只挂了很小的空间，压缩一个 2GB 的文件时直接报错。解决办法是设置zipStream.TempFile或者通过环境变量指定临时目录。另外，确保临时目录有足够的空间，至少是待压缩文件大小的 1.5 倍。

5.3 解压时的路径穿越与 Zip Slip 防护

Zip Slip 是一种经典的安全漏洞：攻击者构造一个包含../../路径的 Zip 文件，解压时覆盖系统文件。虽然 SharpZipLib 新版本已经做了一些防护，但作为开发者，你不能完全依赖库。前面代码里我加了路径验证，这是必须的。

更严格的做法是：解压前先遍历所有条目，检查每个条目的名称是否包含..或绝对路径，如果有就直接拒绝整个压缩包。这样比逐个条目检查更安全，因为某些攻击可能利用条目之间的依赖关系。

5.4 密码错误时的异常信息泄露

默认情况下，密码错误抛出的异常可能包含敏感信息，比如加密算法细节、盐值等。在生产环境里，这些信息不应该暴露给最终用户。我的做法是：捕获底层异常，记录到日志，然后向上层抛出一个通用的“密码错误或文件损坏”异常。这样既方便排查，又不会泄露细节。

另外，有些场景下需要区分“密码错误”和“文件损坏”。但技术上很难可靠区分，因为两者都表现为解密后 HMAC 校验失败。所以统一提示是合理的，不要试图给用户过于精确的错误信息。

6. 从加密强度到密钥管理：实际项目中的取舍

6.1 密码强度与用户体验的平衡

AES-256 的加密强度足够，但整个方案的安全性最终取决于密码强度。我见过太多项目用123456或者项目名称做密码，这种情况下再强的加密算法也没用。实际项目中，我通常建议：如果是对外分发的文件，密码通过另一个渠道传递（比如短信、即时通讯），不要和文件放在一起。如果是内部系统，密码可以由系统生成，长度至少 12 位，包含大小写字母、数字和符号。

但这里有个矛盾：密码越复杂，用户越容易输错，尤其是需要手动输入的场景。我的经验是，对于需要人工输入的场景，用 4 到 6 个随机单词组成的密码短语，既好记又足够安全。对于程序自动处理的场景，直接用 32 位随机字符串，不需要考虑可读性。

6.2 密钥派生：为什么 PBKDF2 迭代次数很重要

Zip AES 用 PBKDF2 从密码派生加密密钥。PBKDF2 的迭代次数决定了暴力破解的难度。迭代次数越高，每次尝试密码的计算成本越大，攻击者破解速度越慢。但迭代次数太高也会影响正常解压速度。

SharpZipLib 硬编码了 1000 次迭代，这个数字在今天的标准下偏低。OWASP 建议至少 10000 次，对于高安全场景建议 100000 次以上。但问题是，Zip 格式规范里并没有规定迭代次数，不同实现可能不同。如果你用 SharpZipLib 压缩，用 7-Zip 解压，7-Zip 会读取压缩包里记录的迭代次数，所以能正常解开。但如果你自己实现压缩逻辑，就要注意迭代次数的选择。

实际项目中，如果安全要求高，我建议不要依赖 Zip 内置加密，而是用专门的加密库（比如用 AES-GCM 加密整个文件），然后把加密后的文件打包成普通 Zip。这样加密强度和密钥管理都更可控。

6.3 什么时候该放弃 Zip 加密

Zip 加密不是万能的。以下几种情况，我建议考虑其他方案：

第一，需要频繁随机访问压缩包内单个文件。Zip 加密后，每次读取都要解密，如果只是读一个小文件却要解密整个条目，效率很低。这种情况下，用加密的虚拟磁盘或者数据库加密更合适。

第二，需要传输超大文件（几十 GB 以上）。Zip 加密的流式处理虽然可行，但临时文件、内存、时间成本都很高。分卷压缩加加密，或者用专门的传输工具更好。

第三，合规要求极高的场景。某些行业对加密算法、密钥管理、审计日志有严格规定，Zip 加密可能无法满足。这时候需要专业的加密方案，而不是在 Zip 上打补丁。

7. 跨平台解压的兼容性实战验证

7.1 Windows、Linux、macOS 上的实测结果

我用同一段 SharpZipLib 代码生成了 AES-256 加密的 Zip 文件，然后在不同平台上用不同工具解压，结果如下：

这个结果再次印证了前面的结论：AES Zip 的兼容性取决于解压工具，而不是操作系统。7-Zip 是跨平台兼容性最好的选择，几乎在所有平台上都能正常处理 AES Zip。

7.2 用 7-Zip 命令行做批量验证

如果你需要批量验证生成的加密 Zip 是否可用，可以用 7-Zip 的命令行版本做自动化测试：

7z t -p"your-password" output.zip

t是测试命令，它会尝试解压并验证完整性。如果密码错误或文件损坏，会返回非零退出码。你可以把这个命令集成到 CI 流程里，每次生成加密包后自动验证。

在 C# 里也可以调用 7-Zip 命令行，但要注意密码通过命令行传递可能被其他进程看到。更安全的方式是用标准输入传递密码，或者用临时文件。不过对于内部测试，命令行方式足够方便。

7.3 给非技术用户的解压指引

如果你要把 AES 加密的 Zip 发给非技术用户，最好附上一段简单的解压指引。我的做法是：在邮件或消息里写清楚“请用 7-Zip 打开，下载地址是 xxx，安装后右键选择‘提取到当前文件夹’，输入密码即可”。不要假设用户知道什么是 AES，也不要让他们去研究为什么系统自带工具打不开。

如果场景允许，更好的做法是提供一个自解压包（SFX），用户双击后输入密码就能解压，不需要额外安装工具。但 SFX 的制作需要额外工具，而且某些安全软件会拦截 SFX 文件，所以要看具体场景。

8. 一些让代码更稳的工程化建议

8.1 把加密逻辑封装成可测试的组件

不要把加密代码散落在业务逻辑里。我通常会把 Zip 加密解压封装成一个独立的服务类，接口设计成：

public interface IZipCryptoService { void Encrypt(string sourcePath, string outputZip, string password); void Decrypt(string zipFile, string outputDir, string password); Task EncryptAsync(string sourcePath, string outputZip, string password); Task DecryptAsync(string zipFile, string outputDir, string password); }

这样做的目的是方便单元测试和替换实现。比如测试时可以用内存流代替文件流，或者用固定的密码和测试数据验证加密解密的一致性。

8.2 日志记录：记录什么、不记录什么

加密相关的日志要特别小心。绝对不要记录密码，哪怕是加密后的密码也不行。可以记录的信息包括：操作时间、源文件路径、目标文件路径、文件大小、操作结果（成功/失败）、异常类型。如果一定要记录密码相关的信息，最多记录密码长度，不要记录任何字符。

另外，异常堆栈里可能包含敏感信息，记录日志时要过滤。我通常会在日志框架里配置一个过滤器，把包含“password”“key”“salt”等关键词的字段脱敏。

8.3 单元测试：验证加密解密的一致性

最基本的测试是：加密一个已知内容的文件，然后用正确密码解密，验证内容一致；用错误密码解密，验证抛出异常。但还有一些边界情况需要覆盖：

• 空文件加密解密
• 超大文件（可以用生成的大文件测试）
• 包含特殊字符的文件名
• 包含子目录的目录结构
• 密码包含非 ASCII 字符（如果业务支持）
• 并发加密多个文件

这些测试能帮你发现很多隐藏问题。比如空文件在 SharpZipLib 某些版本上会生成无法解压的条目，如果不测试就发现不了。

8.4 版本升级时的兼容性检查

SharpZipLib 从 0.86 到 1.x 有过一些 API 变化，加密相关的行为也有调整。升级版本时，一定要用之前生成的加密包做回归测试，确保新版本能正常解开旧版本生成的文件。我遇到过升级后旧加密包解不开的情况，最后发现是新版本对 AES 条目的解析更严格，旧版本生成的某些字段不符合规范。

建议在项目里固定依赖版本，升级前先在测试环境验证。如果必须升级，保留旧版本的解密能力，或者提供迁移工具。

9. 关于密码传递与安全分发的个人经验

加密做得再好，密码传递环节出问题就前功尽弃。我见过最离谱的做法是把密码写在压缩包的注释里，或者用同一个邮件发送压缩包和密码。这等于没加密。

我的经验是：密码和文件必须走不同的通道。比如文件通过邮件发送，密码通过即时通讯发送；或者文件放在共享目录，密码通过电话告知。对于自动化系统，密码可以存在配置中心或密钥管理服务里，不要硬编码在代码或配置文件里。

另外，如果场景允许，尽量用一次性密码或短期有效的密码。比如系统生成一个随机密码，压缩包发送后 24 小时内有效，过期后密码失效。这需要额外的密码管理逻辑，但对于敏感数据是值得的。

还有一个细节：压缩包的文件名不要包含敏感信息。我见过有人把“客户名单_2024年3月.zip”加密后发送，文件名本身就泄露了信息。文件名应该用无意义的编号，比如“archive_20240315_001.zip”。

最后，如果数据真的非常敏感，Zip 加密可能不是最佳选择。考虑用专门的加密容器格式，或者端到端加密的传输方案。Zip 加密适合的是“中等敏感度、需要方便传输”的场景，不要把它当成万能的安全方案。