PHP无法真正加密文件夹，只能逐文件加解密；推荐将敏感文件移出Webroot并用PHP代理访问，而非依赖ZipArchive伪加密或自行实现易出错的端到端加密。
PHP 本身不提供直接加密整个文件夹的功能，也没有内置的“文件夹加密”API。所谓“PHP 加密文件夹”，实际是通过 PHP 脚本控制对文件内容进行加解密操作，再配合权限、路由隔离等手段模拟保护效果。真要靠 PHP 实现端到端加密，必须自己处理每个文件的读取 → 解密 → 输出（或写入 → 加密），且密钥管理、IV 安全、文件元信息（如扩展名、大小）保留等问题极易出错。
PHP 中用 openssl_encrypt 加密单个文件内容
这是最常用也相对可控的方式：逐个读取文件，用对称加密（如 AES-256-CBC）加密其二进制内容，保存为新文件或覆盖原文件（谨慎！）。
关键点：
-
openssl_encrypt只处理字符串，需用file_get_contents读取原始文件（注意内存限制，大文件要用流式分块） - 必须显式生成并安全保存
$iv（初始化向量），且每次加密都该不同；常把$iv前缀到密文一起存储 - 密钥不能硬编码，建议从环境变量或独立配置文件加载，避免被 Web 目录直接访问
- 加密后建议更改文件扩展名（如
.enc）或移出 Webroot，否则仍可能被直接下载（未加密前）
示例片段（简化版）：
立即学习“PHP免费学习笔记（深入）”；
$key = hex2bin(getenv('APP_ENCRYPTION_KEY')); // 32 字节 AES-256 密钥
$ivlen = openssl_cipher_iv_length($cipher = 'AES-256-CBC');
$iv = openssl_random_pseudo_bytes($ivlen);
$data = file_get_contents('/path/to/original.jpg');
$encrypted = openssl_encrypt($data, $cipher, $key, OPENSSL_RAW_DATA, $iv);
file_put_contents('/path/to/original.jpg.enc', $iv . $encrypted); // IV + 密文
为什么不能用 ziparchive + 密码保护当“加密文件夹”
PHP 的 ZipArchive 类支持设置密码（setPassword），但该功能仅在部分扩展编译版本中启用，且PHP 官方明确说明：此密码不提供真实加密，仅用于 ZIP 客户端提示（即“伪加密”）。实际 ZIP 内容仍以明文存储，用 7z 或 binwalk 一拖就出。
常见误判现象：
- Windows 资源管理器打开带密码 ZIP 时弹窗要求输入 —— 这只是 ZIP 格式层的弱校验
-
unzip -P wrongpass archive.zip报错，但7z x archive.zip可直接解出所有文件 - PHP 中调用
$zip->setPassword('123')后仍能用其他工具无密提取
结论：别指望 ZipArchive 实现安全保护，它只适合做轻量级访问提示。
Web 环境下“隐藏文件夹”的可行替代方案
如果目标是防止用户通过 URL 直接访问敏感文件（如上传目录、配置备份），真正的解决路径不是加密，而是隔离访问层：
- 将敏感文件存放在 Webroot 之外（如
/var/www/private/uploads/），确保 Apache/Nginx 无法直接映射到该路径 - 用 PHP 脚本做代理下载：
download.php?file=report.pdf，脚本中校验登录态、权限、文件白名单，再用readfile()输出（不暴露真实路径） - 在 Nginx 中禁用脚本执行和目录浏览：
location ~ ^/uploads/.*\.(php|sh|pl)$ { return 403; } - 配合
.htaccess（Apache）或 Nginxdeny all封锁对敏感目录的 HTTP 访问
这种方案性能好、兼容性强，且规避了加密/解密的 CPU 开销与实现风险。
真正需要端到端加密时，务必考虑密钥生命周期管理——比如用户登录后动态派生密钥、服务端 KMS 托管、或前端 JS 加密后上传（此时 PHP 只作透传）。单纯用 PHP 在服务端循环加密一堆文件，既慢又容易因一处疏漏（如 IV 复用、错误的填充模式）导致整体失效。
