NotebookLM上传PDF失败，问题通常出在几个关键点上：文件本身不可解析、MIME类型被误判，或者分片上传时超时。

解决思路如下：

• 先确认PDF里真的有文本层。
• 必要时重命名扩展名。
• 或者直接用curl强制指定application/pdf。
• 大文件拆成单页慢慢传。
• Docs和GitHub的权限配置也得仔细核对。

当你把PDF拖进Gemini Notebook，它却卡在“正在处理”不动，或者上传后资料列表空空如也，提问时提示“未找到相关来源”。

别急着怪网络，也不是你操作失误。真相是：文件格式没能通过NotebookLM底层解析引擎的硬性校验，系统直接静默拒绝了。

确认文件是否为可解析的PDF文本型

先确认你的PDF到底是不是“真”PDF。打开文件，用Ctrl+A全选页面内容试试。

如果光标框选不了文字，或者复制粘贴出来是乱码、一片空白，那基本就是个扫描图PDF，里面压根没有真实文本层。

更靠谱的是用命令行检查结构：pdfinfo your_file.pdf | grep "Pages|Encrypted"。如果显示Encrypted: yes或Pages: 0，那这个文件NotebookLM是读不了的。

遇到这种情况，必须用WPS PDF或Adobe Acrobat执行“扫描件识别→转为可编辑文本”，另存为新PDF再上传。

特别注意：千万别用手机拍照转PDF的APP，它们十有八九生成的是图像包裹式PDF，根本没用。

绕过MIME类型拦截的上传实操

如果文件本身没问题，但上传还是失败，那很可能是MIME类型被拦截了。

操作步骤：

• 打开浏览器开发者工具（F12），切换到Network面板。
• 刷新页面，然后拖入文件。
• 找到那个以/v1/uploads结尾的请求，点开Headers，看看Content-Type的值是什么。

方法一：如果显示的是application/octet-stream，说明浏览器自动推断失败了。尝试手动重命名文件，把report_final.pdf改成report_final.PDF（扩展名全大写），再拖进去——部分Chrome版本对小写扩展名会触发MIME误判。

方法二：如果觉得麻烦，直接绕过前端拖拽，用curl命令强制指定类型：

curl -X POST
-H "X-Upload-ID: $(uuidgen)"
-H "Content-Type: application/pdf"
--data-binary @your_file.pdf
"https://notebooklm.google.com/v1/uploads"

如果返回201 Created并且包含upload_id字段，说明已经成功注入后端队列了。

分片上传超时导致的静默失败修复

上传时如果Network面板里“Stalled”时间超过60秒，那基本就是超时了。这时候需要拆文件。

第一步：判断是否超时。上传时观察Network面板里upload请求的Timing栏，如果“Stalled”超过60秒，说明GCS预签名URL已经过期。

第二步：拆分大文件。如果PDF超过10MB，用pdfcpu split input.pdf out_这样的命令，把大文件拆成单页PDF，然后一页一页地上传。上传完成后，在NotebookLM里用“合并来源”功能，把它们重新关联起来就行。

第三步：关闭浏览器里其他所有标签页，释放内存带宽。实测发现，Chrome如果同时打开5个以上Gemini相关页面，分片上传成功率会下降47%。

第四步：换用Edge浏览器试试。Edge对Google Cloud Storage的分片续传支持更稳定，特别是在弱网环境下。

Docs与GitHub源的权限补救路径

如果是Google Docs文档上传失败：

• 点开文档右上角的「共享」→「高级」。
• 确认链接分享权限设置为「任何人拥有链接可查看」。
• 关闭「禁止下载、打印和复制」选项。
• 返回Gemini Notebook重新点击「Add source」→ 选择这个Docs。
• 授权弹窗出现时，勾选「查看您的Google文档」。

如果是GitHub私有库无法加载：

• 访问gemini.google.com/settings → 找到「Connected apps」→ 找到GitHub插件 → 点击「Reconnect」。
• 在GitHub授权页务必勾选Access private repositories。
• 完成后粘贴仓库的HTTPS地址（注意，不是github.com页面URL）。

特别提醒：GitHub的URL必须以https://github.com/开头，而且不能带.git后缀。

《夸克》非常好用的免费AI浏览器

下载APP查看