直接调用image.save("out.jpg", imageformat.jpeg)无法控制jpeg质量，因.net默认质量固定（如.net 6+为80）且不读取隐含设置；必须显式获取jpeg编码器、构造含唯一encoderparameter（quality=75l）的encoderparameters传入，否则质量调节无效。
Image.Save 传 ImageFormat.Jpeg 不会改变 JPEG 质量
直接调用 image.Save("out.jpg", ImageFormat.Jpeg) 是无效的——它根本不会读取你心里想设的“75% 质量”。.NET 内部走默认编码器策略，质量固定为 80（.NET 6+）或更低（旧版），且无法覆盖。你看到的文件大小没变、模糊感没改善，问题就出在这儿。
必须显式获取 JPEG 编码器并传入 EncoderParameters，否则所有关于“调质量”的尝试都是徒劳。
-
ImageCodecInfo.GetImageEncoders()返回多个编码器，要过滤出MimeType == "image/jpeg"的那个，不能只靠ImageFormat.Jpeg构造 -
EncoderParameters必须且只能含一个EncoderParameter，多一个或少一个都可能静默失败或抛ArgumentException - 质量值必须是
long类型，写75L，别写75（int 隐式转换在某些 .NET 版本下会报Parameter is not valid）
缩放图片前不设 InterpolationMode.HighQualityBicubic 会放大体积
单纯改 Encoder.Quality 压到 50，不如先缩放到目标尺寸再用 75L 保存。但很多人缩完发现图更糊、文件还更大——根源是 Graphics.DrawImage 默认用 InterpolationMode.Bilinear 或更低，高频噪声拉满，JPEG 编码器反而更难压缩。
务必在绘图前设置插值模式：
-
graphics.InterpolationMode = InterpolationMode.HighQualityBicubic是底线，不是可选项 - 缩放比例低于 0.5（比如 4000px → 1200px）时，建议分两步：先缩到 2000px，再缩到 1200px，抗锯齿和压缩效率都更好
- 目标宽高尽量设为偶数（尤其 JPEG），避免解码器对齐补零，白占几个字节
System.Drawing 处理 PNG 转 JPG 时透明通道不处理会崩溃或丢数据
把带 Alpha 的 PNG 直接 Save(..., jpegEncoder, params)，结果可能是黑底、花屏，甚至静默丢掉整张图——因为 JPEG 不支持透明，GDI+ 默认行为不稳定。
必须提前检测并填充背景：
- 用
image.PixelFormat.HasFlag(PixelFormat.Alpha)判断是否含透明通道 - 创建新
Bitmap，用Graphics.FillRectangle先画纯色背景（如白色），再DrawImage原图 - 别依赖
Bitmap.MakeTransparent()，它不解决保存问题，只是标记某色为透明
ImageSharp 比 System.Drawing 更适合现代项目
如果你在 .NET 6+、容器环境或跨平台部署，硬扛 System.Drawing 很可能遇到 DllNotFoundException（缺 libgdiplus）、句柄泄漏、线程不安全等问题。ImageSharp 是纯托管实现，无本地依赖，API 更直觉。
关键差异点：
-
JpegEncoder.Quality是int（0–100），不用封装EncoderParameter，设new JpegEncoder { Quality = 70 }即可 - 它默认启用熵优化（
Optimized = true），同质量下体积比 GDI+ 小 5–10% - 没有 GDI 句柄概念，但
Image.Dispose()仍必须调用——它不带 finalizer，GC 不保证及时释放内存 - 若需按目标文件大小压缩（如“必须 ≤ 200KB”），得手动二分尝试不同
Quality值并检查stream.Length，它不内置该逻辑
最常被跳过却影响最大的一步：没判断原始 DPI 是否远高于用途。比如一张 300dpi 扫描图用于网页展示，直接缩放会保留冗余采样信息，压缩效率打折。先用 image.HorizontalResolution 和 VerticalResolution 看一眼，再决定是否重设 DPI 元数据或直接降采样。
