Python在只读文件系统下启动时因site模块尝试写入用户site目录（如~/.local/lib/python*/site-packages）而触发PermissionError，根本原因是默认启用用户site路径且未适配只读环境；解决方式包括启动时加-s参数、设PYTHONNOUSERSITE=1环境变量，或构建阶段预装依赖到可读路径。
为什么 sys.path 在只读文件系统下会报错“Permission denied”
Python 启动时默认把当前目录（.）、用户 site-packages（~/.local/lib/python*/site-packages）等路径加入 sys.path。如果应用部署在只读根文件系统（如容器 rootfs、immutable OS），而代码又调用了 pip install --user 或意外触发了 site 模块的用户路径自动启用，Python 就会在导入阶段尝试检查或写入这些路径（比如生成 .pth 文件缓存、写入 easy-install.pth），直接触发 PermissionError: [Errno 13] Permission denied。
这不是 import 本身的问题，而是 site 初始化阶段的副作用。
- 典型错误现象：
ImportError: cannot import name 'main' from 'pip'或启动时卡在import site后的权限拒绝 - 关键线索：错误堆栈里出现
site.py、USER_SITE、getusersitepackages() - 根本原因：Python 默认启用用户 site 目录，且未做只读适配
禁用用户 site 目录的三种可靠方式
必须从 Python 解释器启动源头切断用户路径加载，仅保留系统级和显式指定的路径。
- 启动时加
-s参数：运行python3 -s your_app.py，强制跳过site模块初始化（包括用户 site 和 .pth 处理） - 环境变量
PYTHONNOUSERSITE=1：比-s更灵活，适合容器ENV或 systemdEnvironment=配置 - 在代码最顶端插入
import sys; sys.flags.no_user_site = True—— 不推荐：必须在任何import（包括隐式）之前执行，极易被__future__或编码声明打断，不可靠
推荐组合：容器 Dockerfile 中设 ENV PYTHONNOUSERSITE=1，并确保入口命令不带 --user 类参数；若用 uWSGI/Gunicorn，额外加 --disable-threads（避免某些插件偷偷触发 site）。
立即学习“Python免费学习笔记（深入）”；
依赖必须预装到可读路径，不能依赖运行时 pip
只读系统意味着你无法在容器内或生产机器上执行 pip install。所有依赖必须在构建阶段完成安装，并落盘到只读路径（如 /usr/local/lib/python3.x/site-packages）。
- 不要用
pip install --target /app/deps然后手动加sys.path.insert(0, '/app/deps')：这绕过了 wheel 元数据校验，可能引发ImportError: cannot import name '...' from 'pkg'（因pyproject.toml中的 optional deps 或extras_require未解析） - 正确做法：在构建镜像时用
pip install -t /usr/local/lib/python3.x/site-packages -r requirements.txt，或更稳妥地用pip install --prefix /usr/local（让 pip 自动处理路径和 scripts） - 验证方式：启动容器后执行
python3 -c "import pkg_resources; print([p for p in pkg_resources.working_set])"，确认所有包来源路径是/usr/local/...而非/root/.local/...
注意 venv 在只读系统中的陷阱
看似 venv 是隔离方案，但它默认启用 system-site-packages=False，且激活脚本会修改 PYTHONPATH 和 sys.path，部分实现（如旧版 venv 或某些定制解释器）仍会尝试写入 pyvenv.cfg 或 pip 的缓存目录。
- 风险点：即使 venv 目录本身只读，
pip在首次运行时仍可能尝试创建$HOME/.cache/pip或写入 venv 内的pip-selfcheck.json - 安全做法：构建时用
python3 -m venv /opt/venv --system-site-packages，然后source /opt/venv/bin/activate && pip install -r requirements.txt；运行时用/opt/venv/bin/python启动，并配PYTHONNOUSERSITE=1 - 更轻量替代：放弃 venv，直接用系统 Python +
--prefix安装，配合pyenv构建专用解释器（需编译时指定--enable-shared和只读前缀）
真正麻烦的从来不是 import 语句本身，而是那些藏在 site、pip、venv 底层的隐式路径探测和写入尝试——它们往往在第一次 import 第三方包时才爆发，而且错误信息离真实原因很远。
