使用openssl_encrypt加密邮件正文前需确认算法、模式、填充、IV、密钥长度完全对齐；密钥须经hash('sha256', $key, true)截取为16或32字节；IV必须随机生成并随密文传输；选项设OPENSSL_RAW_DATA；Content-Type等需同步更新。
PHP用openssl_encrypt加密邮件正文前要确认什么
直接套用openssl_encrypt容易发出去解不开，核心是加解密两端必须完全对齐：算法、模式、填充、IV、密钥长度。PHP默认的OPENSSL_CIPHER_AES_128_CBC要求密钥正好16字节，但很多人传入字符串没做hash('sha256', $key, true)截取，结果加密成功、解密报error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt。
- 必须显式指定
$options = OPENSSL_RAW_DATA，否则base64编码会干扰后续拼接 - IV必须随机生成（
random_bytes(16)），且和密文一起传给接收方——不能硬编码或省略 - 别用
mcrypt（已废弃）或openssl_seal（只支持公钥加密，不适合单密钥场景）
SMTP发送时怎么把加密后的内容塞进邮件结构
加密的是原始正文/附件数据，不是整个MIME包。直接替换$mail->Body或$mail->AltBody就行，但要注意Content-Type和编码声明必须同步改，否则邮箱客户端可能当乱码处理。
- 正文加密后，设
$mail->Body = $encrypted_text，同时把Content-Type改成text/plain; charset="us-ascii"（避免UTF-8解码冲突） - 附件加密：先读
file_get_contents($path)，加密后用$mail->addStringAttachment($ciphertext, 'data.enc', 'base64', 'application/octet-stream') - 千万别对整个
$mail->msgHTML()结果再加密——那会破坏MIME边界，收件方根本解析不了
接收方用PHP解密时最常漏掉的三件事
发件人觉得“我加密了”，收件人却解不出，90%卡在IV传递、密钥还原、填充补全这三个环节。尤其是IV，很多人以为存在session里或写死在代码中，实际必须随邮件正文/附件一同传输。
- IV必须和密文一起到达：建议把
base64_encode($iv . $ciphertext)作为正文，接收方substr($data, 0, 16)取IV，substr($data, 16)取密文 - 密钥不能明文写死，也不能用
md5($password)——要用hash_hmac('sha256', $password, $salt, true)生成32字节密钥适配AES-256 - 解密后手动去除PKCS#7填充：
rtrim($decrypted, "\0..\x10")，否则末尾多出不可见字符
为什么不用PGP而选对称加密
PGP（如gnupg扩展）理论上更标准，但实际落地时依赖GPG密钥环、信任链、密钥服务器，内部系统间通信反而增加运维负担。对称加密只要双方约好密码和IV传输方式，就能跑通，适合已知可信接收方的场景（比如CRM发加密客户数据给财务系统）。
立即学习“PHP免费学习笔记（深入）”；
-
gnupg在Docker或共享主机上常因权限/路径问题初始化失败，错误信息是Could not start GnuPG: file not found - 如果必须用非对称，优先选
openssl_public_encrypt+openssl_private_decrypt，别碰openssl_seal——它不返回公钥，接收方没法验签 - 所有密钥、IV、盐值都别进Git，用环境变量或配置中心加载，
$_ENV['MAIL_ENCRYPTION_KEY']比写死'my-secret-123'安全得多
加密本身不难，难的是密钥怎么安全交换、IV怎么可靠传递、解密后怎么干净还原原始数据——这些细节没对齐，发一百封都是废的。
