virtualenv或venv是django项目启动前的强制前置动作，不配置将导致多项目依赖冲突、版本混用及隐性运行错误；推荐python 3.3+用户直接使用内置python -m venv .venv创建隔离环境。
virtualenv 或 venv 不是可选项，而是 Django 项目启动前的强制前置动作。不配独立虚拟环境，等于把所有项目的依赖塞进同一个抽屉里——抽屉一乱，所有项目都找不到自己的钥匙。
为什么 pip install django 会破坏其他 Django 项目？
全局执行 pip install django==4.2.11 后，系统里所有用 import django 的项目都会加载这个版本。哪怕你另一个项目只兼容 Django==3.2.23，它也会在运行时抛出 AttributeError: module 'django' has no attribute 'setup' 或模板渲染失败等隐性错误。
- 根本原因：Python 的
sys.path默认优先查全局site-packages，不会区分“谁装的” - 现象不是立刻报错，而是功能异常（比如 admin 静态文件 404、
django.contrib.auth模块缺失），排查成本远高于提前建环境 - 连
python -m django --version都可能返回错误版本，因为它调用的是当前解释器绑定的 django，而非项目期望的
venv 和 virtualenv 哪个该用？
Python 3.3+ 自带 venv，足够日常使用；virtualenv 是第三方工具，支持更老的 Python 版本和额外特性（如自动换源、预安装包），但对新项目无必要优势。
- 推荐命令：
python -m venv .venv（注意末尾是.venv，不是venv，避免误提交） - 不要用
virtualenv myenv这类不带-p参数的写法——如果系统有多个 Python 版本（如python3.9和python3.11），它可能默认选错解释器 - 验证是否生效：
which python应输出类似/path/to/your/project/.venv/bin/python，而不是/usr/bin/python3
requirements.txt 为什么总生成错？
pip freeze > requirements.txt 只有在激活虚拟环境后执行才有效。在全局环境下跑这行命令，会把系统里所有乱七八糟的包（包括 ansible、awscli 甚至你当年试过的 pygame）全 dump 进去。
- 正确流程：先
source .venv/bin/activate（Linux/macOS）或.venv\Scripts\activate（Windows），再pip install django gunicorn psycopg2-binary，最后pip freeze > requirements.txt - 加
--no-deps参数能过滤掉间接依赖，但 Django 生态里很多包（如django-filter）依赖版本敏感，建议保留完整依赖树 - 别信编辑器右下角显示的 “Python 3.11” 就代表环境干净——它只读取 interpreter 路径，不校验已装包是否匹配项目需求
Django 开发服务器启动失败，第一个该查什么？
不是看 settings.py，而是立刻运行 python -c "import django; print(django.__version__)"。如果输出版本和 requirements.txt 里写的不一致，90% 是虚拟环境没激活或激活了错误的环境。
- 常见陷阱：终端开了多个 tab，只在一个里
source .venv/bin/activate，却在另一个里敲python manage.py runserver - VS Code 中，即使选对了 interpreter，也要确认终端是否继承了该环境——关掉所有终端，用 Ctrl+Shift+P → “Python: Create Terminal” 重开一个
- 用
pip list | grep django比看报错日志更快定位问题，因为很多错误（如No module named 'django.core.management'）本质就是 import 路径错了
pip、manage.py、第三方 app 的 setup.py）全部按隔离假设设计。一旦跳过这步，后面所有调试、部署、协作环节都在给这个漏洞填坑。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
