PHP加密必然增加CPU开销，影响程度取决于算法与数据量：password_hash（bcrypt/argon2id）最慢，单次100–200ms；openssl_encrypt相对高效，但密钥和模式不当易出问题。
PHP加密操作确实会拖慢响应，但程度取决于算法和数据量
直接说结论：所有加密都会增加CPU开销，但影响是否明显，要看你用的是 openssl_encrypt 还是 password_hash，加密的是 1KB 的 token 还是 10MB 的文件。PHP 本身不缓存加密结果，每次调用都实打实计算。
password_hash 用 bcrypt 或 argon2id 时延迟最明显
这类密码哈希设计目标就是“故意慢”，防暴力破解。默认 cost=12 的 bcrypt 在普通服务器上单次耗时约 100–200ms；argon2id 更高，尤其内存参数设大了之后容易触发 swap。
- 别在登录接口里对同一密码反复调用
password_verify—— 比如先查用户再验证，中间还做了其他 DB 查询，应确保只验一次 - 避免把
password_hash放进循环里处理批量用户数据，改用批处理+异步加盐 -
password_needs_rehash调用成本低，但别在每次请求都无条件检查——只在用户登录成功且哈希参数过时时才重算
openssl_encrypt 性能尚可，但模式和密钥管理不当会翻车
AES-128-CBC 和 AES-256-GCM 在现代 CPU 上单次加密几 KB 数据通常
- 每次生成新
openssl_random_pseudo_bytesIV 并拼接——看似安全，但频繁系统调用和内存拷贝会累积延迟 - 错误地把加密逻辑写在 Laravel 的 Model
setAttribute中，导致 Eloquent 批量赋值时重复执行数十次 - 用
OPENSSL_ZERO_PADDING却没手动补位，解密时抛error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt，这种错误恢复成本远高于加密本身
真正伤性能的往往不是加密函数，而是滥用场景
比如在 Redis 缓存键上对用户 ID 做 base64_encode(hash_hmac('sha256', $id, $key))，看似“加密”，实则纯属徒劳：HMAC 不是加密，base64 更不是，反而多两次函数调用和字符串分配。又比如用 mcrypt_encrypt（已废弃）还在跑 PHP 7.1+，不仅慢，还会触发警告并降级到兼容模式。
立即学习“PHP免费学习笔记（深入）”；
加密不该是“以防万一”的装饰动作。该加密的（如数据库敏感字段、API 签名）要选对算法和参数；不该加密的（如 URL 中的分页偏移量），用简单混淆或令牌映射更高效。最容易被忽略的是：加解密逻辑一旦进入高频路径（如日志记录、审计钩子、中间件），哪怕单次只慢 0.5ms，QPS 上千时就变成明显的 P99 毛刺。
