如果 OpenAI 提示“文件类型不受支持”，并让你“请重试 PDF”，先不要急着把所有文件都转成 PDF。ChatGPT 上传、当前官方 OpenAI API、以及 Azure 或 connector 的文件入口，并不总是执行同一套规则，所以第一步不是改扩展名，而是先确认报错出在哪个入口。
如果报错发生在 ChatGPT，先检查是不是 Google Docs、Sheets、Slides 这类原生云文件还没导出；如果报错发生在当前官方 API，就先确认你走的是不是正确的文件路径，比如 input_file 或 file_search；如果报错发生在 Azure 或某个 connector，PDF 可能确实还是那条入口上最快的解法。做完最小修复后，再用同一路径复验一次。如果同一个入口对一个明确定义为受支持的文件仍然报错，就不要再把它理解成“OpenAI 现在只支持 PDF”，而要把它当成路径没选对，或者那条入口还没跟上当前官方规则。
30 秒路由表
先按报错入口分路，不要只盯着文件扩展名：
| 报错发生在哪里 | 最可能的问题 | 最安全的第一步 | 如何在同一路径验证 | 什么时候该升级判断 |
|---|---|---|---|---|
| ChatGPT 上传 | 原生 Google 文件、当前格式不能直接上传，或者这份文件其实更适合转成 PDF 保住版式 | 先从 Google Docs / Sheets / Slides 导出；否则改用明确支持的格式，或在版式重要时转 PDF | 在同一个 ChatGPT 上传入口重试一次 | 导出的受支持文件依然失败 |
| 官方 OpenAI API | 文件路径选错、对 input_file 的预期不对，或者这件事其实更适合走 file_search | 换成当前文档对齐的文件路径，不要拿一条路硬套所有文档任务 | 用同一个请求路径重试，并确认结果符合任务 | 文档允许的文件和路径仍然失败 |
| Azure 或 connector | 某条相邻入口仍然表现得像 PDF-only | 对那条入口导出或转成 PDF，或者直接换到当前官方 OpenAI 路径 | 在同一个 Azure / connector 路径重试 | 连 PDF 都失败，或该入口的行为持续和官方文档不一致 |
这篇文章用到的 OpenAI 官方帮助页和开发者文档都在 2026-04-08 重新核对过。结论很直接：当前官方 OpenAI 并不是统一的 PDF-only。 只是同一句报错仍然会在某些相邻入口上出现，所以你必须先分入口，再选修法。
如果报错出在 ChatGPT
ChatGPT 这条分支，本质上是上传支持问题，不是 API 工具问题。OpenAI 当前的 支持文件类型页面 和 File Uploads FAQ 都说明，ChatGPT 支持的不只是 PDF，还包括常见文档、演示文稿、表格、文本和代码文件。也就是说，DOCX、PPTX、TXT、MD、CSV、JSON、XLSX 这类格式，在 ChatGPT 这一侧本来就不该被简单理解成“肯定要转 PDF 才能传”。
最常见的隐藏分支不是 Office 文件，而是 Google Docs、Sheets、Slides 这种原生云文件。像 .gdoc、.gsheet、.gslides 这类格式，本来就不是直接上传格式，所以你看到“请重试 PDF”，并不代表 ChatGPT 对所有文档都只认 PDF，更常见的含义其实是：你还没有先把原生云文件导出来。
这也是 PDF 仍然经常有用的真正原因。不是因为 ChatGPT 一律只收 PDF，而是因为有些文件的重点不是纯文本，而是图表、版式、嵌入图片和视觉关系。如果你真正需要模型看到的是“排版后的结果”，PDF 往往比 DOCX 或 PPTX 更稳。这里要分清楚的是：一个格式能不能被接收，和 这份内容能不能按你需要的样子被保留下来，不是同一个问题。
这条分支的验证动作也很短：把导出的文件放回同一个 ChatGPT 上传入口重试，而不是换到别的 app、别的 wrapper 或别的 API 路径上测试。如果同一个 ChatGPT 入口对一份明确受支持、而且已经正确导出的文件仍然报错，那就说明你已经不在“原生文件没导出”这条简单分支里了。
如果你最后发现问题其实不是文件类型，而是 ChatGPT 文件或图片额度本身已经打满，这篇文章就不该继续承担那份读者任务。更合适的后续页是我们的 ChatGPT Plus 上传限制指南。
如果报错出在官方 OpenAI API
真正最容易被旧结论误导的，其实是官方 OpenAI API 这条分支。OpenAI 当前开发者文档里的 PDF files and other document formats 已经明确写到：Responses API 的 input_file 路径支持的不只是 PDF，还包括文本、代码、富文档、演示文稿和电子表格。这比很多旧文章、旧论坛回答、甚至一些过时代码片段要宽得多。
但这不等于“只要能上传，效果就一定对”。同一份文档也明确说了，非 PDF 文档里的嵌入图片和图表不会被提取。所以 DOCX 或 PPTX 可能在 API 里被接受，却仍然不是最合适的输入，因为你的真实任务并不是“把文件塞进去”，而是“让模型看见图表、幻灯片关系、注释结构或混合版式”。
把这条分支理顺，最快的办法就是先按任务选路径：
| 你的真实任务是什么 | 更合适的路线 | 为什么 |
|---|---|---|
| 把一份文档直接放进 prompt 上下文里 | input_file | 这是官方当前支持的直接文档输入路径 |
| 对一组文档做检索、引用、后续追问 | file_search | 当前 file search 文档 支持多种非 PDF 文档，更适合 retrieval |
| 保住图表、示意图、嵌入视觉和排版 | 当前官方规则对视觉保真最明确的仍然是 PDF |
所以，官方 API 报这个错，通常不是一句“OpenAI 现在只支持 PDF”能解释的。更常见的情况是：你选错了文件路径；你上传的格式虽然可接收，但真正需要的是 PDF 的视觉保真；或者你请求外面还套着一个旧 wrapper、旧 connector、旧示例，把当前 API 的规则读窄了。
如果你已经换成文档允许的文件类型和路径，报错还是没消失，就该往文件层之外看了。比如 project scope、key 类型、wrapper 路由，仍然可能让“文件选对了”的请求继续失败。如果你已经走到这一步，我们的 OpenAI API Key 和 Organization ID 指南会比继续猜文件格式更有帮助，因为那篇讲的是 scope 与认证，而不是文件路线。
如果报错出在 Azure 或 connector
这条分支是最容易把局部真相误当成全局真相的地方。因为在某些 Azure 或 connector 入口上，“请重试 PDF”确实可能是当前最快的可行答案。但它并不自动等于“整个 OpenAI 现在都只支持 PDF”。
这次研究里，Azure 这一侧就能找到很典型的相邻证据。一个较新的 Microsoft Q&A 线程 仍然展示了 supported format .pdf 这类报错，而与此同时，当前官方 OpenAI 文档已经把某些第一方路径的文档支持范围写得更宽了。connector 社区里也常见同样的模式：用户贴出这句报错，回复直接让他转 PDF，但讨论并没有认真区分 connector 自己的规则，和当前第一方 OpenAI 规则之间的差异。
这对读者的实际意义很明确。如果你必须留在那条旧入口上，转 PDF 或导出 PDF 可能就是最小修复。如果你可以换路径，那么直接切回当前官方 OpenAI 路线，往往才是更好的长期答案。真正不该做的，是把一条 Azure 或 connector 的局部行为，当成所有 OpenAI 上传入口的统一真相。
升级边界也要在这里写清楚：如果同一个 Azure 或 connector 入口在你已经规范导出 PDF 之后还在报错，那就别再把它理解成“只是格式问题”了。此时更可能是实现没跟上、模块行为异常，或者这条入口宣称的支持范围和实际表现不一致，而不是再换一个扩展名就能解决。
什么时候 PDF 仍然是更好的格式
PDF 到今天仍然常常是对的，这也是旧建议为什么没有完全消失。真正的问题从来不是“能不能用 PDF”，而是“你是不是把 PDF 用成了一个偷懒的一刀切解释”。
OpenAI 当前一些面向文档理解的帮助说明，仍然把 PDF 视为在图表、嵌入视觉、复杂排版场景里更稳的格式。官方 API 文档也把这件事说得更清楚：非 PDF 文件也许能被接受，但非 PDF 里的嵌入图片和图表不会被提取。前一句回答的是“能不能传”，后一句回答的是“传进去之后能不能按你需要的方式被看见”。两者必须分开。
所以，真正该用 PDF 的场景通常是这几类：文件视觉结构本身很重要；你是从 Google Docs、Sheets、Slides 导出，想保住渲染结果而不是编辑结构；或者你已经确认某个具体入口现在仍然明显偏向 PDF。除此之外，不要因为网上某条 OpenAI 相关报错看起来像 PDF-only，就反过来把 PDF 当成所有文件任务的默认答案。
修好之后，怎样验证并选长期路线
文件重新被接受之后，不要把“能传了”当成全部结束。更稳的做法是按同一路径做一次短验证：
- 在同一个报错入口上，用最小修复后的文件再试一次，不要换到别的路径来掩盖原问题。
- 确认它不只是“上传成功”，还真的能完成你的任务，比如阅读、检索、或者保住你需要的视觉信息。
- 如果文件来自 Google Docs、Sheets、Slides，保留一份真正有效的导出格式，不要每次重新踩同一个坑。
- 如果问题只在某条特定 OpenAI 路径上消失，就把它记成那条入口自己的滞后问题，而不是再回到“OpenAI 现在一律只支持 PDF”这种旧叙事。
长期路线也应该跟着任务走。如果你大多数时候是在 ChatGPT 里上传普通文档，就继续用当前帮助页已经支持的导出格式；如果你反复做的是文档检索，就不要再拿一次性上传硬扛，直接走 file_search；如果你的任务核心是图表、版式、嵌入视觉，干脆把 PDF 设成那条工作流的默认格式，会比每次重新试错更省时间。
常见问题
OpenAI 现在是不是只支持 PDF？
不是。以 2026-04-08 重新核对的当前官方 OpenAI 帮助页和开发者文档为准，ChatGPT 上传和部分第一方 API 路径都支持多种非 PDF 文件。只是某些 Azure 或 connector 入口仍然可能表现得像 PDF-only。
ChatGPT 这边哪些文件类型本来就该支持？
当前 OpenAI 帮助页描述的是常见文档、演示文稿、电子表格、文本和代码文件。真正容易误踩的是 Google 原生文件，因为那类文件本来就需要先导出。
为什么 DOCX 或 PPTX 在一个 OpenAI 路径能用，在另一个又不行？
因为“OpenAI”不是一个统一的上传规则。ChatGPT 上传、当前官方 API、Azure OpenAI 和第三方 connector 到今天仍可能执行不同的规则，或者存在不同程度的滞后。
什么时候应该选 file_search，而不是 input_file？
当你的真实任务是对一组文档做检索、引用、后续追问，而不是把一份文件一次性塞进 prompt 时，就应该优先考虑 file_search。
什么时候 PDF 才是真正更优的答案？
当文档的版式、图表、示意图、嵌入视觉必须保住；当你从 Google Docs、Sheets、Slides 导出并需要渲染结果；或者当某条具体入口已经证明确实仍然偏向 PDF。
记住这条工作规则
最稳的修法不是“把所有文件都转成 PDF”，而是：先确认报错入口，再做那条入口对应的最小修复，用同一路径复验，最后才决定 PDF 是不是你的长期默认格式。