平台锁定警告Compositor 只在 macOS 跑Windows 和 Linux 用户只能干瞪眼【免费下载链接】CompositorThe Photoshop alternative for Mac项目地址: https://gitcode.com/gh_mirrors/compos/Compositor「Adobe Photoshop 太贵GIMP 又用不顺手」——这是 Compositor 作者在 README 里写下的开场白。这款 100% 免费开源、MIT 协议、对标 Photoshop 核心工作流的图像编辑器近一年在国内技术社区持续刷屏图层、选区、污点修复、内容感知填充、Camera Raw 调色几乎把 PS 的经典工作流搬了个遍还顺手接入了 AI Agent 协作。但有一个问题被反复提起、却少有人正面回答它只在 macOS 上跑。Windows 和 Linux 用户真的只能干瞪眼吗这篇「平台锁定警告」我们从源码出发逐层拆解这个 macOS-only 的硬边界到底硬在哪里、移植要付出什么代价、以及非 Mac 用户手上还有哪些牌可打。一、硬边界从哪来这不是顺便只做了 Mac而是处处为 Mac 而生先看最直白的证据。在仓库根目录的 README.md 中「Requirements」一节写得毫无回旋余地macOS 26.0 or later on a Mac with Apple siliconApple 芯片的 MacmacOS 26.0 及以上这不是「目前只支持 Mac以后再说」而是项目从第一行代码起就建立在 Apple 生态的地基上。打开 Compositor.xcodeproj/project.pbxproj 可以看到三组铁证SDKROOT macosx工程只链接 macOS SDK不声明任何 iOS / Catalyst / 跨平台目标ARCHS arm64只编译 Apple Silicon 指令集Intel Mac 都不在官方支持列表里MACOSX_DEPLOYMENT_TARGET 26.0最低系统版本直接钉在 macOS 26摆明要吃最新的系统 API。productType全部是com.apple.product-type.application和com.apple.product-type.bundle.unit-test构建脚本只认xcodebuild发布脚本只产出.dmg——这套从编译、签名、公证到分发scripts/release.sh、scripts/publish.sh的完整流水线就是标准 macOS 原生应用的出厂流程。二、源码级证据83 个文件 import AppKit像素运算靠 CGPU 靠 Metal「macOS-only」绝不是配置文件里一行字那么简单。深入代码库做一次依赖普查你会看到边界是长在肌肉里的。在 Compositor 主目录的 Swift 源码里做 import 统计结果一目了然83 import AppKit 50 import SwiftUI 34 import CoreGraphics 21 import CoreImage 11 import UniformTypeIdentifiers 5 import Metal 2 import VisionAppKit以 83 次的绝对优势碾压全场——它是 macOS 专属的 UI 框架在 Windows / Linux 上根本不存在。这意味着UI 层窗口、菜单、面板、快捷键、拖放不是「可以换皮肤」而是整层要重写。再看渲染层。UI 之下项目采用 Swift C 混合架构9 个纯 C 像素内核文件安静地躺在 Compositor/Rendering 下——AdjustPixels.c、BrushPixels.c、ContentFill.c、HealPixels.c、WandPixels.c等处理最吃性能的逐像素运算。以污点修复为例HealPixels.h 头文件写得非常清楚spot_heal()在预乘 RGBA 位图上原地工作支持 Content-Aware / Create Texture / Proximity Match 三种模式用「膜填充」把采样纹理和周围色调平滑融合内容感知填充则对应 ContentFill.h 里的content_fill()由 ContentFill.swift 直接调用。这段 C 代码是纯 ANSI C stdint只依赖内存缓冲操作理论上反而是整个项目里最可移植的部分——Linux 上的编译器可以直接吃下这些文件。但 GPU 加速层就没这么幸运了。打开 GPUCanvas.swift画布合成直接驱动MTLCreateSystemDefaultDevice()创建 Metal 设备用CAMetalLayer承接绘制CIContext 基于 Metal 命令队列构建——Metal 是 Apple 专属图形 APILinux 和 Windows 上连驱动都不存在。图层效果描边、投影、内外发光由 MetalLayerEffects.swift 在 GPU 上实时渲染涂抹 / 液化工具Smudge / Liquify干脆把整份工作拷贝放在 GPU 纹理里MetalWarp.swift每一笔都在 GPU 上重采样只在笔划结束时把像素取回 CPU。这套「画布 GPU 化」设计是性能的核心也是移植的最大障碍——换平台意味着要么重写一套 Vulkan / Direct3D 后端要么放弃 GPU 加速退回 CPU 渲染而 CPU 渲染正是作者当初为了性能亲手淘汰的方案。三、三个偷懒可行的伪命题Vision、AppKit 快捷键、内核事件有人可能会说反正 UI 用 SwiftUI 写的Swift 也有开源版Swift 语言本身在 Linux 上可用重写成本不至于太高吧这个直觉需要被三个事实纠正。第一Vision 框架深度介入 AI 功能。打开 ObjectSelection.swift第 3 行赫然是import Vision注释写明「Object Selection: selects the Vision foreground instance under point」。主体识别、一键抠图这些「黑科技」功能底层是苹果 Vision 框架的实例分割模型而 Vision 是闭源且仅存在于 Apple 平台的系统框架——换平台后这类功能连「重写」都无从谈起只能换模型、换推理后端等同于功能级重写。第二交互层深度绑定 AppKit 事件体系。KeyboardShortcuts.swift 里录制快捷键要重写NSView的keyDown(with: NSEvent)文件拖放要处理NSPasteboardImageFileDrop.swift打开 / 保存文件依赖NSOpenPanel/NSSavePanel。这还没算CompositorApp.swift里NSApplicationDelegateAdaptor、WindowPlacement、handlesExternalEvents这些 SwiftUI AppKit 混合的生命周期管理。把 83 处 AppKit 调用逐一声明成跨平台抽象工作量不亚于重写整个 UI 层。第三文件监听走的是内核事件。ProjectWatcher.swift 的注释写得很实在它监听「内核的文件系统事件」FSEvents所以才能做到「外部写入 .comp 项目 → 画布半秒内热更新」且不依赖写入方遵守文件协调协议。FSEvents 同样是 macOS 内核特性跨平台等价物inotify / ReadDirectoryChangesWAPI 语义完全不同需要单独适配。四、认真算一笔账跨平台移植的真实工作量把上面的依赖摊开一份保守的移植工程量清单长这样依赖层现状跨平台代价UI 框架AppKit / SwiftUI 混合83 处 AppKit、50 处 SwiftUI整层重写或引入跨平台 UI 框架成本最高GPU 渲染Metal CAMetalLayer画布合成、图层效果、涂抹液化重写 Metal→Vulkan/D3D12 后端或退回 CPU系统框架Vision / CoreImage / CoreGraphics主体识别、CIFilter、位图处理Vision 无替代需换模型其余需逐 API 适配C 像素内核9 个 .c 文件纯 ANSI C无平台依赖几乎零成本可直接复用分发链路Sparkle 更新、Developer ID 签名公证只认 macOS需另建 Windows/Linux 更新与签名通道9 个 C 内核文件是唯一可以「白拿」的资产其余每一层都要动刀。更要命的是作者在 README 里明说了「maintained by one person」单人维护甚至因为「看不懂的语言无法 review」而拒绝翻译 PR。对一个单人项目来说维护一个跨三平台、每平台一套 UI 框架和 GPU 后端的代码库维护成本不是线性增长而是相乘关系。五、非 Mac 用户手上有什么牌六条开源替代路线社区里对 Compositor 的讨论包括 CSDN「六条路子绕开 PS」等盘点文章早就给出了答案Windows 和 Linux 用户不缺少可打的牌缺的只是和 Compositor 长得一样的牌。Photopea浏览器里跑的在线编辑器PSD 兼容性极强跨平台天然适合偶尔应急和轻量修图GIMP桌面端全能开源之王Windows / Linux / macOS 全平台覆盖功能最接近 PS 的全家桶式选择Krita专业数字绘画向画笔引擎一流对画师比 GIMP 更友好PhotoDemon约 12MB 的便携小钢炮追求轻量时首选Pinta极简跨平台适合只做基础编辑的轻度用户。如果非要无损搬家Compositor 支持导入 PSD / PSB8-bit RGB图层组、蒙版、混合模式、形状图层保持可编辑见 PSDReader.swift而 Photopea / GIMP 同样能读写 PSD——文件格式是互通的工作成果不会因为换工具而作废。真正的痛点在「手感」Compositor 的卖点是 Photoshop 式快捷键 非破坏性工作流这些体验在其他工具上只能重新适应。六、给项目方的建议多平台还是深耕原生从工程理性出发最值得做的事其实不是全平台而是以下三件事第一把 C 内核的资产价值最大化。9 个纯 C 像素内核是目前唯一天然跨平台的部分完全可以抽成独立子模块甚至单独开源让其他平台的编辑器项目也能复用污点修复、内容感知填充这些算法——这对开源生态的贡献比硬扛一个三平台 UI 大得多。第二守住原生体验的护城河。非破坏性变换、GPU 实时图层效果、Vision 主体识别、.comp 文件热更新这些能力高度依赖 Apple 平台 API恰恰是 Compositor 相对 GIMP 们的差异化优势。与其把资源摊薄到两个不熟悉的新平台不如把 macOS 体验做到极致——这也是 README 里作者已经用行动表明的取舍。第三如果要出 Linux / Windows 版正路只有两条一是等一个「愿意长期全职维护跨平台分支」的社区团队出现参考 Blender、Krita 的基金会式治理二是在 Electron / Tauri 等 Web 技术栈上重建 UI 层并接入 WebGPU把 C 内核编译成 WebAssembly 复用——这在架构上是可行的但等于把项目切成两个产品作者本人显然无意走这条路。结论其实很清楚Compositor 的 macOS-only 不是缺陷而是设计选择——它用 Apple 平台独占的 Vision、Metal、AppKit 换来了体积小巧、性能凌厉、体验顺滑的PS 平替。Windows 和 Linux 用户与其对着仓库干瞪眼不如看清这张平台锁定地图能用的是 C 内核的算法资产和 PSD 互通的文件格式不能用的是整套 Apple 原生体验。选择权在每个人自己手上——要么等跨平台分支要么把 Photopea / GIMP 用顺手要么干脆买台 Mac。【免费下载链接】CompositorThe Photoshop alternative for Mac项目地址: https://gitcode.com/gh_mirrors/compos/Compositor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考