WordPress调用Python脚本中途停止 生成PDF不完整问题咨询

这个无报错中途终止、输出PDF不完整的现象，内存溢出是高概率诱因，但不是唯一可能，本质是进程被外部信号强制杀死，Python解释器来不及捕获异常、执行收尾逻辑，就会出现你观察到的现象：没有报错栈，输出的文件只写入了部分内容。

• 首先确认是否为内存问题
  WordPress触发的脚本默认运行在Web服务的请求生命周期内，会受两层内存限制：一是PHP/WordPress配置的memory_limit，二是Linux系统的OOM Killer机制。当进程内存占用触达阈值时，系统会直接发送SIGKILL信号强杀进程，这个信号无法被Python层捕获，自然不会抛出任何错误。
  验证方法：脚本运行时在服务器执行dmesg -T | grep -i oom，如果输出里有对应Python进程被OOM Killer终止的记录，就能确认是内存问题。也可以在脚本里加埋点，每处理完一张图片就打印当前进程的内存占用，观察内存是否随处理量线性上涨、到某个固定值就出现进程退出。
• 第二类高概率原因：超时强杀
  Nginx/Apache的proxy_read_timeout、PHP的max_execution_time、WordPress内置WP_CRON的默认超时阈值大多在30-60秒，处理多张大分辨率图片合成PDF很容易超出这个时长，Web服务会直接断开请求、回收关联的子进程，同样不会给脚本抛出异常的机会。
  验证方法：把待合成的图片缩减到2-3张小分辨率图测试，如果能生成完整PDF，处理图片量上去就复现故障，基本就是超时导致的。
• 代码写法导致的内存异常上涨
  多数人用Pillow、img2pdf等库合成PDF时，会习惯把所有图片一次性全部加载到内存再做合并，单张高清图解压后占内存可达数百MB，几十张图就能占满数G内存；如果打开的图片对象没有手动关闭，内存无法及时回收，也会越跑内存占用越高。
  建议改成增量写入的逻辑，不要一次性加载全部资源，参考写法：

  from PIL import Image
  import os
  
  def merge_to_pdf(img_paths, output_path):
      # 处理首页
      with Image.open(img_paths[0]) as im:
          first_page = im.convert('RGB')
      temp_pages = []
      # 逐张处理后续页面，分批写入释放内存
      for path in img_paths[1:]:
          with Image.open(path) as im:
              temp_pages.append(im.convert('RGB'))
          # 每处理8张就追加写入PDF，清空临时缓存
          if len(temp_pages) >= 8:
              first_page.save(output_path, save_all=True, append_images=temp_pages, append=os.path.exists(output_path))
              for p in temp_pages:
                  p.close()
              temp_pages.clear()
      # 写入剩余页面
      if temp_pages:
          first_page.save(output_path, save_all=True, append_images=temp_pages, append=os.path.exists(output_path))
          for p in temp_pages:
              p.close()
      first_page.close()
  

• 触发逻辑的根本缺陷
  不要在WordPress前台请求、默认WP_CRON的上下文里跑这类长耗时任务，WordPress的请求生命周期从设计上就不支持长任务运行。收到WordPress的合成请求后，先把任务信息写入独立的任务队列表，用系统守护进程、crontab或者Celery这类队列服务，拉起独立的Python CLI进程在后台跑任务，完全脱离Web请求的生命周期，既不会被超时、内存阈值误杀，也可以单独给脚本配置更高的内存限制，等PDF生成完成后再把结果回写到WordPress站点即可。

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