PHP表单数据本身不加密，所谓“加密”分前端提交加密和后端存储加密：前者在非HTTPS下临时防窥探但密钥易暴露，后者才是推荐做法，即服务端接收明文后加密存储敏感字段，并注意IV随机、密钥安全管理和字段长度预留。
PHP 表单本身不加密数据，$_POST 或 $_GET 传过来的值默认是明文；所谓“表单数据加密”，实际是指在客户端加密后提交，或在服务端对敏感字段做加密存储——但二者目的、风险点和实现方式完全不同，不能混用。
前端用 JavaScript 加密再提交（如 AES）
适用于防止中间人窥探（比如非 HTTPS 环境下临时补救），但不可靠：密钥必然暴露在前端，攻击者可直接复用加密逻辑伪造请求。
- 必须用
AES-GCM或AES-CBC+ 安全 IV，禁用 ECB 模式 - 密钥不能硬编码在 JS 里，至少应由服务端动态下发（如登录后返回一次性密钥）
- PHP 后端需用
openssl_decrypt()解密，注意填充、编码、IV 传递方式（通常 Base64 编码后随数据一起 POST） - 若未配 HTTPS，加密意义有限——攻击者可篡改整个表单行为，比如绕过 JS 加密直接发原始数据
服务端对敏感字段加密存储（推荐做法）
这才是真正有意义的“加密”：用户提交明文，PHP 接收后用密钥加密再存数据库，读取时解密。典型场景是加密手机号、身份证号等 PII 数据。
- 用
openssl_encrypt()+openssl_decrypt()，算法选AES-256-CBC，必须使用随机IV（每次加密不同），且把IV和密文一起存储（如拼接后 Base64） - 密钥绝不能写死在代码里，应从环境变量或密钥管理服务（如 HashiCorp Vault）加载
- 避免用
mcrypt（已废弃）或base64_encode()这类编码冒充加密 - 注意字段长度：AES 加密后数据会变长，数据库字段要预留足够空间（如
VARCHAR(255)不够存加密后的手机号）
为什么不能用 $_POST 数据直接加密后当“凭证”校验？
常见错误：把整个 $_POST 序列化后加密，作为隐藏字段防篡改。这本质是自建签名逻辑，极易出错。
立即学习“PHP免费学习笔记（深入）”；
- PHP 的
serialize()对数组顺序敏感，ksort()漏掉就导致验签失败 - 没有绑定时间戳或一次性 nonce，加密结果可被重放
- 不如直接用
hash_hmac('sha256', $data, $secret)生成签名，服务端重新计算比对 - 若真需要加密+认证，用
openssl_encrypt()的AES-GCM模式，它自带认证标签（auth tag）
最常被忽略的一点：加密解决不了业务逻辑漏洞。比如密码字段加密存储了，但登录接口仍允许暴力试错，或者加密密钥权限配置错误导致被 Web 目录直接下载——加密只是纵深防御中的一环，不是银弹。
