flask项目不建虚拟环境时import flask失败，根本原因是python解释器与pip不匹配或path路径混乱导致模块查找失败；必须通过where python确认解释器路径，并用venv创建隔离环境绑定解释器与site-packages。
Flask 项目不建虚拟环境，import flask 就会失败
Windows 上直接 pip install flask 后运行 python app.py 报 ModuleNotFoundError: No module named 'flask'，不是你没装成功，而是当前 Python 解释器根本没在它的 site-packages 里找 Flask —— 它查的是系统级路径，而你的命令行可能调用了另一个 Python（比如从 Microsoft Store 装的、或 PATH 里排在前面的旧版本）。venv 创建的解释器自带专属 Lib\site-packages，激活后 import flask 才真正指向你刚装的那个版本。
- 检查当前解释器路径：运行
where python（Windows）或which python（macOS/Linux），确认它是否指向你期望的 Python 安装目录 - 哪怕
pip list显示 flask 已安装，如果python和pip不是同一套，照样导入失败 -
venv强制绑定解释器与包路径，绕过 Windows 注册表和 PATH 混乱问题
同一台机器跑多个 Flask 项目时，依赖冲突是默认行为，不是意外
项目 A 需要 Werkzeug==2.2.3（对应 Flask 2.2），项目 B 升级到了 Flask 2.3，自动拉 Werkzeug>=3.0。全局装完，A 立刻崩在 ImportError: cannot import name 'Response' from 'werkzeug.wrappers' —— 因为 API 已删。这不是 Flask 的 bug，是 pip 在单一 site-packages 下只能存一个版本的必然结果。
-
venv为每个项目生成独立的Lib\site-packages，互不读写 - Flask 本身不控制依赖版本，它只声明兼容范围；冲突由包管理器在全局环境下执行时触发
- Windows 没有
--user的可靠 fallback：注册表键值错位、PowerShell 执行策略拦截、%APPDATA%权限异常都会让--user失效
激活虚拟环境后，which python 和 pip 指向哪里？为什么这很关键
激活 venv 的本质是把 Scripts\（Windows）或 bin/（macOS/Linux）塞进 PATH 最前面。所以 where python 返回的是 D:\myproject\.venv\Scripts\python.exe，pip install flask 安装目标自动变成 .venv\Lib\site-packages。这个路径劫持是隔离生效的唯一技术基础。
- 不激活就直接用
.venv\Scripts\python.exe app.py也能跑，但此时pip还是系统的，容易误装到全局 - 检查是否真激活：运行
python -c "import sys; print(sys.path[1])"，输出应为虚拟环境内的Lib\site-packages路径 -
pyvenv.cfg文件里的include-system-site-packages = false是开关，改 true 就等于主动放弃隔离
requirements.txt 只在虚拟环境里才有意义
pip freeze > requirements.txt 导出的是当前环境所有包的精确版本。如果没开虚拟环境，这份文件就混着你半年来装的各种工具包（jupyter、black、pylint），同事 pip install -r requirements.txt 会把不该装的全装上，还可能因版本不兼容直接报错。
- 导出前务必确认已激活目标虚拟环境，且只装了项目必需的包
-
pip install -r requirements.txt必须在空的新虚拟环境中执行，否则旧包残留会导致行为不一致 - Flask 项目常带
gunicorn、python-dotenv等运行时依赖，漏掉一个，flask run就可能卡住或静默失败
python 就又回到系统路径——这时候哪怕 .venv 目录还在，pip install 也早已悄悄写进全局。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
