直接原因是web服务器运行用户（如www-data）无密钥文件读取权限；应改密钥属组为web用户组、设640权限，目录设750，用is_readable()和openssl_error_string()排查，并避免chmod 777。
PHP读取密钥文件时提示“Permission denied”
直接原因是Web服务器（如Apache或Nginx）运行的用户（通常是www-data、apache或nginx）没有读取密钥文件的权限，而非PHP本身权限不足。PHP只是替这个用户执行IO操作。
- 用
ls -l /path/to/your/private.key确认文件属主和权限，常见错误是密钥属主为root且权限为600，导致Web用户完全无法访问 - 不要用
chmod 777硬解——这会暴露私钥，违反安全底线 - 推荐做法：把密钥文件属组改为Web用户组（如
chgrp www-data /path/to/private.key），再设权限为640（即rw-r-----） - 确保密钥所在目录也允许Web用户进入：目录至少需
rx权限（如750），否则open()会因“no such file or directory”失败（实际是权限拒绝）
openssl_pkey_get_private() 返回 false 但无错误信息
这是OpenSSL扩展静默失败的典型表现，根本原因常是文件路径错误或权限不到位，而不是密码不对或格式异常。
- 先用
file_exists()和is_readable()双检：即使file_exists()返回true，is_readable()也可能返回false（权限不足时） - 调用
openssl_error_string()在openssl_pkey_get_private()之后立即检查，它可能返回类似error:0200100D:system library:fopen:Permission denied - 注意路径是否为绝对路径——相对路径在CLI和Web环境下解析基准不同，建议统一用
__DIR__ . '/keys/private.key' - 如果密钥带密码，确保传入的密码字符串不带BOM、换行或多余空格（可用
trim()预处理）
使用sodium_crypto_sign_keypair()等现代函数时仍报错
Libsodium不依赖文件IO，但它生成的密钥对若保存到磁盘，后续读取仍走系统权限校验。而且某些环境（如共享主机）可能禁用sodium扩展或限制其熵源。
- 先确认扩展已启用：
extension=sodium在php.ini中未被注释，且extension_loaded('sodium')返回true - 生成密钥后若写入文件，仍要按前述规则设置文件权限；若仅内存使用，则无需文件权限，但要注意Web进程重启后密钥丢失
- 避免用
file_put_contents()直接存二进制密钥——必须用FILE_BINARY标志，否则Windows下可能损坏 - 在容器或SELinux环境，还需检查上下文标签（如
ls -Z）或sebool策略（如httpd_read_user_content是否开启）
CI/CD部署后密钥权限突然失效
自动化部署脚本常以root身份运行，导致密钥文件属主变成root，而Web服务仍以普通用户运行，权限链就此断裂。
立即学习“PHP免费学习笔记（深入）”；
- 部署脚本末尾务必加修复命令，例如：
chown :www-data /app/keys/* && chmod 640 /app/keys/*.key - 避免在
post-deploy钩子中用sudo -u www-data php …临时绕过——这治标不治本，且可能引入执行上下文混乱 - Git仓库中严禁提交私钥；用
.env或KMS注入密钥内容，再由PHP写入受控目录并设权 - 测试环节加入权限断言：
assert(is_readable($keyPath) && posix_getpwuid(fileowner($keyPath))['name'] !== 'root');
最易被忽略的是目录执行权限和SELinux/AppArmor这类强制访问控制——它们会让is_readable()返回true，但实际fopen()仍失败，此时必须查dmesg或审计日志。
