这个坑值得记一笔。把 PDF 读成字节后放进 inline_data，mime_type 写成 application/pdf，返回 400，提示 Unsupported MIME type，文件大小 12 MB，换成小文件同样报错。
刚开始盯着「上传后引用的是 file_data，不是 inline_data」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。inline_data 的 mime_type 必须与文件真实类型完全一致；大文件应走 Files API 上传，而不是内联传字节；PDF 本身是加密文件，解析阶段就被判为不可用。
动手时先用 Files API 上传并拿到文件 uri
curl -X POST "https://generativelanguage.googleapis.com/upload/v1beta/files?key=$KEY" -H "X-Goog-Upload-Header-Content-Type: application/pdf" --data-binary @doc.pdf请求里改用 file_data 引用上传结果
part = {'file_data': {'mime_type': 'application/pdf', 'file_uri': uri}}内联小文件时确认 mime_type 拼写
python -c "import mimetypes;print(mimetypes.guess_type('doc.pdf'))"末了检查 PDF 是否加密，必要时先解密
python -c "import fitz;print(fitz.open('doc.pdf').is_encrypted)"这类问题以前遇到过，但这次的触发条件和上次不一样。
改完先别撤，确认这几项。请求返回 200，模型能回答 PDF 第二页表格里的数字，不再提示 MIME 类型不支持。
同一份文件上传后会有激活延迟，刚传完立刻引用偶尔报文件不可用，等一两秒再发请求即可，重传反而会占用存储配额。报错文案容易误导，真正的原因往往在相邻那一层的日志里。