Laravel 的 encrypt() 不适合 API 响应加密，应使用 AES 对 JSON payload 对称加密；中间件中须仅替换响应体内容并保留状态码与 Header；前端解密需严格对齐 IV、密钥格式及填充方式；仅对合规强要求或临时凭证字段加密，避免全局冗余加密。
API 返回前对数据加密，用 encrypt() 还是自己写 AES？
直接说结论：Laravel 的 encrypt() 不适合用于 API 响应体加密。它专为加密「存储在 session 或数据库里的敏感值」设计，底层用的是 OpenSSL + 非对称密钥封装（APP_KEY），加密后是带元数据的序列化结构，前端根本没法解。
真正该做的是「对响应 JSON payload 做对称加密」，比如 AES-128-CBC 或 AES-256-GCM。你自己控制密钥、IV、编码格式（base64），前端才能对应解密。
- 别把
encrypt()用在 API 响应里——它返回的是 PHP 序列化+加密混合体，不是标准 AES 密文 - 别用
openssl_encrypt()硬编码写法却不显式指定 IV 和 padding，会导致前端解不出 - 密钥不能写死在代码里，建议从环境变量读取，如
config('app.api_encryption_key')
Laravel 中间件里加密 JSON 响应，怎么避免破坏 HTTP 状态码和 Header？
很多人在中间件里直接 json_encode() 再加密，结果把原始 Response 对象整个覆盖掉，状态码变成 200，Content-Type 变成 text/html，甚至缓存头丢失。
正确做法是只替换响应体内容（$response->getContent()），保留原对象结构。同时手动重设 Content-Type 为 application/json，否则前端 fetch 会解析失败。
- 用
$response->setContent($encryptedJson)替换内容，而不是return response()->json(...) - 加密后记得调
$response->headers->set('Content-Type', 'application/json') - 如果接口原本返回 401/422 等非 200 状态，加密后必须保留——别让中间件偷偷改成 200
前端解密失败？大概率是 Laravel 和 JS 的 AES 实现细节不一致
最常见的坑是：PHP 用 openssl_encrypt($data, 'AES-128-CBC', $key, 0, $iv)，JS 用 CryptoJS 默认模式解，结果一直报“invalid padding”或乱码。根本原因是 CryptoJS 默认 PKCS7 填充，而 PHP 的 openssl_encrypt 在 mode=0 时也用 PKCS7，但 key 和 IV 处理方式不同。
- PHP 侧 key 必须是 raw binary（
hex2bin()或base64_decode()），不是字符串字面量 - IV 必须严格 16 字节（CBC）或 12 字节（GCM），且每次加密随机生成，随密文一起 base64 传给前端
- 前端解密前，要先从响应里取出
iv字段（比如data.iv），再用它和共享密钥解密data.payload
要不要加密所有字段？哪些字段真需要加密？
加密不是银弹。加解密有 CPU 开销，移动端尤其明显；密钥管理不当反而引入新风险；而且加密掩盖不了权限漏洞——如果用户本不该看到某字段，靠加密不如靠 Eloquent Scope 或 API Resource 过滤。
真正值得加密的，只有两类：一是合规强要求字段（如身份证号、银行卡号），二是业务上「即使拿到响应也无法直接使用」的临时凭证（如预签名上传 URL）。普通列表数据、状态字段、时间戳，没必要加密。
- 优先用 Laravel API Resource 的
toArray()控制字段输出，比加密更轻量、更安全 - 如果字段本身已脱敏（如
***1234），再加密纯属冗余 - 别为了“看起来安全”而加密整个
data对象——攻击者截获密文，只要拿到一次密钥，全量解密
加密逻辑越靠近业务边界越可控，比如在 Resource 的 toArray() 里对特定字段单独加密，而不是全局中间件一刀切。密钥轮换、算法升级、错误日志埋点，这些事在集中式加密里都容易被忽略。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
