requirements.txt不是可选配置，而是部署成败的关键——它强制规定每个依赖的精确版本（如numpy==1.24.3）和最小集合，确保跨环境一致性；跳过则导致版本混乱、依赖冲突与运行失败。
requirements.txt 不是“为了部署才写”，而是**不写它，部署就大概率失败**。
它解决的不是“要不要装依赖”的问题，而是“装哪一版、装哪些、不装哪些”的确定性问题。没它，pip install -r requirements.txt 就无从执行，环境一致性彻底失控。
为什么 pip install -r requirements.txt 不能跳过？
这个命令不是简单地“批量安装”，它强制按行解析 requirements.txt 中每一条约束，并逐个满足：
-
numpy==1.24.3→ 只装 1.24.3，哪怕本地已有 1.25.0 也得降级 django>=4.2, → 排除 5.0+ 的破坏性变更，但允许 4.2.x 内部小版本自动更新- 遇到
scikit-learn @ git+https://...→ 直接从指定 commit 拉源码编译，不走 PyPI
没有这个文件，你就只能靠人肉回忆或 pip list 猜——而 pip list 显示的是当前环境里“有什么”，不是项目“需要什么”。开发时顺手装的 black、pytest、ipdb 全都会混进去。
requirements.txt 里写错版本号会怎样？
常见错误不是“装不上”，而是“装上了但跑不通”：
-
pandas>=2.0.0→ 新版默认启用nullable=True，旧代码用df.fillna(0)可能报TypeError: cannot fill NaN with value of type int -
requests（没写版本）→ 某天自动升级到 2.32.0，而你的代码依赖已被移除的urllib3.util.retry.Retry.DEFAULT_ALLOWED_METHODS -
torch==2.1.0+cu118→ 在没装 CUDA 11.8 的机器上直接安装失败，且错误提示模糊（只报Could not find a version that satisfies...）
这类问题不会在 pip install 阶段报错，而是在运行时才暴露，排查成本远高于提前写对版本。
立即学习“Python免费学习笔记（深入）”；
生成 requirements.txt 的常见误操作
pip freeze > requirements.txt 是最危险的“一键生成”方式，除非你确认：
- 当前虚拟环境干净，没装任何调试/格式化/IDE 工具类包（如
pylint、autopep8） - 所有依赖都通过
import被实际使用，而不是仅用于 demo 或临时脚本 - 没有手动
pip install -e .安装的本地包——它们会以-e git+https://...形式出现在 freeze 结果中，别人 clone 后无法复现
更稳妥的做法是：先手动列出核心依赖（如 flask==2.3.3、sqlalchemy~=2.0.0），再用 pip install -r requirements.txt 验证能否跑通，最后用 pipreqs . --force（需先 pip install pipreqs）反向扫描代码中的 import 补全遗漏项。
部署时 requirements.txt 放错位置怎么办？
它必须放在执行 pip install -r requirements.txt 命令时的当前工作目录下。常见坑点：
- 文件名写成
requirement.txt（少个 s）或requirements.txt.txt（Windows 默认隐藏后缀）→ 报错ERROR: Could not open requirements file: [Errno 2] No such file or directory: 'requirements.txt' - Dockerfile 中写
COPY requirements.txt /app/却忘了WORKDIR /app→ pip 找不到文件 - PyCharm 中右键运行 Terminal，默认路径不是项目根目录，要先
cd /path/to/your/project
最省事的验证方式：在项目根目录下运行 ls -l requirements.txt（Linux/macOS）或 dir requirements.txt（Windows），确保输出存在且大小非零。
requirements.txt 本质不是“记录已装什么”，而是“声明项目契约”——它定义了代码能正确运行的最小依赖边界。写宽了，环境漂移；写窄了，CI 失败；写错了，半夜收告警。 
