ThinkPHP接口数据加密失败主因是加解密与框架生命周期脱节：需确保加密在JsonResponse前执行、解密在请求解析前完成，且密钥/IV、算法参数前后端严格一致，并排除环境兼容性问题。
ThinkPHP接口数据加密失败，通常不是算法本身出错，而是加解密环节与框架生命周期脱节。关键要确认：加密是否发生在响应真正发出前、解密是否在控制器读取请求前完成、密钥和IV是否全程一致。
响应加密没生效？检查中间件执行时机和优先级
很多加密失效，是因为中间件在框架默认的 JsonResponse 之后才执行，导致 JSON 已被序列化并加上了 Content-Type: application/json，此时再改 content 就只是“套壳”，前端收到的是明文 JSON 包着一串乱码。
- 确保中间件注册顺序排在 think\middleware\JsonResponse 之前（在 app/middleware.php 中靠前声明，或显式设置 priority < 10）
- 不要用
$response->getContent()后再json_encode()—— 这会覆盖原始状态码和 header - 正确做法是：读原始内容 → AES 加密 →
$response->content($encrypted)→ 手动重设Content-Type: application/octet-stream和Content-Length - 加解密必须基于同一组 key + iv，建议从配置或环境变量加载，避免硬编码
前端收不到密文，或解密后为空？重点查请求解密位置
$_POST 为空、$this->request->post() 返回空数组，90% 是因为解密没在框架解析请求体前完成。ThinkPHP 的 input() 系统直接读 php://input，而加密请求体是 base64 密文，无法被自动识别为表单数据。
- 解密逻辑必须放在中间件 handle 方法中，且早于任何控制器执行
- 不要尝试重写 php://input 流（易出错），推荐用
$request->merge(['post' => $decrypted])注入解密后的数组 - 务必校验加密标识，例如检查 Header 是否含
X-Encrypted: aes-128-cbc，避免对普通请求误解 - 确认密钥、iv、padding 方式（如 PKCS7）、加密模式（CBC/ECB）前后端完全一致
环境或配置引发的隐性失败
有些“加密失败”实际是环境不兼容导致的静默异常，比如 openssl 扩展缺失、mbstring.func_overload = 2 干扰字符串长度计算、或 PHP 版本差异造成 openssl_encrypt 行为变化。
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -m | grep openssl确认扩展已启用 - 检查
mbstring.func_overload必须为 0（php -i | grep func_overload） - 开发与生产环境 PHP 版本需严格一致，特别是 8.0+ 对 openssl 参数校验更严
- 密钥和 iv 长度必须合规：AES-128 要求 key=16 字节、iv=16 字节；用
strlen()而非mb_strlen()校验
国密适配场景下的特殊注意点
若使用 GMSSL 或 SM4 替代 AES，不能直接套用 openssl_encrypt/decrypt。SM4 需通过 gmssl 命令行或扩展调用，且 CBC 模式下 iv 处理、padding 方式（如 SM4 常用 PKCS5）与 AES 不完全等价。
- 确认已安装支持国密的 PHP 扩展（如 php-gmssl），而非仅依赖 OpenSSL
- SM4 加密后 base64 编码结果长度应为 16 字节倍数 + padding，否则说明 iv 或填充逻辑有误
- 前端 JS 解密库（如 sm-crypto）版本需与后端一致，特别注意 v1.x 与 v2.x 在 iv 传参方式上的差异
- SM2 签名验签场景中，私钥格式（PEM/PKCS#8）、公钥提取方式、摘要算法（SM3）必须前后端对齐
