venv目录下最关键的三个子目录是Scripts/（Windows）或bin/（macOS/Linux）、Lib/site-packages/（Windows）或lib/pythonX.Y/site-packages/（macOS/Linux）以及含pyvenv.cfg的根目录；前者存放可执行工具并负责路径指向，中间者为第三方库实际安装位置，后者通过pyvenv.cfg文件标识环境身份与原始Python路径。
venv 目录下最关键的三个子目录
Python venv 创建后，核心隔离能力就藏在这几个固定路径里。不同系统命名略有差异，但功能完全一致，搞清它们的作用，才能避免 pip 装错地方、解释器调用混乱这类高频问题。
Scripts/（Windows）或 bin/（macOS/Linux）
这是你每天打交道最多的一层：所有可执行入口都在这儿。它不存代码逻辑，只负责“指路”——让 python、pip 命令实际调用的是当前环境的副本。
-
python.exe（Windows）或python（macOS/Linux）是符号链接或硬拷贝，指向基础 Python，但运行时会自动加载lib/pythonX.Y/site-packages/下的包 -
activate是激活脚本，但注意：Activate.ps1在 PowerShell 默认被禁用，需先运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser - 直接调用
.venv\Scripts\python.exe比先activate更可靠，尤其在 CI/CD 或多环境切换时，能绕过 shell 环境变量污染
Lib/site-packages/（Windows）或 lib/pythonX.Y/site-packages/（macOS/Linux）
所有通过 pip install 安装的第三方库，最终都落在这儿。它是“依赖落地层”，也是排查冲突的第一现场。
- 安装
requests==2.31.0后，你会看到requests/文件夹和requests-2.31.0.dist-info/，版本信息就锁死在这里 - 如果
import requests报错，先确认python -c "import requests; print(requests.__file__)"输出路径是否落在这个目录内 - 手动删包？可以，但更推荐
pip uninstall requests，否则可能残留.dist-info导致后续安装异常
pyvenv.cfg 配置文件
这个小文件不起眼，却是虚拟环境的“身份证”。它不控制行为，但决定了环境能否被正确识别。
立即学习“Python免费学习笔记（深入）”；
- 内容通常只有几行，关键字段是
home = /usr/bin（指向原始 Python 安装路径）和include-system-site-packages = false - 如果你复制整个
.venv目录到另一台机器，只要home路径还存在，环境大概率仍可用；若原始 Python 被卸载，python.exe就会启动失败 - 不要手动修改
home，改了也不会生效——Python 解释器启动时硬编码读取该值，用于定位标准库路径
真正容易被忽略的是：这些目录的结构不是“约定俗成”，而是 venv 模块启动时写死的逻辑。一旦你用 virtualenv 或 conda 创建环境，Scripts/ 可能变成 envs/，site-packages/ 也可能嵌套更深。认准 pyvenv.cfg 存在与否，才是判断一个目录是不是原生 venv 环境的最稳方式。
