使用--system-site-packages参数可使venv环境继承系统site-packages中的包，但必须创建时指定，修改pyvenv.cfg无效；激活后需用import+__file__或pip list -v验证是否生效。
使用 --system-site-packages 参数创建虚拟环境
默认情况下，python -m venv 创建的环境完全隔离，不访问系统 site-packages。要让虚拟环境能直接使用系统已安装的包（比如预装的 numpy、opencv-python-headless、jetson-gpio 或 CUDA 加速库），必须显式加 --system-site-packages 参数。
常见错误是创建后再改配置——pyvenv.cfg 中的 include-system-site-packages = false 是只读结果，不是开关；改了也不会生效，必须重建环境。
- 正确做法：创建时就指定参数，例如
python3 -m venv --system-site-packages .venv - 如果已创建普通环境，删掉再重来，不要试图“补救”：
rm -rf .venv（mac/Linux）或rmdir /s .venv（Windows） - 注意路径权限：某些系统级包（如
tensorrt）依赖特定 ABI 或 CUDA 版本，即使包含进来了，运行时仍可能报ImportError: libcudnn.so.8: cannot open shared object file—— 这属于系统环境缺失，不是 venv 配置问题
激活后如何确认系统包是否可用
激活环境后，不能只靠 pip list 判断——它默认只显示在虚拟环境中安装的包，不显示继承来的系统包。真正验证方式是直接 import 并检查 __file__ 路径。
例如：
python -c "import numpy; print(numpy.__file__)"
若输出类似 /usr/lib/python3/dist-packages/numpy/__init__.py，说明用的是系统包；若输出 .venv/lib/python3.x/site-packages/numpy/__init__.py，说明是 pip 重新装的副本。
-
pip list -v会显示每个包的来源路径，比pip list更可靠 - 系统包不会出现在
pip freeze输出里，所以requirements.txt不会记录它们——部署到其他机器时需单独处理 - 某些包（如
setuptools、wheel）仍会优先使用虚拟环境自带的版本，即使系统有更新版
什么时候不该用 --system-site-packages
这个参数不是万能钥匙，滥用反而破坏隔离性。典型不适用场景：
- 项目需要严格复现（CI/CD、Docker 构建）：系统包版本不可控，不同机器上
import cv2可能加载不同 ABI 的 OpenCV - 团队协作且成员系统环境差异大（有人用 Ubuntu，有人用 macOS，有人用 JetPack）：系统包名、路径、甚至 ABI 都不一致
- 你正在调试包冲突问题：引入系统包会让问题更难定位，比如
ImportError: cannot import name 'xxx' from 'y'可能来自系统旧版 y - 安全敏感场景（如金融、嵌入式）：系统包未经过项目级审计，可能含已知漏洞
Windows 上的特别注意事项
Windows 下启用 --system-site-packages 后，行为和类 Unix 系统略有不同：系统 site-packages 目录会被追加到 sys.path 开头，但部分 C 扩展（尤其是带 DLL 依赖的）仍可能因 PATH 查找顺序失败。
- 常见现象：
import torch成功，但torch.cuda.is_available()返回False—— 很可能是系统 PyTorch 没配好 CUDA 路径，而非 venv 问题 - PowerShell 默认禁用脚本执行，激活时若报错
Activate.ps1 cannot be loaded，需先运行：Set-ExecutionPolicy RemoteSigned -Scope CurrentUser - 不要混用 CMD 和 PowerShell 激活同一环境：CMD 用
venv\Scripts\activate.bat，PowerShell 用venv\Scripts\Activate.ps1，切换时务必先deactivate
pip install，也不要依赖系统偶然存在的某个版本。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
