java 8+ 应使用 java.util.base64，它提供标准、url安全和mime三种编码器；编码解码必须显式指定utf-8，避免平台默认编码不一致；解码失败多因输入非法或类型不匹配；encoder/decoder线程安全可复用，但大文件需流式处理防oom。
Java 8+ 直接用 java.util.Base64，别引第三方库
Java 8 起标准库就带了靠谱的 Base64 实现，sun.misc.BASE64Encoder 已废弃且在 JDK 9+ 默认不可用，硬用会抛 NoClassDefFoundError 或 IllegalAccessError。用 java.util.Base64 是唯一推荐路径，无需额外依赖。
它分三类编码器：Base64.getEncoder()（标准）、Base64.getUrlEncoder()（URL 安全）、Base64.getMimeEncoder()（带换行的 MIME 格式）。日常 API 通信或存储用标准编码器即可。
- 编码前不用手动转
String→byte[]：直接传String.getBytes(StandardCharsets.UTF_8)，别用无参getBytes()（平台默认编码不一致） - 解码后得到
byte[]，转String时也必须显式指定StandardCharsets.UTF_8 -
getUrlEncoder()会把+和/换成-和_，适合 URL、文件名、JSON 字段值
解码失败常见报错：IllegalArgumentException: Illegal base64 character
这基本等于“你给的字符串根本不是合法 Base64”，不是代码写错了，而是输入脏了。典型原因：
- 字符串被截断（比如日志里只抄了前半段）
- 混入空格、换行、
=补位符缺失（Base64 长度必须是 4 的倍数） - 用了 URL 安全编码的结果，却拿标准解码器去解（
-/_会被当成非法字符） - 前端 JS 用
btoa()编码了非 ASCII 字符（它只处理 ISO-8859-1），Java 解码时字节对不上
临时兜底可加 try-catch，但更该在上游校验或统一约定编码类型。例如 HTTP Header 里传 Base64，默认走 getUrlEncoder() + getUrlDecoder() 更稳妥。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
Base64.Decoder.decode() 返回 byte[]，别直接当字符串打印
解码结果是原始二进制数据，不是可读文本。如果原始内容本就是 UTF-8 字符串，那解码后得再用 new String(decodedBytes, StandardCharsets.UTF_8)；如果是图片、PDF 等二进制，则应直接写入文件或传给对应处理器。
- 错误示范：
System.out.println(decoder.decode("SGVsbG8="))—— 打印的是[B@xxxxx，不是"Hello" - 正确做法：
String s = new String(decoder.decode("SGVsbG8="), StandardCharsets.UTF_8) - 若不确定原始编码（比如解码的是用户上传的任意文件），就别强转
String，保留byte[]最安全
性能和线程安全：Encoder/Decoder 实例可复用，但别跨线程共享状态
Base64.getEncoder() 和 Base64.getDecoder() 每次调用都返回新实例，它们是无状态的，线程安全。你可以缓存一个静态 final 实例提升可读性，但没必要——JVM 优化足够好，频繁新建开销极小。
- 可以这样写：
private static final Base64.Encoder ENCODER = Base64.getEncoder(); - 但别为了“省对象”把
Encoder当成员变量塞进有状态的类里，容易引发误用 - 注意：
Base64.getMimeEncoder()支持链式配置（如.withoutPadding()），但每次调用都会生成新实例，配置不可变
真正要小心的是编码内容本身：超大 byte[]（比如几百 MB 文件）直接进 encode() 会触发一次完整内存拷贝，OOM 风险高。这种场景得用流式处理，比如 Base64.getEncoder().wrap(OutputStream)。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
