工作原理

一次转换分四步：判断文件究竟是什么、找到通往目标格式的路径、执行它，然后把结果交给你。下面逐一说明。

我们按字节识别格式，而不是按文件名

名为 report.pdf 的文件未必真的是 PDF，而完全没有扩展名的文件通常仍可辨认。因此我们做的第一件事，是读取上传内容开头的若干字节，并与已知的格式签名比对。

这比听起来更重要。相信扩展名意味着一个被改名的文件要么以令人困惑的错误失败，要么更糟 —— 被交给错误的工具。读取字节则意味着标注错误的文件依然能正确转换，而真正名不副实的文件会被明确拒绝。

每一种受支持的转换都是两个格式之间的一条边，每条边都记录了它的保真程度、大致开销，以及可接受的最大输入。格式页面正是由这张图生成的，并通过 API 完整公开。

如果你指定的两个格式之间没有边，我们会立即告诉你，而不是等上传完成之后。我们不会为了让转换看起来可行，而悄悄经由一个有损的中间格式。

缩放一张图片远不到一秒，因此在请求内部完成，响应里已经带着结果。渲染长文档或转码视频则不然，这类任务会进入队列，由一组独立的工作进程处理。

你从不需要猜测自己拿到的是哪一种。已完成的任务带着结果返回；排队的任务带着任务 ID、队列位置和预估时间返回，你可以轮询它，或者等邮件。

在 Plus 方案中，排队的工作会排在免费层任务之前 —— 这就是该方案的优先级在实际中的含义。

网站、API 和邮件转换是通往同一条流水线的三扇门。它们的差别仅在于如何识别调用方 —— 会话 Cookie、bearer 令牌，或者一封邮件的发件人 —— 之后执行的是完全相同的代码。

这是刻意的约束，而不是实现细节。把「检查配额、嗅探字节、防护压缩包」实现两遍，正是其中一遍最终会对最不容易察觉的调用方漏掉某一步的方式。