根本原因是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-code-analyz

专业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，哪怕路径再标准也没用。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！