requirements.in 仅声明顶层依赖及宽松版本约束，由 pip-compile 自动生成含精确版本与哈希的 requirements.txt；前者人工维护、进 Git，后者机器生成、确保环境一致。
requirements.in 和 requirements.txt 的职责必须分开
不分离会导致每次改一个包都要手动更新所有子依赖版本，极易出错。requirements.in 只写顶层依赖（比如 requests、django>=4.2），不写任何具体版本号；requirements.txt 则是 pip-compile 自动生成的、带完整版本号和哈希值的锁定文件。前者人维护，后者机器生成——这是避免“在我电脑上能跑”问题的第一道防线。
pip-compile 解析依赖时需要宽松约束才能找到兼容解
如果你直接在 requirements.txt 里写死 django==4.2.0 和 requests==2.31.0，pip-compile 就没机会做版本协调。而 requirements.in 允许你用 ~=、>= 等操作符表达意图，例如：
django~=4.2 requests>=2.30
pip-compile 会基于当前 PyPI 状态、Python 版本、已有依赖组合，找出满足所有约束的最优版本集。这个过程没法靠人脑穷举，尤其当项目引入 sqlalchemy、pydantic 这类强依赖传递的库时。
多人协作中，requirements.in 是唯一该进 Git 的“需求说明书”
团队成员各自运行 pip-compile requirements.in，只要 Python 版本和 pip-tools 版本一致，生成的 requirements.txt 就该高度一致。但实际中常出现差异，原因包括：
- 本地缓存损坏 → 清掉
~/.cache/pip-tools再试 - 用了不同 Python minor 版本（如 3.11.8 vs 3.11.9）→ 要求 CI 和开发者统一使用 pyenv 或 asdf 管理
- requirements.in 里混入了
-e .或本地路径 → 这类条目不会被 pip-compile 解析，应移出或用--extra-index-url配合
真正要提交到 Git 的只有 requirements.in 和生成的 requirements.txt；中间产物（比如编译日志、临时 .txt）不该进仓库。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
升级某个包时，不能直接改 requirements.txt
直接编辑 requirements.txt 改版本号，等于绕过依赖解析器——下一次 pip-compile 运行时，它可能把你的手动修改覆盖掉，或者因为冲突而报 IncompatibleRequirements 错误。
正确做法是：
- 只改 requirements.in：比如把
requests改成requests>=2.32 - 加
--upgrade-package requests参数重新编译：pip-compile --upgrade-package requests requirements.in - 检查生成的 requirements.txt 是否包含预期变更，再提交
这一步漏掉，就等于把版本决策权从工具交还给人，而人容易忽略间接依赖的连锁反应。
最常被忽略的是：requirements.in 文件本身不校验语法，但一旦某行写成 requests == 2.31.0（带空格），pip-compile 会静默跳过这一行，导致最终环境缺包。务必用等号紧贴（requests==2.31.0）或完全不用版本号。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
