多线程下threading.Lock()保护LibreOffice PDF转换的异常问题排查

以下是可能导致线程未执行转换却输出PDF路径的几个原因：

• 锁的作用范围不完整
  你可能只给LibreOffice转换的核心代码加了锁，但生成PDF路径、输出日志的逻辑在锁的保护范围之外。比如线程还没抢到锁，就先计算好路径并打了日志，后续锁竞争失败没执行转换，但日志已经输出了路径。要确保从检查源Word文档、生成目标PDF路径到执行转换的全流程都被threading.Lock()包裹。

• 目标路径存在旧PDF文件
  如果输出目录里本来就有同名PDF（比如之前转换残留的），线程可能误判转换成功，直接输出了已存在的路径，但实际没执行本次转换。建议在转换前先检查目标PDF是否存在，若存在则先删除或校验文件修改时间；转换完成后再验证PDF的大小、生成时间，确认是本次转换的结果。

• 锁实例未全局共享
  要是你在cont_helper函数内部创建锁（比如每次调用函数都新建threading.Lock()），这个锁根本起不到线程互斥的作用，多个线程还是会同时执行转换逻辑。必须把锁实例定义在全局作用域（比如Flask app初始化时创建），或者作为类的静态属性，确保所有线程共用同一个锁。

• 异常处理缺失
  LibreOffice转换失败时（比如文件损坏、权限不足、进程启动失败），你的代码没捕获异常，直接跳过转换步骤，但依然执行了输出PDF路径的逻辑。要给转换代码块加上try-except，捕获OSError、subprocess相关异常，一旦转换失败，就记录错误日志，不要输出路径。

• 线程创建逻辑错误
  可能你创建线程时写错了语法，比如写成threading.Thread(target=cont_helper())（多了括号），导致主线程直接执行了cont_helper函数，而线程本身没真正启动，但日志已经输出了路径；后续其他线程可能因为某种原因没执行转换，但路径已经被提前打印出来。正确写法应该是threading.Thread(target=cont_helper, args=(request_id,))，确保target指向函数对象而非调用结果。

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