翻到一个刚建 4 天的 .NET 图像库，代码还没人用过，但我读完了它全部源码 - 张善友
内容提要
ImageFacade 是 .NET 图像处理抽象库，统一 SkiaSharp、OpenCvSharp、ImageSharp 和纯托管软后端，切换后端只需改一行代码。后端不支持的功能直接抛异常，避免隐式回退。纯托管后端零原生依赖、支持 NativeAOT、输出确定，编解码性能接近或超过 C 库。但项目仅创建 4 天、单作者、API 未冻结，适合原型和内部工具，生产使用建议观望。
延伸解读
“抛异常”设计：可预测性优先于便利性
ImageFacade 删除了自动回退机制，后端不支持的功能直接抛 FeatureNotSupportedException。这看似不友好，实则避免了性能特征被隐藏——自动回退可能让一次调用悄悄慢十倍，且难以定位。对开发者而言，行为完全可预期，上线前用 Capabilities 自检即可提前规避。这种“丑但诚实”的工程取舍，在需要稳定性能的场景中值得肯定。
纯托管后端的反直觉优势与代价
软后端 SdcbSimdCodecs 零原生依赖、支持 NativeAOT、输出确定，且编解码性能接近甚至超过 C 库（作者自测 JPEG 解码为 libjpeg-turbo 的 0.82 倍耗时）。但渲染环节从原生优化换成了托管实现，绘制和 Resize 可能变慢。因此，若瓶颈在解码，软后端反而有优势；若重度依赖绘制，需实测权衡。
抽象税可控，但用法坑需留意
门面层的成本主要在像素进出边界，经 Vector128 优化后，1080p 像素搬运降至亚毫秒到几毫秒，抽象税约个位数百分比。然而，每帧重复 FromPixels、每帧新建张量缓冲（4.9MB 进大对象堆）、在 OpenCV 后端用半透明标签底导致绘制异常等用法问题，会显著影响性能或直接报错，需按文档规避。
项目极新，生产使用需谨慎
仓库创建仅 4 天，单作者，API 未冻结（0.3.x），且 0.1 到 0.3 间曾删除整个回退机制，后续变动风险高。测试仅覆盖 win-x64，Linux/macOS 只保证编译。性能数据均为作者自测，无第三方复现。适合原型、内部工具或学习，生产环境建议等 1.0 冻结 API、社区反馈后再评估。
Q&A
ImageFacade 这个库主要解决什么问题？
ImageFacade 是一个 .NET 图像处理抽象库，它把 SkiaSharp、OpenCvSharp、ImageSharp 和纯托管软后端之间的差异封装在 IImageBackend 接口后面，让业务代码只依赖 ImageEngine 和 FacadeImage 两个类。切换后端只需改一行构造代码，业务代码无需改动。
ImageFacade 为什么删除了自动回退机制？
自动回退会让开发者不知道哪次调用悄悄变慢，比如一个不支持的操作把整张图搬到软渲染再搬回来，性能特征被隐藏，出问题难以定位。现在改为后端不支持就直接抛 FeatureNotSupportedException，异常里带后端名和能力名，行为完全可预期。
纯托管软后端 SdcbSimdCodecs 有什么优势？
它是唯一同时满足零原生依赖、声明 NativeAOT 兼容、宽松许可证的后端，能在容器、CI、AOT 发布甚至 browser-wasm 上运行，且同一输入在任何平台输出字节完全一样。编解码性能接近或超过 C 库，例如 JPEG 解码耗时是 libjpeg-turbo 的 0.82 倍且零托管分配。
使用 ImageFacade 的抽象层会带来多少性能损耗？
成本集中在像素进出边界的预乘转换、通道交换和 stride 搬运。经过优化后，1080p 像素搬运压到亚毫秒到几毫秒，而 1080p 解码本身是毫秒到十几毫秒，抽象税大概在个位数百分比。
ImageFacade 在安全性和易用性上有哪些细节设计？
内置防解压炸弹：LoadOptions.MaxPixels 默认 1 亿像素，头部嗅探器能在不分配像素内存的情况下读取声明尺寸，超限直接拒绝；流式加载有独立字节数上限。还支持三态半透明检测（bool?），已知全不透明的图存 JPEG/BMP 时省去合成背景的工作；核心包嵌入文泉驿微米黑字体，容器里没有系统字体也能画中文。
现在适合在生产项目中使用 ImageFacade 吗？
不建议直接上生产。项目仅创建 4 天、单作者、API 未冻结（0.3.x），测试只在 win-x64 上跑，Linux/macOS 仅保证能编译，且没有社区反馈。适合学习、原型和内部工具；生产使用建议等 1.0 冻结 API、Linux/macOS 进入 CI、有真实用户反馈后再考虑，或锁死版本号并跑自己的基准。
