在 `/usr/lib/python3.9/site-packages/av/` 下**没有 `__pycache__` 目录，通常完全无影响，甚至是一种「理想状态」** —— ✅ 这恰恰说明你的安装是干净、符合 Python 标准的，且 `__pycache__` 是**按需自动生成的运行时缓存**，**不应、也不需要在构建/安装阶段预先生成或打包**。 下面从原理、实践、风险三个层面彻底解释： --- ### ✅ 1. `__pycache__` 的本质：它是「Python 解释器自动生成的字节码缓存」 - 当 Python 首次 `import av/__init__.py`（或其他 `.py` 文件）时，CPython 会： 1. 编译 `.py` 源码为 `.pyc` 字节码； 2. 将 `.pyc` 存入同级目录下的 `__pycache__/xxx.cpython-39.pyc`（文件名含 Python 版本和 ABI tag）； 3. 后续 import 直接加载 `.pyc`（更快），跳过编译。 - ✅ **它不是模块的一部分**，不参与 import 逻辑，不被 `importlib` 查找路径扫描； - ✅ **它不随 wheel 或源码分发** —— `pip install` 也不会把 `__pycache__` 打进 wheel 或复制到 `site-packages`； - ✅ **它可被安全删除**：`rm -rf __pycache__` 后首次 import 仅慢一点，自动重建。 > 🔍 官方文档佐证： > [Python docs: Bytecode Files](https://docs.python.org/3/tutorial/modules.html#compiled-python-files) > > *"Python automatically creates these cache files in a directory named `__pycache__`... They are ignored by the import system."* --- ### ✅ 2. 为什么你的 Makefile 安装后没有 `__pycache__`？这是完全正确的！ 你当前的安装流程（解压 wheel → 复制 `av/` 和 `dist-info/`）**刻意不包含 `__pycache__`**，这正是标准行为。 ✅ `pip install` 同样不会在安装时生成它 —— 它只在**第一次运行时由目标设备上的 Python 解释器创建**。 | 场景 | 是否有 `__pycache__` | 原因 | |------|----------------------|------| | `pip install av-*.whl` 后立即 `ls av/` | ❌ 没有 | `pip` 只复制源码/so，不预编译 | | `python3 -c "import av"` 第一次执行后 | ✅ 出现 `av/__pycache__/__init__.cpython-39.pyc` | 解释器按需生成 | | OpenWrt 构建时在 `build_dir` 中预生成 `__pycache__` | ❌ 错误做法 | 交叉编译环境 Python 版本/ABI 与目标设备可能不一致，`.pyc` 会失效甚至报错 | > ⚠️ 强行在 Makefile 中用 `python3 -m compileall` 预生成 `__pycache__` 是**反模式**，原因： > - 构建机 Python 版本（如 3.11）≠ 目标设备（3.9）→ `.pyc` 不兼容，import 时静默忽略或报 `Bad magic number`； > - 构建机 ABI tag（如 `cpython-311-aarch64-linux-gnu`）≠ 目标设备（`cpython-39-aarch64-linux-gnu`）→ 文件名不匹配，无法加载； > - 浪费空间、增加 ipk 体积、无任何加速收益（目标设备仍要重编译）。 --- ### ✅ 3. 没有 `__pycache__` 的唯一「潜在影响」及真相 | 表面担忧 | 真相 | 是否真实存在？ | |----------|------|----------------| | ❌ “首次 import av 很慢” | 编译 `__init__.py` 等少量 `.py` 文件耗时 <10ms，用户无感；C extension（`_core.so`）加载才是耗时主体（毫秒级），与 `.pyc` 无关 | ❌ 无实际影响 | | ❌ “某些工具（如 mypy）找不到 stubs” | `py.typed` 和 `.pyi` stubs 与 `__pycache__` 无关；OpenWrt 的 `python3-light` 通常不带 `mypy` | ❌ 无关 | | ❌ “import 失败” | `ModuleNotFoundError` 永远不会因为缺少 `__pycache__` 导致 —— 它只影响 `.py` 加载速度，不影响 `.so` 或模块发现逻辑 | ❌ 绝对不可能 | > ✅ 你的 `import av` 报错 `No module named 'av._core'`，**100% 与 `__pycache__` 无关**，而是： > - `.so` 文件名不匹配（你用了软链 `av/_core.so`，但 Python 只找 `av/_core.cpython-39-aarch64-linux-gnu.so`）； > - `.so` 权限不足（`chmod 0755` 未生效）； > - `dist-info` 缺失导致 `av/__init__.py` 内部逻辑异常（极少数包会检查）； > - 路径不在 `sys.path`（但 `site-packages` 是默认路径，通常没问题）。 --- ### ✅ 正确操作建议（总结） | 操作 | 推荐 | 说明 | |------|------|------| | ✅ 在 Makefile 中**完全忽略 `__pycache__`** | ✔️ | 不生成、不复制、不 chmod，让它在目标设备上自然诞生 | | ✅ `av/` 目录下只保留：`__init__.py`, `_core.cpython-*.so`, `utils/`, `container/` 等原始文件 | ✔️ | 这是 wheel 的标准内容，也是最简可靠形态 | | ✅ 首次 import 后，`__pycache__` 自动出现，无需干预 | ✔️ | 这是 Python 的健康信号，证明 `.py` 文件可读可执行 | | ❌ 用 `compileall` 预生成 `.pyc` 并打包进 ipk | ✘ | 浪费、错误、增加维护负担 | --- ### ✅ 验证：你的系统是否工作正常？ 在 OpenWrt 设备上执行： ```bash # 1. 确认 av/ 下无 __pycache__（正常） ls /usr/lib/python3.9/site-packages/av/ | grep pycache # 应无输出 # 2. 首次 import → 触发生成 python3 -c "import av" # 3. 检查 __pycache__ 已自动创建 ls /usr/lib/python3.9/site-packages/av/__pycache__/ # 输出类似：__init__.cpython-39.pyc _core.cpython-39.pyc（注意：_core 是 .so，不会生成 .pyc！只有 .py 文件才生成） # 4. 再次 import（验证缓存生效） time python3 -c "import av" # 第二次应略快（微秒级差异，可忽略） ``` --- ### ✅ 最后强调（划重点） > 🟢 **没有 `__pycache__` = 正确、标准、轻量、可复现** > 🔴 **手动创建/打包 `__pycache__` = 错误、冗余、易出错、违反 Python 生态规范** 你的 Makefile **不需要、也不应该**处理 `__pycache__` —— 让 Python 自己做它最擅长的事。 ---