PHP不应直接管理密钥，必须依赖外部可信边界：生产环境用KMS或本地私钥+独立守护进程，开发环境用内存临时密钥；杜绝硬编码、环境变量泄露及.git提交密钥。
PHP 本身不提供安全的密钥存储机制，所有“把密钥写进代码/配置文件”的做法在服务器被入侵时都会直接泄露——真正的密钥管理必须依赖外部可信边界。
密钥不能硬编码在 PHP 文件里
哪怕用 define('ENCRYPTION_KEY', '...') 或 $key = getenv('APP_KEY')，只要 PHP 文件可读、环境变量可被 phpinfo() 或进程环境泄露，密钥就等于裸奔。
- Web 服务器（如 Apache/Nginx）若配置不当，可能直接返回
.env或config.php源码 -
getenv()读取的环境变量在 CLI 模式下容易被ps aux或/proc/$PID/environ窃取 - Docker 容器中通过
ENV指令注入密钥，镜像层会残留明文，docker history可见
优先使用操作系统级密钥服务（Linux）
Linux 的 systemd 提供了 systemd-secrets（需 v249+），但更通用且稳定的做法是绑定内核密钥环（kernel keyring）或使用 libsecret + D-Bus。不过对 PHP 来说，最务实的是利用 openssl_seal() + 外部密钥代理：
- 用
openssl_pkey_new()生成 RSA 密钥对，私钥存于/etc/ssl/private/app-key.pem，权限设为600，属主为 Web 服务器运行用户（如www-data） - PHP 中只加载公钥：
openssl_pkey_get_public('file:///etc/ssl/certs/app-key.pub')，加密操作用公钥；解密由独立守护进程（非 PHP）持有私钥完成 - 拒绝任何 PHP 进程直接读取私钥文件——哪怕只是
fopen('/etc/ssl/private/...', 'r')都是风险点
云环境必须走 KMS（如 AWS KMS / HashiCorp Vault）
本地没条件建可信边界？那就别自己管密钥。PHP 应该只做「加密请求」和「解密响应」，密钥生命周期全托管给 KMS：
立即学习“PHP免费学习笔记（深入）”；
- AWS：用
aws/aws-sdk-php调用$kmsClient->encrypt(['KeyId' => 'alias/my-app-key', 'Plaintext' => $data])，返回密文；解密同理，PHP 从不接触原始密钥 - Vault：启用 Transit engine，PHP 通过
curl向/v1/transit/encrypt/my-keyPOST 数据，Vault 返回ciphertext字段；解密也只传密文过去 - 注意：KMS 调用必须走 TLS + IAM 角色（EC2）或 Token（Vault），绝不用长期 AccessKey 写死在 PHP 里
开发环境怎么临时处理？
本地调试不能真上 KMS，但也不能妥协安全底线：
- 用
libsodium的sodium_crypto_secretbox()+ 随机random_bytes(32)生成一次性的会话密钥，仅内存存活，不用持久化 - 测试密钥可存在
/dev/shm/（tmpfs 内存文件系统），PHP 用file_get_contents('/dev/shm/app-test-key')读取，重启即清空 - 禁止
.env提交到 Git：确保.gitignore包含.env和*key*类通配，CI 流水线用 secret 注入而非文件挂载
密钥管理最难的不是“怎么存”，而是“谁有权限读、在什么上下文里读、读完是否还在内存里”。PHP 进程模型决定了它天然不适合长期持密——一旦接受这点，方案就清晰了：让密钥远离 PHP 进程空间，哪怕多一次网络调用、多一个守护进程，也比把 $key 变量留在 var_dump($GLOBALS) 里强。
