入行头两年我的pip用法基本就一条pip install xxx。遇到问题就百度偶尔会用pip freeze requirements.txt以为自己已经会了。直到有次接到一个任务要给一台完全断网的服务器装一套内部系统我拿着笔记本折腾了一整天才意识到自己连入门都算不上。后来我把pip的文档翻了个遍又在几个项目里反复踩坑才慢慢摸清它的完整能力边界。这篇文章我想把这几年沉淀下来的东西整理一遍重点讲十个平时不太被注意、但非常顶用的用法。它们不全是冷门命令更多是你知道但没往深处想的那些东西。我按使用场景分成四块本地开发、内网部署、供应链安全、性能与跨平台。无论你是刚接触Python的新手还是已经写了几年脚本的老手里面应该都有能直接用上的东西。1. 开发阶段的两个高频利器可编辑安装与requirements条件标记先说本地开发。很多人开发自己的包时习惯改一点代码就重新pip install .一次装完再跑测试。这样不是不行只是效率太低。我见过好几个人因为这个原因觉得调试依赖包很痛苦最后干脆把代码直接塞进site-packages里手动改那才是真正的灾难现场。1.1 pip install -e改完源码立刻生效的开发模式-e参数的全称是--editable也就是可编辑安装。用法很简单# 在项目根目录有pyproject.toml或setup.py的地方执行 pip install -e .装完之后这个包不会把源码复制到site-packages里而是建立一个指向你源码目录的链接。Python在import的时候会直接读取你当前工作区的源码文件。所以你在项目里改了代码不需要重新安装立刻就能生效。这个模式最适合三种场景你正在开发一个库同时有另一个项目在依赖它。你不想每次改库都要重新装一遍。你想调试第三方依赖包。先把它的源码clone下来然后pip install -e这个源码目录。你想确认某个分支的改动效果又不想污染环境。可编辑安装配合虚拟环境非常顺手。原理上这套机制在PEP 660之后统一了实现方式pip会调用项目的构建后端生成一个可编辑安装包然后通过__editable__文件或pth文件把源码目录注册到Python的搜索路径里。对于纯Python代码来说改动即时生效但对于包含C扩展的项目编译产物不会自动重建你需要手动重新执行一次构建这个很容易忽略。有个经典坑我必须提醒你pip install -e在开发机上是神器但千万别在Docker镜像或者生产环境里用。容器构建是一次性的可编辑安装wiring的是容器外的源码路径一旦镜像被复制到别处这个链接就断了。生产环境里老老实实用普通安装。1.2 requirements文件条件标记和依赖分组的高级写法requirements.txt本身大家都会写但大多数人只用了它最基础的一行一个包功能。其实这个文件支持环境条件标记、本地路径引用、可编辑安装、约束文件引用组合起来能解决很多实际的依赖管理问题。举个我实际用过的结构一个稍微复杂点的项目可以这样组织# requirements.txt基础运行依赖 fastapi0.109.2 uvicorn[standard]0.27.1 sqlalchemy2.0,2.1 redis4.5,6.0 # requirements-dev.txt开发环境依赖 -r requirements.txt pytest7.0 ; python_version 3.8 ruff0.3.0 ; sys_platform linux -e .[dev,test]注意最后一行-e .[dev,test]它包含两层意思一是以可编辑方式安装当前项目二是安装pyproject.toml里定义的两个extra分组。这样你在不同环境只要切换requirements-dev.txt和requirements.txt就能保持一致。条件标记; python_version 3.8这类写法是很多人的知识盲区。它的作用是同一份requirements文件在不同Python版本或操作系统上pip会自动过滤掉不匹配的行。比如pytest在Python 3.8以下不放进来ruff只在Linux上装。这在维护多Python版本、跨平台项目时非常有用。另外一个被低估的功能是通过路径引用本地包# 本地私有包不发布到PyPI ./vendor/my-common-lib配合-e可以直接指向本地待开发版本。这个在微服务拆分时特别好用几个服务共享一个公共库还没到发布版本的时候直接路径引用就行。用requirements文件踩过最疼的一个坑是条件标记不是万能的。pip解析时按当前解释器环境来过滤行但你无法用它表达Python 3.8以上用A版本以下用B版本这种复杂逻辑。真要复杂到那个程度就该上pip-tools的pip-compile了它能用约束输入生成锁定清单条件标记也会正确编译进结果。我的建议是小项目手写项目规模上了三个以上微服务尽早引入编译锁文件。2. 内网部署与离线分发源配置、离线下载和目标目录三件套没有经历过断网环境的人很难理解为什么pip能离线安装也算高级用法。直到你面对一台物理隔离的服务器、或者一条网络极差的生产链路才会意识到平时随手pip install有多方便。内网部署这块我总结成三个互相配合的招源配置、离线下载、指定安装目录。2.1 私源配置与双源使用--index-url、--extra-index-url与trusted-host私有源这个问题几乎所有中大型团队都会遇到。互联网上的Python源在大陆地区访问速度不稳定加上很多公司有内部包不能外泄必须自建或使用镜像源。基础命令大家都会pip install requests -i https://mirrors.example.com/simple但每次敲-i太累更好的做法是写进配置。pip的配置文件在Linux/macOS上是~/.config/pip/pip.confWindows上是%APPDATA%\pip\pip.ini[global] index-url https://mirrors.example.com/simple trusted-host mirrors.example.com timeout 60trusted-host很多人不理解。它用来声明哪些主机可以被信任主要应对自建源只走HTTP、没有HTTPS证书的情况。不加它pip会拒绝连接非HTTPS源。加了之后pip会允许对该主机使用HTTP。这里有个安全取舍如果在内网环境问题不大如果在公网除非源是你自己可控的否则慎用。还有两个容易搞混的参数--index-url和--extra-index-url。前者是替换默认源后者是在默认源之外增加一个查询源。看起来差不多实际行为差远了参数行为典型场景--index-url只用指定源统一走公司镜像源--extra-index-url同时查多个源默认PyPI为主补充内部私有包源我用--extra-index-url踩过一个大坑两个源上存在同一个包的不同版本时pip不会智能合并它会分别去两边找常常出现下载了包A但依赖的包B找不到或者版本错乱的问题。更诡异的是某些源返回的元数据不完整会导致本来能装的包莫名报找不到版本。所以我的建议是能用单一--index-url就别用双源实在要双源把公共包和私有包拆开放在不同的requirements文件里分开安装。2.2 pip download为一台断网机器准备整个依赖仓库这是离线部署的核心。在一台能联网的机器上先用pip download把需要的包全部拉下来然后拷贝到断网机器上用本地文件安装。基本流程# 在联网机上下载全部依赖到offline_packages目录 pip download -r requirements.txt -d offline_packages/ # 拷贝offline_packages到目标机器后离线安装 pip install --no-index --find-linksoffline_packages/ -r requirements.txt参数解释一下--no-index告诉pip不要访问任何源--find-links指定从本地目录找包。这样整个安装过程完全不碰网络。但真正值钱的是跨平台下载。假设你联网机器是macOS目标机器是Linux你不能直接把macOS下的whl文件装到Linux上。你需要用平台参数强制pip下载指定平台的wheel# 为Linux x86_64 Python 3.11 下载 pip download -r requirements.txt -d linux_packages/ \ --platform manylinux2014_x86_64 \ --python-version 3.11 \ --implementation cp \ --only-binary:all:这里--only-binary:all:是关键。它让pip只下载wheel格式的包不要源码包。因为源码包sdist到你手里还得现场编译断网机器上没有编译环境的话就是个死局。加了这个参数pip如果在指定平台上找不到对应wheel就会直接报错而不是默默丢给你一个源码包让你去编译。另外建议下载完做个完整性校验把所有文件的sha256算一遍记录到校验文件里。别嫌麻烦拷贝过程出现文件损坏的概率比你想的高。这个校验和第3章哈希校验可以联动。2.3 pip install --target把依赖直接装进指定目录--target参数让我在一段时间里直呼怎么没早知道。它的作用是指定安装目录而不是默认的site-packages。典型场景是没有虚拟环境可以用、需要把依赖和代码打进同一个部署包、或者做无服务器函数部署时函数运行时会从你的函数代码目录里找依赖。pip install --target ./deploy_libs flask3.0.0 # 运行代码前设置PYTHONPATH export PYTHONPATH$(pwd)/deploy_libs:$PYTHONPATH这个参数有个反直觉的地方它不会把包装成普通目录结构而是会创建类似deploy_libs/flask的文件夹照样可以通过import flask导入。同时pip会把依赖的依赖也一并装进来所以最终目录里会有一大堆包。使用时有几个注意点安装目录里如果已经有同名包旧版本不会自动清理容易残留。我从不用它做增量升级要升级就清空目录重装。卸载很麻烦没有uninstall --target这种干净操作只能手动删目录。如果你只需要特定包、想控制依赖范围可以加--no-deps然后手动逐个装依赖。我在一个比较老的项目里用过这个方案那个项目没有虚拟环境系统Python不允许乱动全局环境部署脚本强制要求代码依赖一个目录。--target加--no-deps加手动依赖清单虽然丑但稳。3. 供应链安全与版本基线哈希校验、约束文件与VCS安装很多人的依赖管理停留在能跑就行但一旦进入生产环境、或者要交付给客户依赖的可信性和可复现性就变成大事。我经历过一次内部包被篡改之后才对哈希校验彻底重视起来。3.1 --require-hashes把requirements变成带签名的清单--require-hashes是一个安全开关要求requirements文件里的每个安装包都必须附带sha256哈希值。pip在安装时会校验下载包的实际哈希不一致就拒绝安装。一个带哈希的requirements文件长这样flask3.0.0 --hashsha256:7f9a6c8f91e55a4de6b7efd6a8d6c1a7b6e521e9f4c4a2c1d6e76b6f7c3a6b8d requests2.31.0 --hashsha256:9b47d3f5a6f8d1e2d81e9d0e0b2d4f526b4c5b9e742e6f3a2d31e4b5f7c4f5a2e生成哈希有两个途径一是pip hash命令针对单个文件计算二是用pip-tools的pip-compile --generate-hashes生成整个锁文件。后者在真实项目里更实用。--require-hashes的状态下有几个硬性限制必须知道不能用-e可编辑安装。不能用版本范围比如flask3.0所有包必须锁定精确版本。间接依赖也必须出现在requirements里并且有哈希不能靠pip自动解析。也就是说你必须在清单里列出完整依赖树。第三点是很多人失败的原因。平时你只写顶层依赖pip会自动带上间接依赖开了--require-hashes它要求清单里能看到的每个包都有哈希间接依赖一旦没有被锁定pip会直接报错。所以项目里真要启用几乎必然要引入锁文件工具手工维护是不现实的。3.2 constraints.txt统一多个项目的版本天花板constraints.txt是一个概念上很像requirements、行为上却完全不同的文件。它的作用是只约束版本不触发安装。也就是说你可以在一个单独的约束文件里写死某些包的版本上限然后在多个项目里通过-c constraints.txt引用它让所有项目共用同一套版本基线。pip install -r requirements.txt -c constraints.txt约束文件内容的写法与requirements类似# constraints.txt # 只限制版本不负责安装这些包 requests2.20,3.0 cryptography41.0它的价值在微服务架构里特别明显。假设你有五个服务每个服务的requirements里都有requests版本各不相同。某天安全通告说某版本以下的requests有个漏洞你需要立刻把所有服务的requests都提到安全版本。如果没有约束文件你得改五个项目的requirements有了它只改一个constraints文件就够了。要注意的是约束里的版本如果和requirements里的显式声明发生冲突pip会报错而不是默默忽略。这是个保护机制防止你以为约束生效了、实际装了个计划外的版本。所以把约束文件引入已有项目时第一件事就是对每个服务跑一遍pip install --dry-run -c constraints.txt -r requirements.txt提前找出冲突。3.3 VCS直装直接从Git仓库拉代码安装包pip支持直接从Git、Mercurial等版本控制仓库安装Python包。这在依赖尚未发布到PyPI、或者需要直接从私有仓库拉取某个分支的代码时非常实用。# 直接从Git安装指定分支或tag pip install githttps://examples.com/company/internal-lib.gitmain#egginternal-lib # 指定commit保证可复现 pip install githttps://examples.com/company/internal-lib.gita1b2c3d4ef567890abcdef#egginternal-lib # monorepo里只装子目录 pip install githttps://examples.com/company/monorepo.gitmain#subdirectorypython-packages/internal-libegginternal-lib这里的#egginternal-lib用来告诉pip这个项目的发行名称。modern pip对egg的要求宽松了一些但我建议还是写上尤其在monorepo里不写它pip可能不知道该怎么命名项目。指定commit而不是分支这是我从生产事故里学到的一条铁律分支会动commit永不变。用main今天装的和明天装的可能是不同代码排查问题时会疯掉。VCS安装时还有个问题pip会把整个仓库clone下来再执行构建。仓库大、历史深clone会非常慢。可以在clone前做浅克隆吗很遗憾pip本身不暴露这个选项。我的做法是先用git clone --depth 1手动把仓库拉到本地指定commit然后从本地路径安装。4. 性能、缓存与跨平台兼容从wheel构建到精确下载最后这块偏调优性质。它不会让功能发生变化但能让构建时间变短、让部署包变小、让跨平台的坑变少。都是一些平时注意不到、到关键时刻能救命的细节。4.1 pip cache缓存查看、清理与CI环境里的禁用策略pip从20.1版本开始内置了缓存管理。每次安装下载的wheel和HTTP响应都会被缓存下一次安装相同版本时就直接从缓存读取不再走网络。这在反复重建环境、或者频繁在虚拟环境间切换时能省大量时间。常用命令# 查看缓存占用 pip cache info # 列出缓存的wheel pip cache list # 删除特定包的所有缓存 pip cache remove numpy # 清空全部缓存 pip cache purge缓存带来便利的同时也埋过一个坑本地开发一个包版本号一直没变但源码改了重新pip wheel生成同名wheel时pip可能会从缓存里取出旧的那份导致你构建了半天还是旧代码。所以只要涉及本地构建我习惯加--no-cache-dir从源头绕开这个问题。CI环境里另一个常见问题缓存越积越大把构建机的磁盘塞满。现在很多流水线的镜像每次都是新拉的缓存意义不大反而拖慢首次构建。我的建议是在CI里设置PIP_NO_CACHE_DIR1明确禁用缓存让每次构建都干干净净。4.2 pip wheel把源码编译问题一次性解决在构建机上pip wheel和pip download很容易被混淆。简单说download是下载现成的包wheel是下载构建它会下载源码包或wheel然后本地构建成wheel文件输出到指定目录。pip wheel -r requirements.txt -w wheelhouse/为什么需要这个有些包在PyPI上没有当前平台对应的预编译wheel比如某些C扩展库你必须现场编译。pip install的时候也能编译但那是边装边编一旦编译失败你就得去排查整个环境。用pip wheel你可以在构建机上把能编译的全部编译成wheel形成一套完整的offline wheelhouse之后在目标机器上用--find-links安装就完全不需要编译工具链了。我之前处理过一个离线环境目标机器上是精简系统连gcc都没有。我就是在联网机器上跑pip wheel -r requirements.txt -w wheelhouse/ --no-cache-dir把一堆源码包全部编译成wheel然后拷贝过去离线安装。从那以后离线部署和必须现场编译这两件事就彻底解耦了。4.3 --only-binary与平台指定下载用对标签才能跨平台--only-binary:all:在第2章出现过这里专门讲讲它和平台参数的配合边界。wheel文件有一套规范化的命名标签比如numpy-1.26.4-cp311-cp311-manylinux_2_17_x86_64.whl里面编码了Python版本cp311、ABI、平台manylinux_2_17_x86_64等信息。pip正是靠这些标签决定是否能安装某个wheel。跨平台下载时你需要告诉pip我要的是哪个平台哪个Python版本的包。常用的组合参数# 下载Windows平台、Python 3.12、64位的wheel pip download numpy -d win_packages/ \ --platform win_amd64 \ --python-version 3.12 \ --implementation cp \ --only-binary:all: # 下载macOS Apple Silicon平台 pip download numpy -d mac_packages/ \ --platform macosx_11_0_arm64 \ --python-version 3.11 \ --implementation cp \ --only-binary:all:用这套参数有两条铁律纯Python包不受平台限制标签是py3-none-any任何平台都能装。所以下载时可以不加平台参数或者加了也无所谓。带C扩展的包必须严格匹配平台和ABI。cp311的包不能装在cp312上manylinux和musllinuxAlpine Linux是两套不同的平台标识不能混用。想知道当前环境支持哪些标签直接跑pip debug --verbose它会列出大量支持的tag信息。我在处理跨平台问题时经常拿它对照比你一个一个搜文档快得多。注意这套跨平台指定下载只适用于pip download和pip wheel不要尝试直接把下载的包用在当前环境安装你需要把文件传到目标平台再装。最后分享一条我个人的操作习惯新项目起步时我会先列顶层依赖用pip-compile生成锁文件并在CI里跑--require-hashes校验如果要交付离线环境构建机上提前做一套wheelhouse本地开发则统一用虚拟环境加pip install -e。这套流程跑顺之后依赖问题很少再来找我。pip的文档其实写得很好只是平时没人愿意翻。如果你今天只记住一条那就记住这句能用虚拟环境别直接装能锁版本就别漂移能提前准备wheel屋就别到现场编译。