为什么每个项目都要独立环境
全局 site-packages 是所有项目共享的：项目 A 升级了 requests 到 2.32，项目 B 就地崩掉——这就是「昨天还好好的」的真相。虚拟环境给每个项目一套隔离的 site-packages 与独立的 python/pip 入口，互不干扰，删除即整体销毁，是最朴素的依赖治理。
python -m venv .venv # 在项目根目录创建（建议固定叫 .venv）激活与退出：记平台差异，别记死命令
Linux/macOS 用 `source .venv/bin/activate`；Windows PowerShell 是 `.venv\Scripts\Activate.ps1`，cmd 是 `Scripts\activate.bat`。退出统一是 `deactivate`。PowerShell 首次报「禁止运行脚本」是执行策略限制，`Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` 一次性解决。
VSCode/PyCharm 里把解释器指到 .venv 内的 python，终端会自动激活，日常几乎不用手动敲这些命令——这是省心的做法。
source .venv/bin/activate # Linux / macOS
.venv\Scripts\Activate.ps1 # Windows PowerShell
deactivate # 退出虚拟环境依赖固定：requirements.txt 的三档写法
① 宽松（`requests`）：装到什么全看运气，适合原型；② 区间（`requests>=2.28,<3`）：常用折中；③ 精确锁定（`requests==2.32.3`）：部署可复现，`pip freeze > requirements.txt` 生成的就是这档。实践建议：开发用区间版本表达意图，发布时 freeze 出一份精确锁文件用于部署，两层各司其职。
直接提交 freeze 结果作为唯一依赖文件的问题是：跨平台依赖会带进来平台专属包名（如 Windows 的 colorama、Linux 的 furo），队友在另一平台安装直接报错——这类包应拆到单独文件或加环境标记。
requests>=2.28,<3 # 区间：表达意图
pip freeze > requirements.txt # 锁定：可复现部署
# 跨平台标记示例：
colorama; sys_platform == "win32"三个高频翻车点
① 用错解释器创建环境：系统里多个 python 时，`python -m venv` 用的可能是旧版本——先 `python --version` 确认，或显式 `python3.12 -m venv .venv`；② 环境目录被移动/重命名后路径失效：venv 内的脚本硬编码了绝对路径，搬家后删掉重建最省事；③ IDE 在跑的不是 .venv：命令行正常、IDE 报 ModuleNotFoundError，八成是解释器没指向虚拟环境。
python --version # 先确认解释器
python3.12 -m venv .venv # 必要时显式指定版本
which python # 激活后应指向 .venv 内的 python何时升级到 uv / poetry
标准库 venv + pip 覆盖单项目需求已经够用。当出现这些信号再考虑工具升级：依赖解析频繁冲突、需要 lockfile 的可复现构建（pip-tools 是轻量选项）、需要打包发布到 PyPI（poetry/hatch）、追求极速安装与 Python 版本管理（uv）。先会用标准工具，再让工具解决真实痛点，顺序反了只会多背一层概念。
pip install pip-tools
pip-compile requirements.in # 生成带锁定的 requirements.txt一页速查：venv 工作流
创建 `python -m venv .venv` → 激活（按平台选命令）→ 装包 `pip install` → 开发期区间版本 → 发布期 `pip freeze` 锁定 → .venv 进 .gitignore，requirements.txt 进仓库。六步走完，环境问题从此与你无关。
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
echo ".venv/" >> .gitignore