为何我的Python脚本在批处理调用GhostScript生成PDF后执行异常？

核心场景匹配 #

你遇到的「手动跑Python正常、批处理调用dummy Python正常、批处理调用正式Python失效、日志显示命令已执行」的特征，对应四类高频触发原因，按排查优先级排序如下：

1. 批处理环境唤起了错误版本的Python解释器 #

• 批处理中直接写"%~dp0\test.py"是依赖Windows的文件关联机制唤起Python，这个关联指向的Python解释器，和你手动开控制台跑脚本时用的解释器，可能并不是同一个解释器路径映射目标。
• 因为dummy测试脚本没有第三方依赖，哪怕唤起错Python也能正常运行；但你的正式脚本依赖rmapy这类第三方库，如果唤起的解释器根本没装对应依赖，脚本会直接抛ImportError退出。
• 修复方式：
  • 先在你手动跑Python正常的控制台执行where python，拿到当前生效的Python解释器全路径
  • 把批处理中调用Python的行替换为显式指定解释器的写法，不要依赖文件关联：

    "拿到的Python全路径" "%~dp0\test.py"
    

2. 运行上下文权限差异导致配置读取失败 #

• rmapy的认证token默认存储在当前Windows用户的家目录配置路径下，如果批处理是通过管理员权限、计划任务、其他用户会话启动的，Python脚本会读取不到你之前手动在普通用户会话下留存的认证信息，直接在rm.renew_token()步骤抛错退出。
• 因为你现在的批处理没有捕获Python的错误输出，所有stderr报错都会被吞掉，看起来就像脚本正常执行但没有效果。
• 修复方式：
  • 在批处理调用Python的行末尾追加错误捕获逻辑，把所有Python运行输出、报错写入本地日志，直接定位错误行：

    "Python解释器路径" "%~dp0\test.py" %result%.pdf 2>&1 >> "%~dp0\py_run.log"
    

  • 确保批处理的启动权限和你手动跑Python的权限完全一致，不要用管理员身份启动批处理。

3. 传参与路径匹配的时序错误 #

• 你现在传给Python的PDF参数是不带全路径的相对值，且没有做路径存在性校验：
  • 如果GhostScript生成PDF的流程因为权限、路径问题失败，批处理会立刻启动Python处理不存在的空PDF文件，直接加载失败
  • 如果路径中包含空格，没加引号的传参会被拆成多个参数，导致Python拿不到正确的PDF路径
• 修复方式：
  • 给传入Python的PDF参数补全全路径，并用双引号包裹避免空格拆参：

    "%~dp0\%result%.pdf"
    

  • 在Python脚本中新增PDF存在性校验，提前把路径、状态打印到日志：

    for arg in sys.argv[1:]:
        pdf_abs_path = os.path.abspath(arg)
        print(f"当前处理的PDF路径：{pdf_abs_path}，文件存在：{os.path.exists(pdf_abs_path)}")
        # 后续原有逻辑
    

4. 批处理连接符语法逻辑错误 #

• 你现在批处理中使用&作为命令连接符，这个语法的逻辑是无前置校验，不管上一条GhostScript命令执行成功还是失败，都立刻执行后续Python脚本，不会检查GhostScript的返回码。
• 哪怕GhostScript生成PDF失败、输出的PDF文件损坏，批处理也会照常调用Python，最终因为PDF无效导致上传失败。
• 修复方式：把连接符替换为&&，只有GhostScript执行返回成功（返回码为0）时，才继续执行后续Python调用，避免无效链路提前触发：

  "%PROGRAMFILES%\gs\gs9.54.0\bin\gswin64c.exe" ... 原有GS参数 ...
  && "Python解释器路径" "%~dp0\test.py" "%~dp0\%result%.pdf" 2>&1 >> "%~dp0\py_run.log"
  

按照上述步骤排查后，所有Python运行的报错都会被收集到日志文件中，可以直接定位到具体的失败行，不需要额外猜测。

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