Base64编码末尾的=是标准填充，用于使输出长度为4的倍数；非bug，强行去除会导致base64_decode()失败，URL场景需替换为-和_并还原。
base64_encode() 为什么编码后字符串末尾有 =？
这是 Base64 标准要求的填充（padding），不是 bug。当原始数据长度不能被 3 整除时，base64_encode() 会自动补 = 使输出长度为 4 的倍数——比如 base64_encode("a") 返回 YQ==，因为单字节需补两个 =。
常见误操作：把带 = 的结果直接拼进 URL 或文件名，导致 404 或解析失败。
- URL 场景下建议用
strtr($encoded, '+/=', '-_')做 URL 安全替换（再配合base64_decode(strtr($safe, '-_', '+/'))还原） - 存数据库或日志时保留原样，
=不影响解码，强行去掉会导致base64_decode()返回false - PHP 7.3+ 可用
base64_encode($data, true)启用“无填充”模式，但注意这不兼容老版本 PHP 或其他语言默认实现
base64_encode() 处理二进制文件（如图片）总出错？
根本原因不是函数本身，而是你传进去的压根就不是原始二进制内容。最常踩的坑是：用 file_get_contents() 读取文件时，文件路径错误、权限不足、或文件被文本编辑器“悄悄转码”过（比如 Windows 记事本保存 PNG 为 ANSI）。
实操检查点：
立即学习“PHP免费学习笔记（深入）”；
- 确认路径存在且可读：
file_exists($path) && is_readable($path) - 用
bindec(decbin(filesize($path))) === filesize($path)快速判断是否被截断（非必需，但能抓出某些 FTP 二进制模式未开启的问题） - 别用
echo直接输出编码结果来“验证”，浏览器会把 Base64 当文本渲染；改用var_dump()或写入临时文件再用cat查看前 20 字符 - 大文件（>2MB）慎用：
base64_encode()会把内存占用翻 4/3 倍，考虑流式处理或前端直传
base64_decode() 返回 false 却不报错？
这是 PHP 的设计行为：base64_decode() 遇到非法字符、长度不对、或填充错误时静默返回 false，而不是抛异常。你如果没检查返回值，后续操作（比如 unserialize()）就会崩得莫名其妙。
安全用法只有这一种：
- 必须先判断返回值：
$decoded = base64_decode($input); if ($decoded === false) { /* 处理错误 */ } - 不要依赖
strlen($input) % 4 === 0来预检——Base64 允许忽略末尾空格和换行，但base64_decode()对中间非法字符极其敏感 - 用户输入的 Base64 最好先过滤掉空白：
base64_decode(str_replace(["\r", "\n", " ", "\t"], "", $input)) - 如果来源是 JSON，注意 JavaScript 的
btoa()不支持 Unicode 字符串，PHP 解码前得先utf8_encode()（反之亦然）
base64_encode() 和加密、签名完全不是一回事
新手最容易混淆的点：以为 Base64 是“加密”，其实它只是编码——没有密钥、不可逆（指无法从算法上反推，但实际等于明文暴露）。用它来“保护密码”或“隐藏 API key”毫无意义。
真实场景该怎么做：
- 传输小段敏感数据（如 session ID）时，Base64 只用于避免特殊字符破坏 HTTP 头或 URL，必须搭配 HTTPS
- 配置文件里存密钥？用
openssl_encrypt()+ AES，别碰base64_encode() - 想防篡改？加
hash_hmac('sha256', $data, $key)，再把 hash 和 data 一起 Base64 编码，但验证逻辑必须在服务端做 - PHP 8.1+ 的
base64_encode($data, true)虽省去=，但依然不解决安全性问题
真正难的从来不是怎么调用 base64_encode()，而是分清它在哪能用、在哪一用就露馅。
