ModuleNotFoundError: No module named ‘_lzma’

快速结论：这个报错通常出现在 torchvision “已安装但实际无法导入”的环境里：is_torchvision_available() 因为只用 find_spec 探测路径而返回 True，于是 Transformers 走了 torchvision 分支，最后在导入 AutoImageProcessor 时才失败。优先确认 torchvision 本身是否真的能 import，而不是先怀疑 Transformers。

适用环境：Issue 已确认：transformers main @ c93057d 与 5.16.1；Python 3.11.15；torch 2.x；macOS arm64；CPU 复现，无需下载模型。触发场景之一为 CPython 构建时缺少 liblzma。评论中还提到 torchvision/CUDA nms 算子不匹配这类导入期 RuntimeError。

最快修复方案：暂无确认的一步修复方案。Issue 讨论中的验证性修复是在 is_torchvision_available() 中保留原有的 vision / torch / 包发现检查后，额外探测一次真实的 torchvision import，遇到 ImportError 或 RuntimeError 时返回 False；该改动未合入，属可优先尝试方向。

注意事项：该修复仅对 torchvision 这一处做真实导入探测，并未改变通用的 _is_package_available()，因为把所有可选依赖都改成真导入会显著增加开销。维护者认为“安装坏了”本身属于用户侧问题，是否把这种探测推广到其他包仍是设计层面的取舍；讨论中提到的替代最低诉求是让 _LazyModule 的报错带上根因（例如 : {e}）。

问题场景

在使用 Transformers 的图像处理相关功能时，例如执行 from transformers import AutoImageProcessor，环境里的 torchvision 处于“已被 find_spec 发现、但 import 时会抛异常”的状态。此时 is_torchvision_available() 返回 True，Transformers 据此选择 torchvision 路径，随后在惰性导入 AutoImageProcessor 时崩溃。

Issue 给出的可复现方式是：在 sys.path 中放入一个假的 torchvision 包，其 __init__.py 里 import _missing_native_extension，用来模拟 CPython 未编译 liblzma 时 torchvision 导入链挂在 _lzma 上的情况。把假包从 sys.path 移除（即 torchvision 完全缺失而非损坏）后，is_torchvision_available() 返回 False，AutoImageProcessor 反而可以正常导入。

报错原文

True
ModuleNotFoundError: Could not import module 'AutoImageProcessor'. Are this object's requirements defined correctly?

ModuleNotFoundError: No module named '_lzma'

原因分析

根因在于可用性判断的语义：_is_package_available 只调用 importlib.util.find_spec(pkg_name) 并检查 spec is not None，is_torchvision_available() 建立在这个判断之上。而 find_spec 只能证明包在 import 路径上，不能证明它真的可以被导入。

因此，当 torchvision 自身导入链失败时（例如 CPython 构建缺少 liblzma 导致 ModuleNotFoundError: No module named '_lzma'，或 torchvision/CUDA 的 nms 算子不匹配），可用性检查仍然返回 True，Transformers 于是走 torchvision 分支并最终失败。更麻烦的是，报错名字是 AutoImageProcessor 而不是 torchvision，会把人引向错误的排查方向。Issue 也指出“完全缺失”的情况降级是正确的，只有“存在但损坏”的情况不正确。

环境排查

确认 transformers 版本：Issue 中为 main @ c93057d，以及 5.16.1。
确认 Python 版本：Issue 中为 3.11.15。
确认 torch 版本：Issue 中为 torch 2.x。
确认 torchvision 是否真实可导入：单独执行 import torchvision，观察是否抛出 ModuleNotFoundError、ImportError 或 torch/torchvision 风格的 RuntimeError。
确认系统/CPython 是否具备 liblzma 支持：若 torchvision 导入链报 No module named '_lzma'，应优先检查 Python 构建本身。
确认平台：Issue 环境为 macOS arm64；评论中另提到 torchvision/CUDA nms 算子不匹配这一历史场景。

解决步骤

先单独验证 torchvision：在相同 Python 环境下执行 import torchvision。如果它本身就报 ModuleNotFoundError: No module named '_lzma' 或类似导入错误，说明问题出在 torchvision / Python 构建，而不是 Transformers。
对照复现路径确认判断语义：用 from transformers.utils.import_utils import is_torchvision_available; print(is_torchvision_available())，若输出 True 但 import torchvision 失败，即命中本 Issue 描述的行为。
处理损坏的 torchvision 安装：修复或重装能够正常导入的 torchvision；若根因是 CPython 缺少 liblzma，应从 Python 构建侧解决。
可优先尝试的代码层修复：按评论中的验证方案，在 is_torchvision_available() 内保留原有 vision / torch / 包发现检查，再对 torchvision 做一次真实 import 探测，捕获 ImportError 与 RuntimeError 并返回 False；不要在通用的 _is_package_available() 上引入对所有可选依赖的真导入。
若采用上述探测修复，需同时覆盖缺依赖导致的 ImportError、torch/torchvision 风格的 RuntimeError，以及正常导入成功的用例。
如果暂不做探测修复，讨论中提到的最低诉求是让 _LazyModule 的错误信息携带根因，例如在消息中附加 : {e}，避免只报 AutoImageProcessor 而掩盖 torchvision 的真实错误。该方向维护者表示“可以接受、值得考虑”，但未确认为最终实现。

验证方法

在修复后的判断逻辑下，原先的复现场景应从 is_torchvision_available() == True 之后 AutoImageProcessor 导入失败，变为 is_torchvision_available() == False 且 AutoImageProcessor 可以成功导入。同时应确认在 torchvision 完全缺失、torchvision 导入抛 RuntimeError、torchvision 正常可导入这三种情况下，判断结果分别符合预期。