Composer本身不提供加密能力，它只是依赖管理工具；所谓“基于Composer库”实指选用Packagist上可install的加密类库（如paragonie/sodium_compat），在控制器或中间件中手动调用sodium_crypto_box_seal()等函数实现请求链路加密，严禁在autoload中加载密钥或执行加密逻辑。
PHP 应用中如何用 Composer 包做运行时请求链路加密？
直接说结论：Composer 本身不提供加密能力，它只是依赖管理工具；所谓“基于 Composer 库”，实际是指选用已发布在 Packagist 上、可被 composer require 安装的加密/签名类库（如 defuse/php-encryption、firebase/php-jwt 或 paragonie/sodium_compat），在业务逻辑层手动集成。
关键点在于：不能把加密逻辑塞进 Composer 的 autoload 或插件钩子中——那会污染依赖加载流程，且无法感知 HTTP 请求上下文。必须在控制器、中间件或服务类里显式调用加密函数。
- 推荐优先用
sodium_crypto_box_seal()（libsodium 封装）做端到端密文传输，它自动处理密钥交换与前向保密，比手搓 AES-GCM 更安全 - 若需兼容 PHP 7.2+ 且无 ext-sodium，可用
sodium_compat替代，但注意其纯 PHP 实现比原生慢 3–5 倍，高频链路慎用 - 避免用
mcrypt_encrypt()（已废弃）或未加 nonce 的openssl_encrypt()，这类写法在 PHP 7.4+ 会报Deprecated: Function mcrypt_encrypt() is deprecated
如何给 API 响应体动态加签并验证防篡改？
签名不是加密，目标是验证数据完整性与来源可信度。常见错误是只对响应 body 做 MD5/SHA1——这毫无安全性，攻击者可重放整个响应包。真需求是「每个响应带有时效性、绑定请求上下文的签名」。
实操建议用 HMAC-SHA256，密钥由服务端安全存储（如环境变量 API_SIGNING_KEY），签名字段必须包含：timestamp（秒级时间戳）、nonce（单次随机字符串）、request_id（或 trace_id）、body_hash（响应 JSON 的 SHA256）。
立即学习“PHP免费学习笔记（深入）”；
- 签名原文拼接顺序要固定，例如：
$payload = $timestamp . '|' . $nonce . '|' . $request_id . '|' . $body_hash - 签名结果通过 HTTP Header 返回，如
X-Signature: hmac-sha256=xxx，客户端校验时必须重新计算并比对 - 服务端需缓存最近 60 秒内的
nonce，防止重放；若用 Redis，key 可设为nonce:{client_ip}:{timestamp} - 别把签名逻辑写在视图层（如 Twig 模板），会导致无法统一拦截/审计；应放在响应发送前的中间件或 Response 对象构造处
为什么 vendor/autoload.php 不该参与加解密密钥加载？
因为 vendor/autoload.php 是 Composer 自动生成的类加载入口，它的职责仅限于注册 PSR-4/PSR-0 映射。一旦在里面读取 .env、调用 openssl_pkey_get_private() 或初始化加密器实例，会导致两个严重问题：
- 所有 CLI 命令（如
php artisan tinker或自定义bin/console）启动时都会强制执行密钥加载，哪怕命令跟加密完全无关 - Web 服务器（如 Apache mod_php）下，每次请求都重复执行 autoload 文件，密钥解析、证书读取变成高频 IO，压测时易成瓶颈
- 更隐蔽的问题：某些容器化部署（如 PHP-FPM + OpCache）会缓存 autoload 文件的 opcache，但密钥文件更新后 autoload 不感知，导致密钥热更新失效
正确做法是把密钥加载延迟到第一次加密/解密调用时（lazy init），或在框架生命周期早期（如 Laravel 的 AppServiceProvider::boot()）集中初始化加密服务实例。
PHP-FPM 环境下 AES-GCM 解密失败的典型报错与修复
常见现象是本地开发正常，上线后出现 openssl_decrypt(): Failed to decrypt data 或空响应，尤其在高并发时概率上升。根本原因不是算法本身，而是 OpenSSL 扩展在多进程下的状态残留或内存越界。
- 确认是否用了非标准 IV 长度：AES-GCM 要求 IV（nonce）严格为 12 字节，用
random_bytes(12)，而非md5(time())这类 16 字节输出 - 检查是否复用 IV：同一个密钥下，IV 绝对不可重复，否则 GCM 模式会彻底崩溃；生产环境建议用数据库序列号或 Redis INCR 生成单调递增 nonce
- PHP 8.1+ 用户注意：
openssl_encrypt()默认返回false而非空字符串，错误处理必须显式判断=== false，不能只用empty() - 若使用
ext-sodium，优先选sodium_crypto_aead_xchacha20poly1305_ietf_encrypt()替代 GCM——它对 nonce 复用容忍度更高，且无需手动管理 tag 长度
最易被忽略的是 OpenSSL 版本差异：CentOS 7 自带 OpenSSL 1.0.2，不支持 AEAD 模式下的完整 GCM，必须升级到 1.1.1+；而 Alpine Linux 的 musl libc 下，某些 OpenSSL 补丁行为也和 glibc 不一致。
