直接整张大图读入内存再Base64编码易致OOM，因需同时存原始字节数组和膨胀后的Base64字符串；应采用流式分段编码、前置压缩降采样、避免字符串拼接，并配合JVM/平台层内存管控。
直接把整张大图读进内存再 Base64 编码，是 OOM 的典型诱因。根本原因不是“图片太大”，而是编码过程强制在内存中同时存下原始字节数组和膨胀后的 Base64 字符串——1GB 原图，内存峰值可能冲到 1.7GB 以上。解决的关键，是打破“全量加载”这个前提。
用流式分段编码替代一次性加载
不把整个文件读入内存，而是按固定块大小（如 8192 字节）分批读取、编码、输出。这样内存中只保留当前块的原始数据和对应 Base64 结果，峰值占用恒定，与文件总大小无关。
- 每次读取的字节数建议设为 3 的倍数（如 3072、6144、9216），因为 Base64 每 3 字节生成 4 字符，能避免末尾补位带来的缓冲区边界处理复杂度
- 使用 InputStream → ByteArrayOutputStream → Base64.getEncoder().encode() 链路，但必须控制 ByteArrayOutputStream 的写入范围，不能让它累积全部数据
- 编码结果不要拼成一个大字符串，而应逐块写入 FileOutputStream 或追加到 StringBuilder（若最终仍需字符串，且确定总长可控）
对图片本身做前置压缩或降采样
Base64 膨胀是固定的，但原始图片体积可以主动减小。尤其在上传场景中，用户手机拍出的图常远超展示所需分辨率。
- Android 端可用 BitmapFactory.Options.inSampleSize 先缩放解码，比如 inSampleSize=2 表示宽高各取 1/2，像素总量变为 1/4，内存占用直降 75%
- 服务端收到原始图后，可先用 ImageIO 或 Thumbnails 库生成指定尺寸缩略图，再对缩略图做 Base64 编码，而非原图
- 若业务允许，将图片转为 WebP 格式再编码，比 JPEG 同质量下体积平均小 25%～30%，从源头降低 Base64 输入数据量
规避字符串拼接导致的二次内存压力
即使分段编码，如果用 String += 或 StringBuilder.append() 累积所有块，最终仍会构造一个巨大字符串，触发第二次内存高峰。
- 优先将每段 Base64 直接写入文件或网络输出流，完全绕过字符串拼接
- 若必须返回完整 Base64 字符串，改用 byte[] 数组预估总长：原始字节数 × 4 / 3 + 4（补位预留），分配一次性的 byte[]，用 Base64.Encoder.encode() 直接写入该数组对应偏移位置，最后 new String(byteArray, StandardCharsets.US_ASCII)
- 禁用 String.intern()，避免字符串常量池被大量 Base64 内容占满
配合 JVM 和平台层做兜底控制
编码逻辑优化是核心，但运行环境配置能提供安全缓冲。
- JVM 启动参数增加 -XX:+UseG1GC -Xms2g -Xmx2g，固定堆大小并启用 G1 垃圾收集器，减少大对象分配时的碎片和 Full GC 风险
- Android 端设置 Bitmap.Config 为 RGB_565（2 字节/像素），比默认 ARGB_8888（4 字节/像素）节省一半内存
- 服务端限制单次请求图片最大尺寸（如宽高均 ≤ 4096）、最大文件体积（如 ≤ 10MB），在接入层就拦截明显越界的请求
