pip 报 Constraints cannot have extras，检查 -r 和 -c

CI 把一份带 package[extra] 的依赖文件交给 pip install -c，升级解析器后报 Constraints cannot have extras。先检查这份文件承担的作用：安装需求可以选择 extras，constraints 只限制已经被其他需求选中的包，不能用来启用可选依赖。

在 pip 26.2.1 中，这项检查仍然存在。它不是缓存损坏，也不说明方括号里指定的 extra 拼错；即使所有版本都能兼容，把 extra 放进 constraints 仍会被拒绝。

文件扩展名不能决定 pip 怎样解释它

检查真正失败的安装命令、文件中的嵌套引用，以及 CI 是否通过环境变量指定了约束文件。一份叫 requirements-dev.txt 的文件，只要通过 -c 传入，就按 constraints 使用；换个文件名不会改变规则。

-r 列出要安装的需求，-c 限制解析时允许采用的版本。constraints 中出现某个包名，不会自行触发安装；未被任何安装需求或依赖链需要的包，可以始终不出现在环境中。

如果完整报错还指出 editable 或 unnamed requirement，也要分别处理。约束行需要明确的发行包名，不能把 -e . 当作一条普通版本限制。不要只删除第一条带方括号的行，然后认为整份锁定输入已经符合要求。

把 extra 留在安装需求，单独限制基础发行包

例如应用需要 requests 的 socks 可选依赖，并且项目已经审定一个兼容的 requests 版本。安装需求文件应保留：

# requirements.txt
requests[socks]

约束文件只写基础发行包的版本限制。下面用 2.32.3 展示语法，不表示这个版本是项目现在应选的版本：

# constraints.txt
requests==2.32.3

用同一项目解释器运行安装入口：

python -m pip install -r requirements.txt -c constraints.txt

实际使用时保留原有索引、认证、平台条件和哈希校验。若项目已经有专用锁文件工具，应在对应输入中区分安装需求与版本约束，再重新生成它支持的输出，而不是手改生成文件后任由下一次构建覆盖。

extra 所引入的传递依赖也要满足整个依赖图。上面的版本行仅限制 requests，不会把 socks 所需的其他包自动固定到某个审定版本。需要可重建安装时，仍须按项目既有方式维护完整依赖组合。

不要用批量删括号代替整理依赖

把全部 [...] 用正则删除，可能同时丢掉应用真正需要的 extra，也可能破坏路径、链接或其他格式。应逐条区分基础发行包、可选功能、版本、marker 和来源；符合条件的版本限制留在 constraints，真正的安装需求留在 requirements。

Python 或平台 marker 也承载适用条件，不能为了让解析通过一并删掉。遇到直接 URL、本地包或可编辑安装，应按当前 pip 支持的输入形式和项目来源约定处理，不把它们无条件改成同名公共索引包。

constraints 不会覆盖需求中已经声明的版本。如果 requirements 要求一个固定版本，而 constraints 排除它，解析器应当报告冲突；改文件角色只能修正语法，不能让两个互斥条件同时成立。

保存原依赖输入、生成文件与 pip 版本，在可重建的隔离环境中按原 CI 流程验证。除了错误消失，还要确认 extra 需要的功能确实可用，并检查实际安装版本和应用测试。回退时一起恢复依赖输入及生成结果；只恢复文本不会撤销环境里已经发生的包安装。

若问题发生在构建子进程找不到 pip，而不是读取 constraints 时，可另查构建隔离中的依赖声明。