一份 60 页的扫描档案，点上传才发现一次最多识别 10 页。这不是刻意限制，是同步处理的物理边界：服务器要把每页渲染成图片、逐页调用识别，PHP 单次请求大约 120 秒就会超时。页数再多不是慢一点，是直接失败。

所以真正要解决的是：怎么分，才能既跑完又不搞乱顺序、不多花页数。

先算总数，再决定分几批

上传前先做一件花 20 秒的事：看清这份 PDF 一共多少页。

  • 60 页 → 6 批，每批 10 页
  • 45 页 → 5 批，其中一批 5 页（不要平均分成 9 批 5 页，批次越多，合并时出错的机会越多）
  • 25 页 → 3 批（10 + 10 + 5）

同时算额度：识别不向游客开放，注册（短信验证码登录即完成注册）一次性送 5 点、永久有效，VIP 会员每月另有 20～120 点配额（当月不结转）。60 页的量，注册账号要分六天，会员三天 —— 要么提前买页数包（页数包永久有效、不过期），要么把批次安排到几天里。别在第一天就按游客额度开跑，那是最慢的路径。

空白页也会消耗 1 页额度（识别前无法预知是否空白），所以能先删空白页就先删，这一步能省下的页数经常超出预期。

怎么拆：拆 PDF，不要在上传时挑页

扫描件PDF转Word 是按整份文件识别的，没有「只识别第 11 到 20 页」这个选项。所以必须先把 PDF 拆开。

用 PDF 拆分 按页范围切成每份不超过 10 页。拆分这一步不消耗识别页数，它属于普通转换额度：免费用户每天 5 次转换、VIP 会员不限次，单文件大小免费 8MB、VIP 月卡 20MB、半年卡 30MB、年卡/银卡/金卡 50MB。

命名是这批操作里最容易出错的地方。 拆完的文件如果叫「未命名(1).docx」，六批做完你就再也分不清先后了。拆之前先把原 PDF 改成一个有序前缀的名字，例如「档案01-2026-合同甲」，这样每一批的输出文件名都自带位置信息。批量改名做法见 几百张照片批量改名：日期、序号与场景的命名方案。

合并：顺序检查不能省

六批做完会得到六个 docx，通常要合成一份。顺序错误是分批操作唯一真正的风险，而且它不会报错。

正确的合并方式：先另存一份空文档，按编号顺序依次插入，插一份就立刻翻到接缝处看页码对不对。不要凭文件名记忆排序，把六个文件依次打开确认第一页内容再排。

接缝处专查两项：页码是否连续，以及上一批最后一句和下一批第一句是不是同一句话被拆成两半（分批识别时，一句被切断是正常的，因为批次之间模型没有上下文）。后者要手工接回去，处理办法见 识别出来的文字全是断行和页眉页脚？三步清理比手工删快十倍。

一个能少分批的思路：先抽要的部分

很多扫描件不需要全文电子化。 60 页档案里真正要改的可能只有 8 页。

先花五分钟通读，把要处理的页挑出来单独转成 PDF，再识别 —— 一次就跑完了，还省掉五分之四的页数。抽页的做法见 从长 PDF 里抽出几页转成 Word：页码定位与范围填写的要点 和 只想取 PDF 里的某一页？不用拆分整个文件。

这个顺序很重要：先减量，再分批，反过来就是把 60 页都识别了一遍再去删。

最后：识别失败不扣点数

拿不准某一批会不会成功时，可以直接提交试 —— 供应商报错、图片无法解码这类失败不扣页数，已扣的会退回。但整份文件本身有问题的（加密、损坏、渲染不出页面）要先生效处理：加密 PDF 需先解密，具体见 加密的 PDF 怎么转 Word？分两种密码，处理方式完全不同。