Base64字符串需先剥离data URL前缀再解码，确保长度为4的倍数并补足填充符；解码后须校验字节头（如JPEG为FFD8）以准确识别格式并设置对应MIME类型，避免因内容与类型不匹配导致图片无法渲染。
Base64 字符串能直接转成图片，但必须确保格式合法、前缀正确、字节数可被 4 整除，否则 Convert.FromBase64String() 会抛 FormatException 或 ArgumentException。
Base64 字符串是否带 data URL 前缀？
常见错误是把完整 data URL（如 "data:image/png;base64,iVBORw0KGgo..."）直接传给解码函数。它会因非法字符（冒号、斜杠、逗号）而失败。
- 用
string.Contains("base64,")判断是否存在前缀 - 存在时用
str.Split(new[] { ',' }, 2)[1]取出纯 Base64 段（注意2表示最多切两段，避免中间有逗号误切） - 不建议用
Substring()硬截取，因为 MIME 类型长度不固定（image/jpegvsimage/webp）
解码后字节能否构造有效图片？
Convert.FromBase64String() 成功只说明 Base64 合法，不代表字节流是有效图片。常见陷阱：
- 末尾缺少填充（
=），导致解码后长度异常 → 检查原始字符串长度是否为 4 的倍数，不足则补= - 解码后字节数为 0 → 说明 Base64 为空或全空白，应提前
string.IsNullOrWhiteSpace()校验 - 写入
MemoryStream后用Image.FromStream()加载，若抛ArgumentException（“参数不是有效的图像”），说明字节损坏或格式不被 GDI+ 支持（如 WebP 在 .NET Framework 下原生不支持）
保存为文件时如何自动识别图片类型？
不能仅靠 Base64 前缀的 MIME 类型决定扩展名，因为前缀可能伪造或缺失；也不能依赖 Image.RawFormat，它在从内存流创建时常常为 Unknown。
- 推荐做法：先尝试用
Image.FromStream()加载，再根据Image.RawFormat.Guid匹配已知格式 GUID - 更稳妥的是读取字节头（magic bytes）：PNG 是
89 50 4E 47，JPEG 是FF D8 FF，GIF 是47 49 46 38 - 示例判断 JPEG：
bytes.Length >= 2 && bytes[0] == 0xFF && bytes[1] == 0xD8 - 确定格式后再用对应扩展名保存，避免强制写
.png却存了 JPEG 数据
在 ASP.NET Core 中返回图片流要注意什么？
直接用 File(byte[], "image/png") 不安全——MIME 类型必须与实际内容一致，否则浏览器可能拒绝渲染或触发下载。
- 不要硬编码
"image/png"，应根据真实格式动态设置contentType - 使用
MemoryStream时记得stream.Position = 0，否则File()读不到数据 - 如果 Base64 来自前端上传且含前缀，务必先剥离，否则解码失败会导致 500 错误
- .NET 6+ 可考虑用
ImageCodecInfo.GetImageEncoders()查找匹配编码器，但多数场景只需按头信息设 MIME 即可
真正容易被忽略的是：Base64 解码本身不校验图片完整性，所有“看起来解码成功但图片打不开”的问题，几乎都出在字节流源头（传输截断、编码错误、服务端日志自动截断长字符串）或 MIME 与内容不匹配上。
