Convert.ToBase64String转图片需先读取字节再编码；避免不关闭流、手动拼MIME头；慎用File.ReadAllBytes处理大图防爆内存；注意中文路径编码；ToBase64String仅接受byte[]而非Bitmap。
用 Convert.ToBase64String 转图片为 Base64 字符串
核心就是读取图片字节，再编码。别直接读文件流后不关闭、也不用自己拼 MIME 头——除非你明确需要 data URL 格式。
常见错误：File.ReadAllBytes 读大图时爆内存；或者忘了指定编码格式导致中文路径报错；还有人把 Bitmap 对象直接传给 ToBase64String，结果编译不过——它只收 byte[]。
- 先用
File.ReadAllBytes(path)获取原始字节（小图稳妥， - 大图建议用
using var fs = new FileStream(...)+MemoryStream流式读取再转 byte[] - 编码后字符串默认不含前缀，如需 data URL（比如前端
<img src="data:image/png;base64,...>%EF%BC%89%EF%BC%8C%E6%89%8B%E5%8A%A8%E6%8B%BC%EF%BC%9A%20" data: mimetype base64string alt="C#怎么操作图片Base64转换 C#如何将图片转Base64字符串和Base64还原为图片文件【图像】" > -
mimeType别硬写image/jpeg，从文件扩展名或Image.RawFormat推断更可靠
示例：
string imagePath = @"C:\test.jpg"; byte[] bytes = File.ReadAllBytes(imagePath); string base64 = Convert.ToBase64String(bytes); // 纯 Base64，无头无尾
用 Convert.FromBase64String 还原图片文件
这是编码的逆操作，但关键在「还原成什么」：是存文件？还是加载为 Image 或 Bitmap？很多人卡在解码后不会正确构造图像对象，或者忽略异常处理导致程序崩。
常见错误：FromBase64String 输入含空格/换行/前缀（如 data:image/...;base64,）直接抛 FormatException；还有人把解码后的 byte[] 直接喂给 new Bitmap(byte[])——.NET 不支持这种构造方式。
- 先清理字符串：用
base64.Trim().Replace("\r", "").Replace("\n", "") - 如果带 data URL 前缀，用
base64.Substring(base64.IndexOf(',') + 1)截取纯 Base64 段 - 解码后得到
byte[]，存文件就File.WriteAllBytes(outputPath, bytes) - 要加载为图像对象，必须用
new MemoryStream(bytes)构造流，再传给Image.FromStream()或Bitmap.FromStream() - 务必
using流，否则资源泄漏，尤其在循环批量处理时容易 OOM
示例：
string base64 = "iVBORw0KGgoAAAANSUhEUgAA..."; // 纯 Base64 byte[] bytes = Convert.FromBase64String(base64.Trim()); File.WriteAllBytes(@"C:\output.png", bytes); // 直接存盘
注意 Image.FromStream 的陷阱和兼容性
很多人以为解码完 byte[] 就万事大吉，结果调 Image.FromStream(new MemoryStream(bytes)) 后一操作就报 Parameter is not valid——大概率是流没重置位置，或图像格式不被 GDI+ 支持。
Windows 上 .NET Framework 默认用 GDI+ 解码，对 WebP、AVIF 完全不认；.NET 6+ 在 Windows 上仍默认走 GDI+，除非显式用 ImageSharp 或开启 System.Drawing.Common 的 Skia 后端（需额外配置）。
- 每次用
MemoryStream创建图像前，必须ms.Position = 0，否则从末尾开始读，必然失败 -
Image.FromStream返回的对象不能跨线程访问（尤其 WinForms/WPF 中 UI 线程限制） - 若需支持 WebP、HEIC 等现代格式，别硬扛 GDI+，改用
SixLabors.ImageSharp库，它的Image.Load<tpixel>(byte[])</tpixel>更健壮 - Linux/macOS 下
System.Drawing依赖 libgdiplus，常缺组件导致DllNotFoundException，生产环境慎用
Base64 转换不是万能的，该绕开就绕开
Base64 编码会让体积膨胀约 33%，传大图（>2MB）时不仅拖慢接口，还可能触发 ASP.NET 的默认请求体限制（maxAllowedContentLength）、或前端 fetch 的内存压力。很多场景其实不需要真转 Base64。
- 前后端传图，优先走文件上传（
multipart/form-data）+ 服务端返回 URL，而不是塞 Base64 字符串 - 本地调试临时看图，用
File.OpenRead+ 内存流加载，比来回编解码快得多 - 做缩略图或加水印？别先转 Base64 再解，直接用
ImageSharp流式处理原始流 - 日志里打 Base64 是自找麻烦——既难读又占空间，记个文件哈希或路径更实用
真正绕不开的，一般是微信小程序上传、某些老 API 强制要求 data URL、或离线 PWA 静态资源内联。其他时候，先问一句：非得 Base64 吗？
