把每个项目隔离在各自的 venv 中，锁定依赖版本，并采用一套可复现的项目结构。
在 Kodokon 中打开本课把你所有项目的依赖都装进同一个解释器，最终必然撞上版本冲突：项目 A 需要 requests 2.31，项目 B 却需要一个不兼容的版本。虚拟环境（venv）把每个项目隔离开来：它有自己的解释器、自己的 pip、自己的包。这是没有商量余地的专业实践 - 一个项目，一个环境，并且能在任何机器上被原样重建。
python -m venv .venv
source .venv/bin/activate
# On Windows:
# .venv\Scripts\activate
python -m pip install requests
python -m pip list要让安装过程可复现，就得锁定版本。pip freeze 会导出整个环境，包括传递依赖在内，并带上精确的版本号：可复现性拉满，但升级起来很费劲。现代的做法把两种需求分开：直接依赖以宽松的约束声明在 pyproject.toml 中，再生成一个锁文件用于精确安装。在小项目的规模上，requirements.txt 依然完全拿得出手。
python -m pip freeze > requirements.txt
# On another machine:
python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt在结构方面，src 布局是标准参考：代码放在 src/<package>/，测试放在 tests/，配置放在 pyproject.toml。src 目录的意义并不只是好看：它能防止你不小心从当前目录导入本地的包，那样会掩盖打包方面的错误 - 有了它，你的测试跑的是真正安装好的那个包。开发过程中，pip install -e . 会以可编辑模式安装项目。
mkdir -p src/billing tests
touch src/billing/__init__.py
touch src/billing/invoices.py
touch tests/test_invoices.py
touch pyproject.toml README.md .gitignore
echo ".venv/" >> .gitignore