应优先使用 python -m venv 创建虚拟环境，因其是 python 3.3+ 内置标准库模块，轻量、无额外依赖、兼容性好且与 python 版本同步更新；virtualenv 是第三方包，易引发版本冲突，非必要不推荐。
直接用 python -m venv 创建，别装 virtualenv —— Python 3.3+ 自带的 venv 足够稳定、兼容性好，且不会和系统包混在一起。
为什么不用 virtualenv 而用 venv
Python 官方从 3.3 开始内置 venv 模块，它和 virtualenv 功能基本一致，但更轻量、无额外依赖、更新节奏与 Python 版本同步。你查 pip list 不会看到它，因为它不是 pip 包，而是标准库的一部分。
常见误区是先 pip install virtualenv 再用 virtualenv venv，这反而可能引入版本冲突（比如 virtualenv 20.x 对 Python 3.12 支持滞后），而 python -m venv venv 总是调用当前 Python 解释器自带的逻辑，最可靠。
- Windows 用户注意：
venv\Scripts\activate.bat是 cmd 用的，venv\Scripts\Activate.ps1是 PowerShell 用的（默认被禁用） - Mac/Linux 用户注意：
source venv/bin/activate才能真正激活，只输venv/bin/activate是执行而非 source，环境不会生效 - PyCharm 等 IDE 识别的是
venv/bin/python（Mac/Linux）或venv\Scripts\python.exe（Windows），路径错一个字符就找不到解释器
venv 目录该放哪？别塞进 Django 项目包里
虚拟环境目录必须和 Django 项目代码**同级**，不能放在 myproject/myproject/ 或 myproject/manage.py 同目录下——否则 manage.py 会误把 venv 当成一个 Django app，运行时报 ImportError: No module named 'venv'。
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
正确结构示例：
myproject/ ├── venv/
- 创建命令：在
myproject/父目录下运行python -m venv myproject/venv - 激活后安装 Django：确保
(venv)出现在命令行前缀，再运行pip install django==4.2（LTS 版更稳） - 验证是否装对：运行
python -c "import django; print(django.__version__)"，输出应为4.2.x，而不是系统全局的旧版
PyCharm 里选错解释器的典型症状和修复
PyCharm 报 ModuleNotFoundError: No module named 'django' 或补全失效，大概率是解释器没指向虚拟环境里的 python。
- 检查路径：Settings > Project > Python Interpreter > 右上角齿轮 > Add > Existing environment > 浏览到
venv/bin/python（Mac/Linux）或venv\Scripts\python.exe（Windows） - 别选错文件：不是
venv/Scripts/activate，也不是venv/Scripts/pip，必须是python可执行文件 - 激活状态不等于 PyCharm 生效：即使终端里
(venv)显示正常，PyCharm 默认仍用系统解释器，必须手动指定 - 改完后重启 PyCharm：有时缓存导致新解释器不立即生效
最常被忽略的一点：Django 项目启动时（python manage.py runserver）必须在已激活的 venv 下运行，或者明确用 venv/bin/python manage.py runserver；如果只是 python 命令没走虚拟环境，哪怕 pip list 看起来有 Django，实际加载的仍是全局 Python 的 site-packages。
