近期在整理基于 Java 1.8 的老项目代码时，编译过程中出现以下告警内容：
为修复此问题，我计划将 sun.misc.BASE64Encoder替换为标准 API java.util.Base64。
完成替换后，通过测试用例对比输出结果时，发现两者生成的编码字符串存在差异：sun.misc.BASE64Encoder的输出中每间隔固定长度会出现换行符（Windows下是\r\n，Linux下是\n）。
具体示例如下：
探究原因，sun.misc.BASE64Encoder是早期 Java 的非公开 API（位于 sun.*包下），其实现严格遵循 RFC 1521 (MIME 标准)：
该标准要求 Base64 编码后每行不超过 76 字符；
因此编码器会在每 76 个字符后自动插入
\r\n；而
java.util.Base64.getEncoder()的设计为无换行符输出。
最初考虑撤销此次修改以保持历史一致性，避免手动添加换行符。但在回退前发现项目中存在以下逻辑：
该代码证实：
项目自身已意识到换行符的干扰性；
实际业务场景中无需保留 MIME 换行符。
最终决定保留 java.util.Base64的重构方案，既消除对废弃 API 的依赖，又符合原有业务逻辑的真实需求。