Image.Save 选错编码器参数会导致图片体积增大，需显式设置 Quality（75–85）、填充透明背景、启用 HighQualityBicubic 插值、分步缩放、偶数尺寸，并注意 ImageSharp 与 GDI+ 的 Quality 差异及资源释放。
用 Image.Save 时选错编码器参数，图片反而更大
默认用 JpegEncoder 保存时，如果不显式设置质量，.NET 6+ 会用 80% 质量（旧版可能更低），但很多人直接传空 EncoderParameters 或漏掉 Quality 项，结果压缩率极差，甚至比原图还大——尤其对 PNG 转 JPG 场景。
- 必须创建
EncoderParameters并添加EncoderParameter，键为Encoder.Quality，值为 1–100 的整数（推荐 75–85） - 别用
Bitmap.Save(string)这种无参重载，它走默认编码器策略，不可控 - PNG 转 JPG 前先检查是否含透明通道：有则必须先填充背景色，否则
Save可能静默丢数据或崩溃
缩放尺寸前没做双线性重采样，边缘锯齿严重且文件没变小
单纯调 Graphics.DrawImage 不设插值模式，系统用最近邻算法，缩略图模糊+块状感强，还因高频噪声拖慢 JPEG 压缩效率，最终体积不降反升。
- 务必在绘图前设
graphics.InterpolationMode = InterpolationMode.HighQualityBicubic - 缩放比例低于 0.5 时，建议分两步缩放（比如 1→0.7→0.35），单步过猛会导致细节坍缩、压缩后出现明显色带
- 目标尺寸宽高都得是偶数（尤其 JPEG），避免解码器对齐补零，徒增几个字节
ImageSharp 替代 GDI+ 时，JpegEncoder 的 Quality 含义不同
GDI+ 的 Quality 是 1–100 整数，而 ImageSharp 的 JpegEncoder.Quality 是 1–100 浮点数，但底层映射逻辑不一样：设 80 在 ImageSharp 中实际压缩强度接近 GDI+ 的 72，容易误判效果。
- 实测对比建议：GDI+ 设 80 → ImageSharp 设 75；GDI+ 设 90 → ImageSharp 设 85
- ImageSharp 默认启用
OptimizeEntropically（熵优化），开启后体积更小但编码稍慢，生产环境建议保持开启 - 别混用
Image.Load和Image.Save的不同版本包（如 v2.x 和 v3.x），API 兼容性差，JpegEncoder构造方式会报错
内存中反复 Clone 或 Dispose 错位，导致图片处理卡顿甚至 OutOfMemoryException
在循环里对同一张 Bitmap 多次 Clone()，又没及时 Dispose()，GDI+ 句柄堆积，尤其 Windows Server 环境下句柄数很快见顶；而 ImageSharp 虽无句柄，但未释放 Image 实例仍会占大量托管内存。
- 所有
Bitmap、Graphics、Image（GDI+）必须用using包裹，不能只 Dispose 图像不 Dispose Graphics - ImageSharp 的
Image.Load返回对象必须显式image.Dispose()，它不实现 finalizer，GC 不保证及时回收 - 批量处理时，复用
Image实例（image.Mutate(...)）比反复Load/Dispose快 30% 以上
