根本原因是VSCode Python解释器与pip安装环境不一致；需检查终端which python路径与左下角解释器是否相同，不一致则激活对应venv或重新选择解释器；requirements.txt应使用requests==2.25.0等精确版本避免兼容问题。
VSCode里pip install完模块却报ModuleNotFoundError
根本原因不是没装上，而是VSCode用的Python解释器和你执行pip install时的环境不一致。常见于终端没激活虚拟环境就直接运行pip install，结果包被装进了系统Python或另一个venv里。
排查步骤：
- 在VSCode集成终端里运行
which python（macOS/Linux）或where python（Windows），确认当前shell用的是哪个解释器 - 对比左下角状态栏显示的Python解释器路径，二者必须完全一致
- 如果路径不同，要么手动激活对应venv（
source venv/bin/activate或venvScriptsctivate），要么在VSCode里重新选解释器（Ctrl+Shift+P→Python: Select Interpreter）
requirements.txt版本写法直接影响依赖稳定性
只写requests这种无版本约束的条目，重建环境时可能装上requests 2.32.0——而你的代码只兼容2.25.0，运行就崩。VSCode本身不校验版本，但pip install -r requirements.txt会照单全收。
推荐写法：
立即学习“Python免费学习笔记（深入）”；
-
requests==2.25.0：精确锁定，适合生产环境或已验证可用的组合 numpy>=1.21.0,：允许小版本升级，避开破坏性变更- 避免
pip freeze > requirements.txt后直接提交——它会把开发工具（如jupyter、pytest）也塞进去，污染生产依赖
多个项目共用同一venv导致隐性冲突
VSCode不会阻止你把项目A的venv路径配置给项目B用，但一旦项目B执行pip install django==4.2，项目A依赖的django==3.2就被覆盖了——而VSCode语言服务（Pylance）仍按旧版本做类型推导，补全错、报错假。
正确做法：
- 每个项目根目录下独立创建venv：
python -m venv .venv（注意点号前缀，VSCode默认扫描） - 确保
.venv/pyvenv.cfg文件存在——缺失它，VSCode无法识别为有效环境 - 不要跨项目复用venv；conda环境同理，
conda activate myproject后也要在VSCode里重新选解释器
VSCode终端不自动激活venv是设计使然，不是bug
选了解释器，只影响调试、右键“Run Python File”、Pylance补全这些功能；集成终端启动时仍是系统shell，默认不加载任何venv。这是明确的设计选择，不是配置遗漏。
可靠方案只有两个：
- 每次开终端后手动激活：
source .venv/bin/activate（Linux/macOS）或.venvScriptsctivate（Windows） - 在
settings.json里配置终端启动命令（仅限Windows PowerShell）："terminal.integrated.profiles.windows": { "PowerShell": { "source": "PowerShell", "args": ["-ExecutionPolicy", "Bypass", "-NoExit", "-Command", "& '.venv\Scripts\activate.ps1'"] } }注意路径必须用.venv且与项目根目录对齐，否则脚本找不到
pyvenv.cfg文件的存在与否——删掉它，VSCode就彻底“看不见”这个venv，哪怕路径再标准也没用。 
