subprocess.run() 是调用 pip 安装模块最可靠方式，需用 sys.executable、check=True、--user 和 importlib.util.find_spec 验证存在性，禁用运行时安装。
用 subprocess 调用 pip 安装模块最可靠
直接在运行时调用 pip，subprocess 是唯一推荐方式。Python 的 os.system 或 os.popen 缺少错误捕获能力，而 pip.main() 在 pip 10+ 已被移除，强行调用会抛出 AttributeError: module 'pip' has no attribute 'main'。
实操建议：
- 始终用
subprocess.run()，并显式指定check=True，让异常暴露安装失败 - 使用
sys.executable而非硬编码"python"或"pip"，避免虚拟环境或多 Python 版本下调用错解释器 - 加
--quiet减少输出干扰，但首次调试建议先去掉，确认路径和权限是否正常
import subprocess
import sys
def install_package(pkg):
try:
subprocess.run([sys.executable, "-m", "pip", "install", "--quiet", pkg], check=True)
except subprocess.CalledProcessError:
raise ImportError(f"Failed to install {pkg}")
模块导入前检查是否存在，再决定是否安装
不能无条件执行 pip install，否则每次运行都重装、卡住、或触发权限错误。必须先验证模块是否可导入，再触发安装逻辑。
常见错误现象：ModuleNotFoundError 报错后直接调 pip，但没捕获后续 import 是否成功，导致“装了却仍报错”。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 用
importlib.util.find_spec(pkg_name)判断模块是否存在，比try/except ImportError更轻量（不实际加载模块） - 若需支持子模块（如
requests.packages.urllib3），要对点号分段处理，只检查顶层包（"requests"） - 不要在循环里反复检查同一模块——缓存已尝试安装的包名，避免重复调用 pip
权限与用户安装模式必须显式控制
在没有 root/admin 权限的环境（如共享服务器、CI runner、某些 macOS 系统）下，直接 pip install 会报 PermissionError: [Errno 13] Permission denied。
实操建议：
- 默认加
--user参数，把包装到用户目录（~/.local/lib/pythonX.Y/site-packages），绕过系统级写入限制 - 如果项目明确要求全局安装（如 Docker 构建阶段），应提前确保容器以 root 运行，或在
Dockerfile中用RUN pip install预装，而非运行时动态装 - 注意
--user安装后，Python 必须能识别该路径——某些旧版 Python 需手动加site.USER_SITE到sys.path，但现代版本（3.6+）通常自动处理
生产环境强烈不建议运行时调 pip
这不是技术能不能做到的问题，而是部署稳定性的红线。动态 pip 安装会引入不可控变量：网络波动、PyPI 暂不可用、包版本漂移、依赖冲突升级、甚至恶意包注入（若 pkg 名来自外部输入）。
容易被忽略的关键点：
-
requirements.txt应覆盖全部依赖，CI 流程中用pip install -r requirements.txt --no-deps验证完整性 - 若真有“插件式”扩展需求（如用户上传自定义模块），应限定为本地路径加载（
importlib.util.spec_from_file_location），而非联网安装 - 调试时临时用 pip 补包可以，但上线前必须把所有
install_package()调用删掉，并补进依赖声明
