等比例缩放需先确定基准（如最大边长），再按原宽高比计算目标尺寸，避免硬设宽高导致变形；应设置高质量插值与抗锯齿模式提升画质；大图缩放须移出UI线程并及时释放资源；ImageSharp更现代但需注意线程安全与DPI设置。
缩放时保持宽高比，别硬设 Width 和 Height
直接给 Bitmap 构造函数传入目标宽高，不计算比例，是导致图片拉伸变形的最常见原因。等比例缩放的核心是先确定一个基准（比如最大边长、目标宽度或目标高度），再按原始宽高比推导另一个维度。
实操建议：
- 用
original.Width和original.Height算出原始宽高比(double)original.Width / original.Height - 若按“最大边不超过 800 像素”缩放：取
scale = Math.Min(800.0 / original.Width, 800.0 / original.Height)，再用(int)(original.Width * scale)和(int)(original.Height * scale)得新尺寸 - 避免用
Math.Round或四舍五入强制对齐像素——缩放后尺寸为 0 是常见崩溃点，务必加Math.Max(1, ...)防御
Graphics.DrawImage 缩放质量差？关键在 InterpolationMode 和 SmoothingMode
默认绘制模式下，DrawImage 会用低质量双线性插值，边缘发虚、文字糊成一片。这不是算法问题，是渲染设置没调对。
实操建议：
- 必须设置
graphics.InterpolationMode = InterpolationMode.HighQualityBicubic - 加上
graphics.SmoothingMode = SmoothingMode.HighQuality和graphics.PixelOffsetMode = PixelOffsetMode.Half（后者能缓解边缘偏移） - 如果源图含 Alpha 通道且缩放后出现灰边，需确保
graphics.CompositingMode = CompositingMode.SourceOver，并用PixelFormat.Format32bppPArgb创建目标Bitmap
大图缩放卡顿或内存溢出？别在 UI 线程里直接操作 Bitmap
一张 5000×4000 的 PNG 解码后可能占 80MB 内存，Bitmap 构造 + Graphics 绘制全在 GDI+ 层同步执行，UI 线程一卡就是几秒。这不是代码写得不够“优雅”，是资源模型限制。
实操建议：
- 用
Task.Run(() => ResizeImage(...))移出 UI 线程，但注意Bitmap不跨线程共享——所有图像操作必须在同一个线程内完成 - 缩放前先用
Image.FromStream配合new Bitmap(stream)而非直接Image.FromFile，可避免文件锁和延迟解码 - 缩放完成后立即调用
sourceBitmap?.Dispose()和graphics?.Dispose()，GDI+ 句柄泄漏比托管内存泄漏更致命
用 ImageSharp 替代 GDI+？注意 .NET 版本与线程安全
如果你的项目已用 .NET 6+，ImageSharp 是更现代的选择：无 GDI+ 依赖、支持 WebP/AVIF、自动 SIMD 加速。但它不是“设了参数就完事”的黑盒。
实操建议：
- 安装
ImageSharp2.x（对应 .NET 6/7）或 3.x（.NET 8），别混用ImageSharp.Drawing扩展包版本 - 缩放用
image.Mutate(x => x.Resize(new ResizeOptions { Size = new Size(w, h), Mode = ResizeMode.Max }），ResizeMode.Max才是等比缩放，Crop或Pad会改画面 -
Image实例不是线程安全的，多个任务并发调用Mutate必须加锁，或每个任务 new 一个独立实例
真正容易被忽略的是：缩放后的 DPI 信息丢失。GDI+ 默认输出 96 DPI，ImageSharp 默认 72 DPI。如果后续要打印或和 CAD 数据对接，得手动写入 image.Metadata.HorizontalResolution 和 VerticalResolution。这不会影响显示，但会影响下游系统对物理尺寸的解析。
