必须用 python -m venv 创建虚拟环境，因其是 Python 3.3+ 官方内置方案，无需安装、兼容性好、IDE 和 CI 原生支持；而 virtualenv 是第三方工具，易因版本滞后引发 Python 3.12+ 兼容问题。
直接用 python -m venv .venv 创建，别碰全局 pip install —— 否则项目一多、依赖一混，三天就能重装系统。
为什么必须用 python -m venv 而不是 virtualenv
Python 3.3+ 已把 venv 打包进标准库，无需额外安装，也不依赖第三方工具。你如果先 pip install virtualenv 再运行 virtualenv .venv，反而绕开了官方路径，还可能因 virtualenv 版本滞后（尤其在 Python 3.12+ 或即将发布的 3.14.3 中）引发兼容性问题。IDE（如 VS Code、PyCharm）和 CI 工具链原生识别 venv 生成的结构，但对 virtualenv 的行为支持不一致。
python -m venv .venv 这条命令的三个关键细节
看似简单，但路径、命名、权限三处最容易出错：
-
.venv是推荐目录名：隐藏、被 Git 默认忽略、VS Code 自动识别；别用venv或env，否则容易和旧项目习惯冲突 - 绝对路径写死（如
python -m venv /home/user/proj/.venv）会导致迁移后激活脚本失效——pyvenv.cfg里记录的是硬编码路径 - macOS 上若提示
Permission denied，不是缺sudo，而是你在用系统自带 Python（受 PEP 668 保护），应改用pyenv或brew install python安装的版本
Windows 下激活失败的常见原因和对应操作
激活本质是修改 %PATH%，把 .venv\Scripts 提到最前面。但 Windows 用户常卡在这几步：
立即学习“Python免费学习笔记（深入）”；
-
.venv\Scripts\activate.bat用于cmd；.venv\Scripts\Activate.ps1用于 PowerShell —— 后者默认被禁用，需提前运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser - 终端不支持脚本执行？换用
cmd或Windows Terminal，别用某些 IDE 内置终端（如旧版 PyCharm 的 Terminal 插件） - 激活后
where python仍指向全局路径？说明没生效，检查是否漏掉source（Linux/macOS）或点号空格（Windows：.venv\Scripts\activate不是.venv\Scripts\activate.bat）
创建后验证环境是否真正隔离
激活后别急着装包，先确认隔离是否生效：
- 运行
python -c "import sys; print(sys.path[0])"，输出必须是.venv/lib/python3.x/site-packages或类似路径（Windows 是.venv\Lib\site-packages） - 执行
pip show django（哪怕没装），报错提示 “Package not found” 才对；如果显示系统级路径，说明继承了全局包 —— 你可能误加了--system-site-packages -
pip list应只显示pip、setuptools、wheel三个基础包，其余全是空白
最容易被忽略的是：虚拟环境不可移动、不可复制，也不能签入 Git。一旦发现 .venv 目录异常（比如缺失 bin/ 或 Scripts/），别修，直接删掉重建 —— 它的设计哲学就是“可丢弃”。
