Base64编码是JSON中安全传输二进制数据的唯一稳妥方式，需配合file_name、content_type等独立字段，并避免大文件直塞JSON；超几MB应改用multipart/form-data。
PHP json_encode() 会直接炸掉二进制数据
它根本不管你是图片头还是 ZIP 签名，遇到 \x00、\xff 或非 UTF-8 字节就静默截断或报 JSON_ERROR_UTF8。这不是 bug，是设计如此——JSON 标准只认 Unicode 字符串。
- 别试图用
mb_convert_encoding($bin, 'UTF-8', 'binary')强转，乱码或崩溃概率极高 - 真实场景里，
file_get_contents('avatar.jpg')这种原始字节流，必须绕过json_encode()的直译逻辑 - 如果你在 API 返回里硬塞 raw binary，前端
JSON.parse()会直接抛SyntaxError: Unexpected token（后面跟着不可见字符）
用 Base64 编码是唯一稳妥的传输方式
Base64 把任意字节映射成 64 个可打印 ASCII 字符，彻底避开编码冲突。虽然体积膨胀约 33%，但换来的是确定性——PHP 和 JS 都原生支持，无依赖、无兼容问题。
- PHP 端：用
base64_encode(file_get_contents($path))，不是json_encode()包二进制 - JS 端：
atob()解码后需转成Uint8Array才能构造Blob或File - 别省事用
data:image/jpeg;base64,...直接塞 HTML —— 大文件会让 DOM 膨胀严重，内存飙升 - 如果接口要传多个文件，把每个文件分别 base64 后放进数组字段，别拼接
注意 MIME 类型和文件名不能丢
Base64 只解决“内容怎么传”，但接收方需要知道这是 PNG 还是 PDF，要不要下载，保存时叫什么名。这些信息必须作为独立字段传，不能藏在 base64 字符串里。
- 结构建议长这样：
{"file_data": "base64string...", "file_name": "report.pdf", "content_type": "application/pdf"} -
content_type别硬写image/*，用finfo_file($finfo, $path, FILEINFO_MIME_TYPE)动态获取更可靠 - 前端拿到
file_name后，用decodeURIComponent(escape())处理中文名，否则可能乱码 - 别把
file_name当作唯一信任来源——服务端必须校验扩展名和实际二进制签名（比如用exif_imagetype()）
大文件别走 JSON 主体，改用 multipart/form-data
超过几 MB 就别 base64 了。Base64 + JSON 意味着服务端要一次性读完整个 base64 字符串、解码、再处理，内存占用翻倍，超时风险陡增。
立即学习“PHP免费学习笔记（深入）”；
- 上传场景：用
fetch+FormData，后端用$_FILES接收，比 JSON 安全高效得多 - 下载场景：不要返回含 base64 的 JSON，改用
Content-Disposition: attachment直出二进制流 - 真要 JSON 里带大文件（比如离线包），至少分块 base64 并加
chunk_index/total_chunks字段，前端拼接
post_max_size）、前端解码时的内存压力、以及永远别相信客户端传来的 content_type 或扩展名。 
