Delphi调用Microsoft Print To Pdf如何判断生成的PDF文件就绪

thread.onTerminate触发时仅代表你业务线程内的页面生成逻辑、以及printer.endDoc的调用流程走完——此时打印数据只是被提交到了Windows打印后台处理服务（print spooler）队列，虚拟PDF打印机还没完成数据渲染、磁盘写入操作，这时候调用shellExecute打开文件，读到的自然是未写完的不完整内容。固定等10秒能正常打开只是刚好覆盖了当前环境下的spooler处理耗时，不是通用可靠方案。

• 优先方案：监听打印后台队列的任务完成状态
  调用printer.beginDoc时记录本次打印任务的JobID，通过Windows打印API轮询或订阅打印任务状态变更事件，直到对应JobID的任务被标记为JOB_STATUS_COMPLETE、且从打印队列中移除后，再执行文件打开操作。这个方案完全匹配实际打印处理耗时，不需要硬编码延时，准确率最高。
  注意不要把printer.endDoc返回作为处理完成标记，该节点仅代表应用侧完成了打印数据提交，和系统侧打印处理、文件写入完成没有关系。
• 兼容方案：文件锁+文件大小校验
  如果不方便调用打印spooler相关API，可以实现轻量检测逻辑：每间隔200ms尝试以独占读写权限打开目标PDF文件，若打开失败说明文件仍被PDF打印机进程占用写入；当可以成功独占打开，且连续两次检测到文件大小不再变化时，即可判定文件写入完成。记得给检测逻辑加30秒左右的超时阈值，避免异常场景下程序无限等待。
• 驱动原生方案：使用虚拟PDF打印机自带的完成回调
  如果你使用的是Microsoft Print to PDF这类系统自带PDF打印机，或是第三方商用PDF打印组件，绝大多数这类驱动本身暴露了打印完成的回调事件，直接使用驱动自带的完成通知，可靠性高于自行实现的轮询逻辑。

• 不要使用固定时长等待的方案：不同设备性能、PDF文件页数、系统负载都会影响打印处理耗时，固定等待时间过短仍会出现文件损坏问题，过长则会拖慢用户操作流程。
• 不要依赖业务线程的生命周期判断完成状态：你自己实现的页面生成逻辑跑完后，后续的渲染、文件写入动作是在系统spooler服务、虚拟打印驱动的独立进程中执行的，和你的业务线程是否终止没有关联。

内容的提问来源于stack exchange，提问作者PekiCa