前两天帮一个同事排查问题，他在内网机器上pip install一个内部组件，报了一堆莫名其妙的环境冲突，最后发现是配置文件里残留了一个旧源地址。这种问题其实很典型：很多人用 pip 只停留在pip install 包名，遇到换源就百度一条命令复制粘贴，遇到报错就重装 Python，完全没有把 pip 当成一个值得认真研究的工程工具来对待。
所以这篇我打算换一种方式，不讲“pip 不是内部命令”怎么解决，也不重复pip install requests这种基础操作。我按自己这些年做 Python 项目、搞 CI、维护离线环境的经验，整理出 pip 真正值得掌握的十大高级用法。覆盖配置管理、依赖快照、版本约束、离线分发、缓存运维五个方向，基本上每一招都是我在真实项目里踩过坑之后才彻底理解的。
1. 先把“换源”这件事做到位：pip 配置文件全解
很多人理解的换源就是命令行里加一个--index-url https://pypi.tuna.tsinghua.edu.cn/simple，这确实能临时解决问题，但换个终端、换个机器又回到原点。而且命令行参数一旦写错，可能整个安装过程反复超时，非常折磨人。
正确的做法是把源、超时、重试这些全局行为写进 pip 配置文件里。pip 配置文件有明确的查找顺序，理解这个顺序，你就知道为什么有时候明明改了配置却不生效。
1.1 用法一：pip config 命令管理三层配置，一次改好所有环境
pip 从 10.0 版本开始提供了pip config子命令，查看、修改、删除配置再也不用手动去翻配置文件了。
先看当前生效的配置来自哪些文件：
pip config list -v-v参数会把每个配置项的来源文件也打印出来。我见过很多人在用户目录里改了半天，结果实际生效的是全局配置，就是因为没看配置优先级。
pip 配置文件的加载优先级从高到低是：命令行参数 > 环境变量 > 虚拟环境配置文件 > 用户配置文件 > 全局配置文件。命令行参数优先级最高很好理解，环境变量优先级高意味着你可以用PIP_CONFIG_FILE指定一套完全独立的配置，这在 CI 里非常实用。
常用配置命令：
# 设置全局源为清华镜像 pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple # 设置超时时间（秒） pip config set global.timeout 60 # 设置重试次数 pip config set global.retries 5 # 删除某项配置 pip config unset global.timeout配置文件在 Windows 和 Linux 上的位置也不一样。Windows 上全局配置一般在C:\ProgramData\pip\pip.ini，用户配置在%APPDATA%\pip\pip.ini；Linux 下全局配置是/etc/pip.conf，用户配置是~/.config/pip/pip.conf或~/.pip/pip.conf。你要是懒得记路径，就用pip config list -v看。
这里有个我自己试出来的经验：配置index-url之后，如果你用的源是http://而不是https://，还必须额外加一条：
[global] index-url = http://192.168.1.100:8081/simple/ trusted-host = 192.168.1.100trusted-host的作用是声明信任某个主机，pip 才允许走 http 协议。刚开始用私有源的人十有八九会栽在这一步。
1.2 用法二：项目级配置与多源索引，版本库不同源不打架
配置文件不仅能放在用户目录，还能放在虚拟环境目录里。Linux 下是$VIRTUAL_ENV/pip.conf，Windows 下是%VIRTUAL_ENV%\pip.ini。这个特性用来解决“不同项目用不同源”的问题非常合适。
举个例子，公司内部包在私有源上，开源包走 PyPI 官方镜像。如果一个项目两个源都要用，配置可以写成：
[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple extra-index-url = https://packages.example.com/simple/ trusted-host = packages.example.comindex-url是主源，extra-index-url是额外源。pip 在主源找不到包的时候会去额外源继续找。这个组合在工程里非常常用，既保留了官方源的完整包覆盖，又满足了内部包的拉取需求。
另外提一句系统包管理器和 pip 的关系。在 Debian 系系统上，很多人喜欢用 apt 装 Python 包，比如apt install python3-requests。我的建议是系统级包交给 apt 管，项目级依赖交给 pip 管，两边不要交叉混装。apt 的包版本普遍偏旧，但它和系统原生库兼容性好；pip 装在虚拟环境里，不污染系统，也不容易和 apt 打架。
2. 环境复现别靠 pip freeze 一把梭：快照与锁定
“环境复现”可能是 Python 项目里最让人头疼的工程问题之一。很多团队的做法是：在一台机器上跑通后，执行pip freeze > requirements.txt，然后把这个文件交给别人。看起来没问题，但实际用起来经常翻车。
pip freeze的本质是输出当前环境里所有 pip 管理的包及其版本，它更适合做“环境快照”，而不是“依赖清单”。直接依赖、间接依赖、本机路径、平台相关包全都混在一起，一旦跨机器迁移就容易出问题。
2.1 用法三：pip freeze 的正确打开方式与两个隐藏坑
先看pip freeze和pip list的区别：
| 命令 | 输出了什么 | 常见用途 |
|---|---|---|
pip list | 当前环境所有已安装包，包含 pip、setuptools 等 | 查看环境中到底装了什么 |
pip list --format=freeze | 所有包，格式是包名==版本 | 和 freeze 类似，但包含 pip 自身 |
pip freeze | 所有包，但默认排除 pip、setuptools、wheel 等 | 生成 requirements 文件 |
第一个隐藏坑是 editable 安装。如果你在项目里用pip install -e .安装了本地包，pip freeze输出会包含一行：
-e /path/to/your/project把这个文件拿到别的机器上执行pip install -r requirements.txt，pip 会尝试从那个绝对路径安装，而目标机器上根本没有这个路径，直接报错。
第二个坑是跨平台问题。有些包在 Windows 上有、Linux 上没有，或者某个版本只在特定平台有预编译 wheel。你把 Windows 环境的 freeze 结果拿到 Linux 服务器上一装，轻则下载源码包现场编译，重则直接找不到对应版本。
正确的做法是维护两个文件：一个requirements.in记录直接依赖，另一个requirements.txt是锁定后的完整版本列表。用 pip-tools 工具链来管理：
pip install pip-tools # 由 requirements.in 生成锁定文件 pip-compile requirements.in -o requirements.txt # 按照锁定文件精确同步当前环境 pip-sync requirements.txtpip-compile会把直接依赖的所有间接依赖也解析出来，并锁定成精确版本；pip-sync则会把你环境里多出来的包卸载掉，实现和锁定文件完全一致。
2.2 用法四：requirements.txt 进阶写法：Git 依赖、线路内选项与多文件
很多人以为 requirements.txt 就是一行一个包名==版本，其实它是一个功能相当完整的需求描述文件。
第一，支持多文件包含：
# 基础依赖 -r base.txt # 测试环境额外依赖 pytest==8.0.0用-r把 base.txt 的内容引进来，这样可以把生产依赖和开发依赖拆开，避免每次部署都装一堆测试工具。
第二，支持 Git 依赖。比如项目依赖某个仓库的特定分支：
someproject @ git+https://github.com/example/someproject.git@v1.2.0#egg=someproject甚至可以指定子目录：
someproject @ git+https://github.com/example/someproject.git@main#subdirectory=lib/someproject这个功能在依赖还没发布到 PyPI 的私有项目上非常管用。
第三，行内选项和环境标记。requirements.txt 里的每一行都可以带安装选项：
requests==2.31.0 numpy<2.0; python_version < "3.12" --extra-index-url https://packages.example.com/simple/ --trusted-host packages.example.com分号后面是环境标记，只有当条件满足时这一行才会生效。python_version < "3.12"这样的写法能很好地处理不同 Python 版本下的依赖差异。
第四，可以直接写本地 wheel 文件路径：
./vendor/some_package-1.0.0-py3-none-any.whl这通常配合离线部署使用，后面单独讲。
提示：requirements.txt 中
#开头的是注释，空行会被忽略。但千万别在行尾加注释，有些老版本 pip 会解析错误。
3. 版本约束与依赖安全：处理“依赖地狱”的标准姿势
依赖地狱这个词，写过大型 Python 项目的开发一定深有体会：A 包要求 numpy<2，B 包要求 numpy>=1.24，C 包又锁死了某个老旧版本。这种时候光靠 requirements.txt 是不够的，你需要理解 pip 的版本比较规则，还需要一个专门的约束文件。
3.1 用法五：版本符号与 pip index versions，查清楚再约束
PEP 440 定义了一套完整的版本比较规则，pip 支持的常用符号我整理成一张表：
| 符号 | 含义 | 示例 |
|---|---|---|
== | 精确匹配 | requests==2.31.0 |
!= | 排除某个版本 | requests!=2.30.0 |
>=/<= | 范围 | django>=3.2,<4.0 |
~= | 兼容匹配 | ~=2.2等价于>=2.2,==2.* |
* | 通配 | ==2.1.* |
=== | 任意精确字符串 | 基本不用，别碰 |
重点说一下~=。~=2.2的意思是大于等于 2.2，并且主版本是 2，也就是说次版本可以升，但大版本不能跨。~=2.2.4就更严格，等价于>=2.2.4,==2.2.*。这是一个很聪明的柔性约束写法，既允许小版本升级修 bug，又避免大版本升级带来的破坏性变更。
但在写版本约束之前，你得先知道某个包在源上到底有哪些版本。pip 21.2 之后提供了查询命令：
pip index versions requests输出会列出这个包在源上的所有可用版本，并且标记 yanked 版本。yanked 是发布者废除但未删除的版本，正常安装不会选到它，但如果你在约束里精确指定了一个 yanked 版本，pip 也能装上。所以查询版本列表后再写约束，能避免很多隐形问题。
我的习惯是：直接依赖用范围约束写在requirements.in里，类似pandas>=1.5,<2.0；最终锁定文件里再把所有包变成精确版本。一年后换掉旧版本时，改的是源文件，而不是去锁定文件里改几十行。
3.2 用法六：constraints.txt 约束文件与 --require-hashes 锁哈希
constraints.txt是一个很多人知道但用得很少的功能。它和 requirements 文件最大的区别是：constraints 文件里的包不会主动安装，只会在某个包被依赖时限制版本。
使用方式：
pip install -c constraints.txt -r requirements.txt举例。项目 requirements.txt 里写的是flask==2.3.0，而 Flask 的某个传递依赖把click拉到了 8.x，但你因为某个内部库只能配合 click 7.x 使用。这时候不需要改 Flask 的依赖声明，只需要在 constraints.txt 里写：
click==7.1.2再配合-c参数安装，所有被依赖的 click 都会被限制在 7.1.2。这是解决“某个间接依赖版本不对”的标准姿势。
另一个安全相关的功能是--require-hashes。需要在 requirements 文件里给每个包带上哈希值：
requests==2.31.0 --hash=sha256:这里填实际哈希值然后安装时执行：
pip install --require-hashes -r requirements.txtpip 会校验下载的每个文件哈希是否匹配，只要有一个对不上就立刻中止。这对从公共源拉包、担心中间人篡改的场景非常重要。
但要注意，--require-hashes有两个限制：一是必须使用精确版本，二是不支持 Git/VCS 依赖。生成哈希我一般是先pip download然后手动加，或者用 hashin 这个工具自动更新 requirements 文件。安全归安全，维护成本确实不低，小项目没必要硬上，但凡涉及金融、医疗这类强合规场景，建议还是加上。
4. 离线安装与跨服务器迁移：没有外网也能装包
内网服务器不能访问外网，这是所有做企业级项目的人迟早会遇到的问题。新环境装不上包，最原始的办法是手工下载每个 wheel 再用 U 盘拷进去，但如果依赖链有几十个包，手工根本不可行。
pip 面对这种场景其实有一套很成熟的离线分发方案，核心就是pip download+pip install --no-index --find-links。
4.1 用法七：pip download 构建 wheelhouse，跨环境迁移不发愁
在有网环境的机器上，执行：
pip download -r requirements.txt -d wheelhouse-d指定输出目录，pip 会把 requirements 里涉及的所有包及依赖都下载到 wheelhouse 目录。然后你把整个目录复制到离线服务器上，执行：
pip install --no-index --find-links=./wheelhouse -r requirements.txt--no-index告诉 pip 不要访问任何远程索引，--find-links告诉它去本地目录找包。这样一套完整的环境就能在完全断网的情况下复现。
如果目标机器和下载机器架构不同，比如你在 x86 机器上要给 ARM 服务器准备依赖，直接pip download是不行的。需要指定目标平台参数：
pip download \ --only-binary=:all: \ --platform manylinux2014_aarch64 \ --python-version 3.10 \ --implementation cp \ --abi cp310 \ -r requirements.txt \ -d wheelhouse--only-binary=:all:很关键，加上它之后 pip 只会下载预编译的 wheel 文件，不会去下载源码包。如果某个包没有对应平台的 wheel，那就只能在目标机器上现场编译，离线场景下这几乎等于装不上。
一个小经验：下载完成后，在源机器上先检查一下 wheelhouse 里有没有混入源码包，比如.tar.gz后缀的文件。有的话说明交叉下载参数没写对，或者那个包根本没有对应平台的 wheel，需要提前想替代方案。
4.2 用法八：--no-index、--find-links 与 --target 目录化部署
上一节给的离线安装命令中，--no-index和--find-links是固定搭配。--find-links除了目录，也支持file://路径和 HTML 页面地址，内网搭建的简单包索引经常用：
pip install --no-index --find-links=http://192.168.1.100:8000/wheels/ requests还有一个非常实用的参数是--target。它能让 pip 把包安装到一个指定目录，而不是 site-packages。举个例子，服务器没有 root 权限，也不允许往系统 Python 目录里写东西，这时候可以把依赖装到自己目录：
pip install --target ./my_site_packages -r requirements.txt运行项目时用PYTHONPATH指定这个目录：
PYTHONPATH=$PWD/my_site_packages python app.py这个方式相当于给 Python 也搞了一个“绿色版依赖”，整个项目目录拷到哪都能跑，非常适合受限环境。
不过--target有几个坑要注意：一是它会优先于全局 site-packages 被加载，如果目录里某个包版本和系统里不一致，容易产生诡异的行为；二是同一个 target 目录不要跨 Python 版本共用，比如 3.9 和 3.10 的扩展模块 ABI 不兼容；三是如果你要重复往同一个 target 目录装包，建议加--upgrade，否则 pip 可能不覆盖已有同名包。
顺带说一句 conda 和 pip 的边界。conda 真正擅长的是管理 Python 之外的二进制依赖，比如 C 库、CUDA 工具链这些；pip 管的是纯 Python 包和 wheel。混用的时候遵循一个原则：底层有二进制依赖的库优先用 conda 装，纯 Python 包再用 pip。最忌讳的是同一个包两个工具各装一遍，后面一定会出现版本冲突。
5. 缓存与升级运维：日常把 pip 养顺手
pip 用久了，缓存会越来越大，装包速度变慢，磁盘空间被吃掉，CI 构建也可能被缓存污染。这些问题虽然不致命，但日常开发中非常影响体验。
5.1 用法九：pip cache 查看、清理与固化的工程意义
pip 在 20.1 版本后内置了缓存管理命令。先看几个基本操作：
# 查看缓存目录位置和占用大小 pip cache info # 列出缓存的包 pip cache list # 删除匹配的某个包缓存 pip cache remove 'pandas*' # 清空全部缓存 pip cache purge默认缓存目录在 Linux 上是~/.cache/pip，Windows 上是%LocalAppData%\pip\Cache。如果磁盘空间紧张，或者排查“为什么换了源还是下载报错”的问题，通常先pip cache purge一把。
缓存也能主动利用。在公司内部多台开发机之间共享同一份缓存，可以设置环境变量：
export PIP_CACHE_DIR=/data/shared/pip-cache这样第一台机器下载过的包，第二台机器直接命中缓存，下载时间能省很多。我们团队的实际体验是共享缓存后，新环境搭建从十分钟降到一两分钟。
CI 场景反而要禁用缓存。Docker 构建镜像时，pip 下载的缓存会留在构建层里，导致镜像体积膨胀。写 Dockerfile 时加上：
RUN pip install --no-cache-dir -r requirements.txt或者通过环境变量：
ENV PIP_NO_CACHE_DIR=1这个细节能直接把镜像体积砍掉几百 MB。
5.2 用法十：pip list --outdated 与批量升级策略，别乱升
最后一个用法比较偏运维：检查依赖过期情况。
pip list --outdated输出所有有新版本可用的包，还会标注当前版本、最新版本、包类型。想脚本化处理的话用 JSON 格式：
pip list --outdated --format=json在 bash 环境下批量升级所有过期包可以这样：
pip list --outdated --format=freeze | cut -d '=' -f 1 | xargs -n1 pip install -UWindows PowerShell 用户建议先pip list --outdated --format=json把数据导出，再写个循环处理，别硬套 bash 命令。
但升级这件事我强烈不建议全量一把梭。很多包跨大版本升级是破坏性的：pandas 1.x 到 2.x 有 API 变化，requests 2.x 到 3.x 更是直接丢弃了旧接口。批量升级完，项目可能直接跑不起来。
我的实操习惯是：先跑pip list --outdated看清楚有哪些包落后了，然后挑和业务直接相关的逐个升级；升级完立刻执行pip check检查依赖冲突，再跑一遍项目测试用例。pip check会扫描当前环境所有已安装包，告诉你哪些依赖关系已经坏了。
另外再啰嗦一句，升级依赖时留意--upgrade-strategy参数。pip 的默认策略是only-if-needed，意思是只要被依赖的间接包版本满足要求，就不额外升级它们；而eager则会把所有关联包都升到最新。日常操作保持默认就好，追求“全部最新”不是好习惯。
写到这里，十大用法基本讲完了。如果你现在还卡在“pip 不是内部命令”这种报错上，别慌，用python -m pip install 包名是最稳妥的绕行方式，之后把 Python 安装目录下的 Scripts 文件夹加进 PATH 就能根治。最后多说一句，不管是装什么包，看到类似pip install -U --pre xxx的命令时先停一下，确认来源可不可信，再确认当前 Python 版本兼容不兼容，预发布版的坑往往比正式版多得多。Python 包管理这事，提前想清楚版本、源、离线、缓存这些工程问题，比到时候到处搜命令管用得多。
