为什么我们不做桌面应用

当文件不能离开私有网络时，下一个问题常常是“有没有 Windows 或 macOS 安装包”。这种形态我们有意放弃。桌面 GUI 会是第二套界面代码；“这个应用”和 /api/v1/ 一旦分叉，功能漂移几乎不可避免。

约束是边界，不是外壳

“字节留在这里”靠你自己运行的 pdfx-server 就能满足，并不依赖 WinForms 或 Electron 这种具体形态。Compose 加 pdfx（本地运行，或用 --cloud 指向你的 base URL），让浏览器、REST、MCP、CLI 共享同一份操作目录。

怎么把这套栈立起来写在自托管里：Compose 用 task docker:build / task docker:up（API 在 :8080，门户在 :3000），本地开发则在门户旁边跑原生的 task pdfx:dev。想要一道固定门闸就设置 SECURITY_CUSTOMGLOBALAPIKEY。本文只回答一个问题：这套栈为什么不包成桌面产品。

本地 pdfx（不带 --cloud）在持有文件的机器上运行 pdf-core，这已覆盖从不需要 GUI 的离线批处理。云模式让同一个 CLI 打向你的自托管或托管 API base，multipart 契约与 curl 完全一致。

桌面分叉的代价

消费级套件优化的是画布编辑、可视化对比和应用商店安装包。维持那套界面意味着每加一个 op（合并参数、OCR 模式、消毒默认值）都要在另一个 GUI 里再实现一遍，而它不是 Agent 已在调用的 OpenAPI 契约。

插件和商店渠道会放大支持成本，却不会改善 MCP 或 Idempotency-Key 的行为。每一次商店审核与系统权限弹窗，花掉的时间都不会落到 /v1/openapi.json 上。一旦桌面那棵树上线了 API 没有的合并选项（或反过来），自动化脚本和演示就会悄悄对不上。

OCR 是个具体的例子，说明重复为什么会伤人。当前服务端路径返回 Markdown（text/markdown），分 Auto 与 Force 两种模式（Force 用 ocrType=force-ocr）。如果某个桌面 UI 还在承诺“带隐藏文本层的可搜索 PDF”，那是在描述另一条流水线，等于说假话。只保留一份 op 定义就不会出现这种分裂。

一份目录、四种客户端、零第二 UI

产品对同一批 op 已经有四种句柄：门户表单、打到 /api/v1/… 的 curl、/mcp 上的 MCP，以及本地或云模式的 pdfx。合并 就是具体例子：按上传顺序把 PDF 合起来，不把页面栅格化成图像，无论你点了“处理”，还是 POST 了多个 fileInput 部分。

桌面版会是第五种句柄，还自带一条独立发版线。我们在意的失败模式不是“少了个托盘图标”，而是“演示页面还能用，而依赖同一个 op 的脚本已经悄悄回归了”。

我们不在声称什么

跳过桌面版并不会在浏览器里变出 Acrobat 级的交互式编辑。表单工具加 HTTP 作业仍然是产品本身。在线编辑画布、可视化对比、消费级签名 UI 都刻意留在范围之外。需要私有部署，就把 Compose 拉起来，把客户端指向你的 API base；需要像素级编辑器，就用为这件事而生的套件，不要等 PDF123 出一个 .exe。

托管 PDF123 依然是快速的匿名路径，自托管是同一套工具箱搬到防火墙之后。两条路径都不是第三套、会各自漂移的桌面版。与纯浏览器转换器的对比见为什么自托管 PDF 工具箱。买到什么、要运维什么，见自托管实际买到什么。四种非桌面客户端怎么保持一致，见同一操作，四种客户端。