base64_encode默认按RFC 2045在每76字符后插入\r\n换行，适配邮件传输；现代场景需用str_replace(['\r\n', '\r', '\n'], '', base64_encode($data))清除所有换行。
base64_encode 默认会加换行，不是 bug 是设计
PHP 的 base64_encode 在输出超过 76 字符时，**自动插入 \r\n 换行**（符合 MIME RFC 2045 规范），目的是适配邮件等老式文本传输通道。但现代 API、JSON、URL 或数据库字段根本不需要它——反而会导致解码失败或数据截断。
最简单可靠的去换行方式：用 str_replace 批量干掉
别试图改 base64_encode 行为（它没提供禁用换行的参数），直接后处理最稳：
-
str_replace(["\r\n", "\r", "\n"], '', base64_encode($data))—— 显式清除所有换行组合，顺序不能错（先\r\n，再单个） - 不要用
trim：它只清首尾，中间的换行照样存在 - 避免正则：除非你要同时压缩空格，否则
str_replace更快、无 PCRE 开销、不踩 UTF-8 修饰符坑
从源头避免换行：chunk_split 是罪魁祸首？
如果你发现 base64 字符串里有换行，但确认没手动调用 chunk_split，那大概率是用了某些封装类或框架——它们可能在 base64_encode 后悄悄套了一层 chunk_split($encoded, 76, "\r\n")。检查你调用链里有没有类似逻辑，尤其是旧版邮件工具类或 JWT 签名辅助函数。
如果确实需要自己分块（比如构造 MIME 头），记得：分块是编码后操作，不是编码的一部分；传输前必须再清理一次换行。
立即学习“PHP免费学习笔记（深入）”；
接收端要防“伪成功”解码
前端或第三方服务传来的 base64 字符串若含换行，base64_decode($input, false) 默认会跳过非法字符继续解，结果看似成功，实际解出乱码。务必：
- 接收时先用
str_replace(["\r", "\n", "\t", " ", "\0"], '', $input)清理所有干扰符 - 校验长度是否为 4 的倍数，不足就补
=（base64_decode不自动补） - 关键场景用
$strict = true：遇到非法字符直接返回false，别让错误静默蔓延
换行符看不见，但一旦混进 base64 字符串，解码结果就不可信。与其猜来源、修配置，不如在 encode 后立刻 strip，decode 前强制 normalize——这是最可控的防线。
