Convert.ToBase64String和Convert.FromBase64String需严格处理编码与字节转换：字符串必须用Encoding.UTF8.GetBytes转为字节数组再编码，解码前须清理空白、补全填充并校验格式，大文件应分块处理避免内存溢出。
Convert.ToBase64String 和 Convert.FromBase64String 是 C# 中最直接、无需额外依赖的 Base64 编解码方式，但直接用它们处理字符串时，90% 的乱码或异常都源于编码转换这一步被跳过或选错。
Convert.ToBase64String 只接受 byte[]，字符串必须先转字节
Convert.ToBase64String 方法签名是 string ToBase64String(byte[] inArray)，它根本不认识 string 类型。试图写 Convert.ToBase64String("hello") 会编译失败。
- 必须显式调用
Encoding.UTF8.GetBytes("hello")得到字节数组 - 不要用
Encoding.Default（即系统本地编码），跨机器传输时极易解码失败 - 中文、emoji、特殊符号在 UTF-8 下是多字节，用其他编码（如 ASCII）会截断或抛
ArgumentException
string original = "你好 ?"; byte[] bytes = Encoding.UTF8.GetBytes(original); // ✅ 正确：UTF-8 是事实标准 string base64 = Convert.ToBase64String(bytes); // "5L2g5aW9IOaYr+S9oA=="
解码失败？先检查输入是否“干净”和“合规”
Convert.FromBase64String 对输入极其严格：长度必须是 4 的倍数，字符只能是 A–Z、a–z、0–9、+、/、=，且 = 只能出现在末尾。
常见导致 FormatException 的情况：
- 字符串含空格、换行符（比如从日志复制、邮件正文粘贴）
- 来自 URL 或 JWT 的 Base64Url 格式（用
-替代+，_替代/，且省略=） - 前端 JS 用
btoa()编码时传入了非 Latin-1 字符（JS 里需先encodeURIComponent再btoa，否则后端解不出）
修复建议：
- 清理空白：
base64.Replace(" ", "").Replace("\r", "").Replace("\n", "") - Base64Url 转标准：
base64.Replace('-', '+').Replace('_', '/') - 补齐填充：
base64.PadRight(base64.Length + (4 - base64.Length % 4) % 4, '=')
处理图片或大文件时，别让 File.ReadAllBytes 拖垮内存
Convert.ToBase64String(File.ReadAllBytes("big.pdf")) 看似简洁，但对 50MB 文件，内存中会同时存在原始字节数组（50MB）+ Base64 字符串（约 67MB），极易触发 OutOfMemoryException，尤其在容器或低配服务器上。
更安全的做法：
- 小文件（File.ReadAllBytes，简单可靠
- 大文件或流式场景：改用
Stream+ 分块缓冲（例如每次读 3072 字节原始数据 → 编码为 4096 字节 Base64 块），避免一次性加载 - 图片等二进制数据，优先用
File.ReadAllBytes(path)而非Image.Save到MemoryStream，后者引入System.Drawing依赖且在 Linux 上可能失败
真正容易被忽略的点是：Base64 不是加密，也不是压缩，它只是编码；它的唯一作用是把任意字节序列映射成可打印 ASCII 字符。所有“为什么解出来是乱码”“为什么长度不对”的问题，根源几乎都在字节与字符串之间的编码桥接没对齐——不是 Base64 本身的问题，而是你没告诉它“原始字节当初是怎么来的”。
