为什么 sudo 运行 Python 时找不到 board 模块？

使用 sudo 后找不到 board，通常是因为运行脚本的 Python 解释器变了。普通用户使用的是 venv 中的 Python，sudo python 则可能调用系统 Python，两个环境中的依赖不同。

如果当前硬件访问方式确实需要 root 权限，可以让 sudo 显式调用 venv 中的 Python。是否必须使用 root，还需要结合脚本所用的底层驱动判断。

为什么加上 sudo 后报错更早了？

激活 venv 后，当前 shell 会调整 PATH，让 python 优先指向虚拟环境的解释器。sudo 通常会按自身配置处理环境变量和命令搜索路径，因此 sudo python 不一定使用同一个解释器。

两次报错发生在不同阶段：

• 普通用户运行时，脚本已经通过模块导入，直到访问 /dev/mem 才遇到权限错误。
• 使用 sudo 后，当前 Python 环境找不到 board，脚本在导入阶段就停止了。

报错提前并不说明 root 权限更少。应先确认两次运行使用的 Python 环境是否一致。

先确认解释器和模块位置

在已经激活、能够导入 board 的 venv 中执行：

python -c "import sys, board; print(sys.executable); print(sys.prefix); print(board.__file__)"

命令会输出解释器路径、环境前缀和 board 模块的位置。再查看 sudo python 对应的环境：

sudo python -c "import sys; print(sys.executable); print(sys.prefix)"

重点比较解释器路径和 sys.prefix。如果这些值不同，就能确认两条命令没有使用同一个 Python 环境。

让 sudo 使用虚拟环境的 Python

如果通过标准的 venv 激活脚本进入了虚拟环境，可以先检查：

printf '%s\n' "$VIRTUAL_ENV"

确认输出不为空，且是目标 venv 的路径，再执行：

sudo "$VIRTUAL_ENV/bin/python" leds/led_controller.py

$VIRTUAL_ENV 会由当前 shell 在调用 sudo 前展开，因此传给 sudo 的是明确的解释器路径。

也可以直接使用前面 sys.executable 输出的绝对路径。下面的路径需要替换为实际值：

sudo /absolute/path/to/venv/bin/python leds/led_controller.py

可以先验证提升权限后是否仍能导入模块：

sudo "$VIRTUAL_ENV/bin/python" -c "import sys, board; print(sys.executable); print(board.__file__)"

如果导入成功，再运行完整脚本，继续检查硬件访问。

如果仍然报错，分别处理依赖和硬件权限

如果明确指定 venv 的解释器后仍找不到 board，需要确认该环境是否就是之前运行成功的环境，并按脚本的依赖说明检查安装情况。安装依赖时使用目标环境的 python -m pip，可以避免 pip 指向其他 Python 环境。导入名称也不一定等于安装包名称，不能仅凭 import board 就认定应安装名为 board 的包。

如果模块导入成功，但仍然无法访问 /dev/mem，则要检查底层库使用的硬件访问方式及其权限要求。现有信息没有提供完整脚本、驱动和 Raspberry Pi 型号，无法确定是否存在适合该环境的非 root 运行方式。

此前 GPIO 17 不合法的问题也需要单独检查。引脚是否受支持取决于所用库、驱动和硬件，切换到 GPIO 18 并不能解决 Python 模块搜索路径的问题。

备注：内容仅供参考。