一看到ModuleNotFoundError: No module named cryptography绝大多数Python开发者的第一反应都是哦又是它。这行报错几乎能出现在任何一台机器上——Windows、macOS、Linux、Docker容器里都逃不掉。有人是刚执行完pip install某个包一运行程序就崩在这里有人是明明已经装过了cryptography换个环境再跑却说找不到还有人是在pip install阶段就直接编译失败连安装这关都过不去。如果你也被这个报错卡过或者正在被它折磨这篇内容可以直接给你几套从轻到重的解法顺便把这个包为什么会这么“娇贵”的原因讲明白。它不仅是一个依赖缺失问题背后还牵扯到Python环境管理、二进制包分发、OpenSSL绑定、Rust工具链等一系列坑。适合刚入门的Python新手也适合被生产环境依赖问题搞得焦头烂额的中级开发者。1. 先说清楚这个报错到底是怎么冒出来的在动手敲命令之前我建议你先停下来确认一下自己属于哪种情况。同样是No module named cryptography原因可能完全不一样对应的修复手段也完全不同。1.1 最容易命中的三种场景场景一新装了一个包跑起来就报错。这是最常见的。你执行了pip install某个业务库安装过程很顺利可一运行程序立刻抛ModuleNotFoundError: No module named cryptography。问题在于这个库本身没有直接声明对cryptography的依赖或者声明了但版本范围非常宽松导致安装时没有把它正确带上来。场景二pip install 阶段就失败。这种报错通常不是ModuleNotFoundError而是ERROR: Could not build wheels for cryptography或error: cant find Rust compiler。因为cryptography的源码安装环节比较复杂缺少编译工具链时pip 会尝试从源码构建然后惨烈失败。场景三明明装过了换个环境又说找不到。很多人在这时是最懵的。pip show cryptography明明能看到版本号Python 里却照样提示模块缺失。这种情况十有八九是pip和python不配对——你用的pip安装到了A环境运行的python却是B环境。1.2 为什么“cryptography”这么容易躺着中枪这话得从依赖链说起。cryptography是一个底层的加解密库提供对称加密、非对称加密、证书处理、TLS握手等能力。你可以把它想象成工具箱里的螺丝刀很多人自己不直接买它但组装柜子的时候一定会用到。放到Python世界里它就是那个“柜子组装服务”的隐藏供应商。大量你耳熟能详的包最终都会依赖它。比如常见的网络库requests在某些场景下会走它paramikoSSH协议实现、pyOpenSSL、jwt如果是加密JWT、mysql-connector-python、httpx、truststore等等都跟它有关系。你装了一个看似八竿子打不着的包它却悄悄在你的环境里种下了一颗对cryptography的依赖种子。种子能不能发芽取决于pip的依赖解析结果也取决于当前环境里是否有兼容版本。这就是为什么它“中枪率”极高你根本不知道是哪一层依赖把它牵出来的。而一旦某个包锁定了不兼容版本或者环境太干净没把它装上去No module named cryptography就会准时出现在你面前。2. 快速止血先让代码跑起来再说遇到报错第一反应永远是先恢复可用状态再考虑长期方案。下面这三条路按优先级从低到高排列基本能解决九成以上的问题。2.1 最直接的操作补装依赖在项目虚拟环境或明确知道python路径的前提下直接执行python -m pip install cryptography注意我这里特意写的是python -m pip而不是裸的pip。这是一个非常重要的习惯。python -m pip能保证你调用的pip和当前python解释器是完全对应的从根源上规避“pip是pippython是python”的错位问题。装完之后验证一下python -c import cryptography; print(cryptography.__version__)能打印出版本号说明模块已经成功进入当前解释器的环境。如果这一步就过了后面内容你可以少看两章。2.2 装不上换版本、换镜像、锁定wheel如果pip install cryptography执行后报错先别慌看看是不是网络问题还是编译问题。国内网络环境下从PyPI官方源下载有时会很慢甚至超时你可以换到公共镜像源python -m pip install cryptography -i https://pypi.tuna.tsinghua.edu.cn/simple如果依然编译报错后面第三章细说最省事的办法是装一个和当前Python版本匹配的预编译版本。一般建议指定一个较新的稳定版本比如python -m pip install cryptography42.0.0cryptography从很早期就为Windows、macOS、Linux的主流平台提供wheel预编译包。理论上现代Python版本下直接安装应该都能拉到wheel包不走源码编译。如果pip非要走源码编译大概率是你的Python版本太老或太新超出了官方wheel的支持范围。2.3 装上了还是找不到检查环境配对这是最烧脑的一类坑。pip show cryptography显示已安装python -c import cryptography却报错。我强烈怀疑你的机器上存在多个Python环境。比如macOS自带Python 3.9你又通过安装包装了Python 3.11在命令行敲pip时它可能指向3.11但python命令却指向3.9。排查方法# Windows where python where pip # Linux / macOS which -a python which -a pip如果看到python和pip所在目录完全不同那问题就出在这。统一方式很简单全部用python -m pip操作并且确认你运行程序的python就是同一个。提示与其在两个环境之间反复横跳不如直接删掉一堆旧版本只保留一个你常用的Python然后所有项目一律用虚拟环境隔离。这一步能帮你省掉未来无数个“为什么装不上”的深夜。3. 拆开暗箱为什么cryptography会编译失败很多人遇到pip install cryptography时直接被一串编译日志劝退。这一章我带你看看这块“硬骨头”的内部构造看完你就能理解为什么它比普通纯Python包难伺候得多。3.1 wheel 与 sdist 的分发差异Python包分发有两种主流形态wheel预编译好的二进制包pip下载后直接解压就能用。sdist源码包pip下载后需要在你机器上完成编译构建。对于大多数纯Python库即便走sdist也就是复制文件而已。但cryptography不一样它包含C扩展和Rust实现的底层组件。如果pip在目标平台上找不到合适的wheel就会退回到sdist然后开始要编译。编译就需要工具链工具链不齐就报错。现代pip版本在常规系统和Python版本组合下基本都能拉取到对应的wheel。如果你发现pip在尝试构建源码我建议你检查两件事一是Python版本是否太老比如3.6甚至更早二是平台是否很特殊比如某些Linux发行版的架构。3.2 Rust工具链和OpenSSL的故事要理解为什么编译要Rust得先知道cryptography的架构演进。这个库并不是纯粹的OpenSSL封装它的部分底层原语如ASN.1编解码是用Rust重写的。因此在从源码编译时Rust编译器是硬性依赖。如果你机器上没有安装Rust工具链就会看到这类经典报错error: cant find Rust compiler与此同时Windows上编译通常还需要Visual Studio Build Tools中的C工具链Linux上需要openssl开发头文件macOS上需要Command Line Tools。它们缺一不可。我的建议是能不编译就别编译。优先确保pip能拉到wheel包。只有在极少数无法满足的情况下才去考虑源码安装然后照着官方文档把对应平台依赖装齐。3.3 平台差异Windows / macOS / Linux 各自注意的点Windows直接下载官方Python时绝大多数情况下pip会拉到wheel。如果你是从源码装那就要装Visual Studio Build Tools勾选“使用C的桌面开发”和Rust工具链。macOS官方Python安装包一般没问题。遇到问题时先执行xcode-select --install装好命令行工具。如果是Homebrew的Python偶尔会牵扯到openssl3的路径问题这时可以试试brew install openssl再编译。Linux最常出问题的场景。Ubuntu/Debian下需要build-essential libssl-dev libffi-dev python3-devRedHat系需要gcc openssl-devel libffi-devel python3-devel。安装完这些再回头编译成功率会高很多。3.4 Python版本和cryptography版本兼容速查cryptography的新版本对Python版本有一定门槛。如果你的Python版本较老pip resolver会自动选择老版本而老版本可能没有新平台的预编译wheel又会引发编译。这是一个连锁反应。我给你一张兼容参考表以实际发布说明为准cryptography 版本段建议的Python版本备注3.x3.6老项目常见但较老版本可能编译困难38.x - 41.x3.7较为稳妥42.x 及以上3.7目前推荐wheel覆盖好43.x 及更新依赖更高Python版本若你的环境偏老慎追最新如果项目要求Python 3.6或更早你可能需要锁定一个较老的cryptography版本而不是安装最新版。反之如果Python很新老版本反而可能没有对应wheel也需要挑选新版本。4. 从根源修依赖环境体检与重建前面几章解决的是“眼前怎么跑通”但如果你发现这个报错反复出现或者解决一个又冒出下一个我建议你干脆对Python环境做一次系统性体检。毕竟在真实项目里依赖问题向来是连锁反应。4.1 用 pipdeptree 看清楚依赖树很多依赖冲突问题光看requirements清单是看不出来的。你需要把整棵依赖树展开看看谁在依赖谁。python -m pip install pipdeptree python -m pipdeptree输出里会列出每个包的依赖关系。你可以搜索cryptography确认它到底是怎么被引入的├── paramiko3.4.0 │ └── cryptography42.0.5 ├── pyOpenSSL24.1.0 │ └── cryptography42.0.5这个信息很有价值。假如你看到某个包依赖了cryptography40.0而你环境里装的是42.x那么你要么调整版本约束要么考虑那个依赖包是否需要升级。不要强行去装两个不同版本——同一环境下同名包只能有一个版本。4.2 虚拟环境重建法干净利落如果你已经没法判断当前环境被污染成什么样了不要挣扎直接重建虚拟环境。这个操作成本低、效果立竿见影。# 删除旧环境 rm -rf venv # 重新创建 python -m venv venv # 激活 # Windows: venv\Scripts\activate # Linux / macOS: source venv/bin/activate # 重新安装依赖 python -m pip install --upgrade pip python -m pip install -r requirements.txt重建之后90%的怪问题都会消失。原因很简单虚拟环境重建会强制pip重新做依赖解析很多之前残留的半安装状态、deprecated版本的包全都会清除干净。注意如果requirements.txt本身就有问题比如锁定了互相冲突的版本重建后照样会装失败。这时候你需要单独逐步安装依赖或者用pip install 包名一个个排除问题源头。4.3 从requirements.txt精确还原环境如果项目对依赖版本非常敏感我建议你把依赖锁定成这样cryptography42.0.5 paramiko3.4.0但在实际排查阶段由于版本锁得太死pip可能找不到完全匹配的组合。此时可以分两步python -m pip install -r requirements.txt --dry-run--dry-run会模拟解析依赖但不实际安装能提前看到会不会有冲突。如果发现冲突你需要手动调整requirements里的版本范围放宽到能兼容的区间再正式安装。4.4 离线环境怎么装生产内网机器常常连不上外网。我已经不止一次遇到这种场景项目在内网部署pip install时提示找不到包最终只能靠离线wheel解决。在能联网的机器上先下载好对应平台的wheelpython -m pip download cryptography42.0.5 -d ./wheels然后把整个wheels目录带到离线机器上安装python -m pip install --no-index --find-links./wheels cryptography离线环境下尤其要注意Python版本和操作系统架构必须完全匹配。在Windows x64上下的wheel不能直接丢给x86版本的Python否则还是会触发源码编译然后崩溃。5. 踩坑实录与速查表这一章我用几个我亲身遇到过、或者同事反复遭遇过的场景作为素材帮你把问题最典型的形态一次看透。5.1 场景实录一个包升级引发的“连带爆炸”某次我在给一个模拟项目加SSH功能装了个paramiko。安装完成后运行脚本直接爆出No module named cryptography。我第一反应是直接补装但装完再跑却又提示版本太低。后来一查发现项目里另一个库把cryptography锁在了3.x而paramiko新版要求4.x导致resolver选择了3.x但这个老版本在当前的Python版本下没有wheel编译又失败。最后解决办法是把那个早期库升级到兼容新版整个依赖树才终于平了。这件事给我的教训是报错本身往往不是根因依赖冲突的上游才是。遇到这种连锁反应优先看依赖树。5.2 常错动作清单用裸pip而不是python -m pip。多环境机器上踩雷概率极高。在代码目录下直接全局安装包。把依赖装进了系统环境项目环境干干净净运行时照样报错。不激活虚拟环境就安装。shell提示符没有显示(venv)装到了别的环境里。把pip install cryptography当作万能修复。如果你没搞清楚版本冲突装完可能又冒出其他模块缺失。在Docker镜像里不用--no-cache-dir。旧缓存偶尔会导致装到过时版本引起后续连锁问题。5.3 报错速查表异常表现典型原因优先尝试No module named cryptographypip show有版本python和pip指向不同环境统一用python -m pip检查which -a python安装报cant find Rust compiler源码编译缺少Rust工具链换wheel或先装Rust再编译安装报Failed to build cryptography缺少C编译器或OpenSSL头文件安装对应平台的编译依赖安装后import cryptography版本过低依赖树中旧库锁定了老版本升级上游库或调整版本范围内网/离线环境安装失败无法访问PyPI源提前下载wheel使用--no-index --find-links装完新包后原有项目崩了新包upgrade了cryptography用pipdeptree查依赖必要时回滚版本5.4 一些少有人提的细节补充几个容易被忽略的点cryptography对Python版本的支持范围是动态的老版本不会照顾新Python新版本也不会照顾老Python。碰到兼容问题先查官方发布说明不要瞎猜。如果项目有可能长期维护我建议在requirements里直接写明cryptography42.0.0这样的下限约束而不是锁定一个精确版本这样既留了升级空间又不会让pip装到一个奇怪的老版本。Linux下如果用的是基于Alpine的Docker镜像cryptography的wheel往往装不上要走apk add gcc musl-dev libffi-dev openssl-dev之类的步骤编译。这块坑非常深生产环境中尽量改用基于Debian的镜像。我在实际工作中越来越觉得这类ModuleNotFoundError看着低级但它最能暴露你对Python环境管理的理解程度。很多人解决了这一单问题下一次换个机器照样翻车因为他的环境管理习惯没有变。每次碰到这类问题我都会先反思这个项目是不是用了虚拟环境依赖有没有锁定Python版本是不是太乱把这几件事理顺比记住任何一条具体命令都管用。最后分享一个小技巧当你准备给一台新电脑或新服务器部署项目时别急着克隆代码先跑一遍python --version和python -m pip --version确认解释器和pip来源一致后再开始行动。这个动作花不到一分钟能省掉你后面至少一小时的排查时间。环境干净了cryptography就会安安静静躺在依赖里再也不会突然跳出来刷存在感。 
长河君 · 2026/10/14 4:22:57 · 阅读 1.2k Python报错No module named cryptography：依赖、环境与修复方法
一看到ModuleNotFoundError: No module named cryptography绝大多数Python开发者的第一反应都是哦又是它。这行报错几乎能出现在任何一台机器上——Windows、macOS、Linux、Docker容器里都逃不掉。有人是刚执行完pip install某个包一运行程序就崩在这里有人是明明已经装过了cryptography换个环境再跑却说找不到还有人是在pip install阶段就直接编译失败连安装这关都过不去。如果你也被这个报错卡过或者正在被它折磨这篇内容可以直接给你几套从轻到重的解法顺便把这个包为什么会这么“娇贵”的原因讲明白。它不仅是一个依赖缺失问题背后还牵扯到Python环境管理、二进制包分发、OpenSSL绑定、Rust工具链等一系列坑。适合刚入门的Python新手也适合被生产环境依赖问题搞得焦头烂额的中级开发者。1. 先说清楚这个报错到底是怎么冒出来的在动手敲命令之前我建议你先停下来确认一下自己属于哪种情况。同样是No module named cryptography原因可能完全不一样对应的修复手段也完全不同。1.1 最容易命中的三种场景场景一新装了一个包跑起来就报错。这是最常见的。你执行了pip install某个业务库安装过程很顺利可一运行程序立刻抛ModuleNotFoundError: No module named cryptography。问题在于这个库本身没有直接声明对cryptography的依赖或者声明了但版本范围非常宽松导致安装时没有把它正确带上来。场景二pip install 阶段就失败。这种报错通常不是ModuleNotFoundError而是ERROR: Could not build wheels for cryptography或error: cant find Rust compiler。因为cryptography的源码安装环节比较复杂缺少编译工具链时pip 会尝试从源码构建然后惨烈失败。场景三明明装过了换个环境又说找不到。很多人在这时是最懵的。pip show cryptography明明能看到版本号Python 里却照样提示模块缺失。这种情况十有八九是pip和python不配对——你用的pip安装到了A环境运行的python却是B环境。1.2 为什么“cryptography”这么容易躺着中枪这话得从依赖链说起。cryptography是一个底层的加解密库提供对称加密、非对称加密、证书处理、TLS握手等能力。你可以把它想象成工具箱里的螺丝刀很多人自己不直接买它但组装柜子的时候一定会用到。放到Python世界里它就是那个“柜子组装服务”的隐藏供应商。大量你耳熟能详的包最终都会依赖它。比如常见的网络库requests在某些场景下会走它paramikoSSH协议实现、pyOpenSSL、jwt如果是加密JWT、mysql-connector-python、httpx、truststore等等都跟它有关系。你装了一个看似八竿子打不着的包它却悄悄在你的环境里种下了一颗对cryptography的依赖种子。种子能不能发芽取决于pip的依赖解析结果也取决于当前环境里是否有兼容版本。这就是为什么它“中枪率”极高你根本不知道是哪一层依赖把它牵出来的。而一旦某个包锁定了不兼容版本或者环境太干净没把它装上去No module named cryptography就会准时出现在你面前。2. 快速止血先让代码跑起来再说遇到报错第一反应永远是先恢复可用状态再考虑长期方案。下面这三条路按优先级从低到高排列基本能解决九成以上的问题。2.1 最直接的操作补装依赖在项目虚拟环境或明确知道python路径的前提下直接执行python -m pip install cryptography注意我这里特意写的是python -m pip而不是裸的pip。这是一个非常重要的习惯。python -m pip能保证你调用的pip和当前python解释器是完全对应的从根源上规避“pip是pippython是python”的错位问题。装完之后验证一下python -c import cryptography; print(cryptography.__version__)能打印出版本号说明模块已经成功进入当前解释器的环境。如果这一步就过了后面内容你可以少看两章。2.2 装不上换版本、换镜像、锁定wheel如果pip install cryptography执行后报错先别慌看看是不是网络问题还是编译问题。国内网络环境下从PyPI官方源下载有时会很慢甚至超时你可以换到公共镜像源python -m pip install cryptography -i https://pypi.tuna.tsinghua.edu.cn/simple如果依然编译报错后面第三章细说最省事的办法是装一个和当前Python版本匹配的预编译版本。一般建议指定一个较新的稳定版本比如python -m pip install cryptography42.0.0cryptography从很早期就为Windows、macOS、Linux的主流平台提供wheel预编译包。理论上现代Python版本下直接安装应该都能拉到wheel包不走源码编译。如果pip非要走源码编译大概率是你的Python版本太老或太新超出了官方wheel的支持范围。2.3 装上了还是找不到检查环境配对这是最烧脑的一类坑。pip show cryptography显示已安装python -c import cryptography却报错。我强烈怀疑你的机器上存在多个Python环境。比如macOS自带Python 3.9你又通过安装包装了Python 3.11在命令行敲pip时它可能指向3.11但python命令却指向3.9。排查方法# Windows where python where pip # Linux / macOS which -a python which -a pip如果看到python和pip所在目录完全不同那问题就出在这。统一方式很简单全部用python -m pip操作并且确认你运行程序的python就是同一个。提示与其在两个环境之间反复横跳不如直接删掉一堆旧版本只保留一个你常用的Python然后所有项目一律用虚拟环境隔离。这一步能帮你省掉未来无数个“为什么装不上”的深夜。3. 拆开暗箱为什么cryptography会编译失败很多人遇到pip install cryptography时直接被一串编译日志劝退。这一章我带你看看这块“硬骨头”的内部构造看完你就能理解为什么它比普通纯Python包难伺候得多。3.1 wheel 与 sdist 的分发差异Python包分发有两种主流形态wheel预编译好的二进制包pip下载后直接解压就能用。sdist源码包pip下载后需要在你机器上完成编译构建。对于大多数纯Python库即便走sdist也就是复制文件而已。但cryptography不一样它包含C扩展和Rust实现的底层组件。如果pip在目标平台上找不到合适的wheel就会退回到sdist然后开始要编译。编译就需要工具链工具链不齐就报错。现代pip版本在常规系统和Python版本组合下基本都能拉取到对应的wheel。如果你发现pip在尝试构建源码我建议你检查两件事一是Python版本是否太老比如3.6甚至更早二是平台是否很特殊比如某些Linux发行版的架构。3.2 Rust工具链和OpenSSL的故事要理解为什么编译要Rust得先知道cryptography的架构演进。这个库并不是纯粹的OpenSSL封装它的部分底层原语如ASN.1编解码是用Rust重写的。因此在从源码编译时Rust编译器是硬性依赖。如果你机器上没有安装Rust工具链就会看到这类经典报错error: cant find Rust compiler与此同时Windows上编译通常还需要Visual Studio Build Tools中的C工具链Linux上需要openssl开发头文件macOS上需要Command Line Tools。它们缺一不可。我的建议是能不编译就别编译。优先确保pip能拉到wheel包。只有在极少数无法满足的情况下才去考虑源码安装然后照着官方文档把对应平台依赖装齐。3.3 平台差异Windows / macOS / Linux 各自注意的点Windows直接下载官方Python时绝大多数情况下pip会拉到wheel。如果你是从源码装那就要装Visual Studio Build Tools勾选“使用C的桌面开发”和Rust工具链。macOS官方Python安装包一般没问题。遇到问题时先执行xcode-select --install装好命令行工具。如果是Homebrew的Python偶尔会牵扯到openssl3的路径问题这时可以试试brew install openssl再编译。Linux最常出问题的场景。Ubuntu/Debian下需要build-essential libssl-dev libffi-dev python3-devRedHat系需要gcc openssl-devel libffi-devel python3-devel。安装完这些再回头编译成功率会高很多。3.4 Python版本和cryptography版本兼容速查cryptography的新版本对Python版本有一定门槛。如果你的Python版本较老pip resolver会自动选择老版本而老版本可能没有新平台的预编译wheel又会引发编译。这是一个连锁反应。我给你一张兼容参考表以实际发布说明为准cryptography 版本段建议的Python版本备注3.x3.6老项目常见但较老版本可能编译困难38.x - 41.x3.7较为稳妥42.x 及以上3.7目前推荐wheel覆盖好43.x 及更新依赖更高Python版本若你的环境偏老慎追最新如果项目要求Python 3.6或更早你可能需要锁定一个较老的cryptography版本而不是安装最新版。反之如果Python很新老版本反而可能没有对应wheel也需要挑选新版本。4. 从根源修依赖环境体检与重建前面几章解决的是“眼前怎么跑通”但如果你发现这个报错反复出现或者解决一个又冒出下一个我建议你干脆对Python环境做一次系统性体检。毕竟在真实项目里依赖问题向来是连锁反应。4.1 用 pipdeptree 看清楚依赖树很多依赖冲突问题光看requirements清单是看不出来的。你需要把整棵依赖树展开看看谁在依赖谁。python -m pip install pipdeptree python -m pipdeptree输出里会列出每个包的依赖关系。你可以搜索cryptography确认它到底是怎么被引入的├── paramiko3.4.0 │ └── cryptography42.0.5 ├── pyOpenSSL24.1.0 │ └── cryptography42.0.5这个信息很有价值。假如你看到某个包依赖了cryptography40.0而你环境里装的是42.x那么你要么调整版本约束要么考虑那个依赖包是否需要升级。不要强行去装两个不同版本——同一环境下同名包只能有一个版本。4.2 虚拟环境重建法干净利落如果你已经没法判断当前环境被污染成什么样了不要挣扎直接重建虚拟环境。这个操作成本低、效果立竿见影。# 删除旧环境 rm -rf venv # 重新创建 python -m venv venv # 激活 # Windows: venv\Scripts\activate # Linux / macOS: source venv/bin/activate # 重新安装依赖 python -m pip install --upgrade pip python -m pip install -r requirements.txt重建之后90%的怪问题都会消失。原因很简单虚拟环境重建会强制pip重新做依赖解析很多之前残留的半安装状态、deprecated版本的包全都会清除干净。注意如果requirements.txt本身就有问题比如锁定了互相冲突的版本重建后照样会装失败。这时候你需要单独逐步安装依赖或者用pip install 包名一个个排除问题源头。4.3 从requirements.txt精确还原环境如果项目对依赖版本非常敏感我建议你把依赖锁定成这样cryptography42.0.5 paramiko3.4.0但在实际排查阶段由于版本锁得太死pip可能找不到完全匹配的组合。此时可以分两步python -m pip install -r requirements.txt --dry-run--dry-run会模拟解析依赖但不实际安装能提前看到会不会有冲突。如果发现冲突你需要手动调整requirements里的版本范围放宽到能兼容的区间再正式安装。4.4 离线环境怎么装生产内网机器常常连不上外网。我已经不止一次遇到这种场景项目在内网部署pip install时提示找不到包最终只能靠离线wheel解决。在能联网的机器上先下载好对应平台的wheelpython -m pip download cryptography42.0.5 -d ./wheels然后把整个wheels目录带到离线机器上安装python -m pip install --no-index --find-links./wheels cryptography离线环境下尤其要注意Python版本和操作系统架构必须完全匹配。在Windows x64上下的wheel不能直接丢给x86版本的Python否则还是会触发源码编译然后崩溃。5. 踩坑实录与速查表这一章我用几个我亲身遇到过、或者同事反复遭遇过的场景作为素材帮你把问题最典型的形态一次看透。5.1 场景实录一个包升级引发的“连带爆炸”某次我在给一个模拟项目加SSH功能装了个paramiko。安装完成后运行脚本直接爆出No module named cryptography。我第一反应是直接补装但装完再跑却又提示版本太低。后来一查发现项目里另一个库把cryptography锁在了3.x而paramiko新版要求4.x导致resolver选择了3.x但这个老版本在当前的Python版本下没有wheel编译又失败。最后解决办法是把那个早期库升级到兼容新版整个依赖树才终于平了。这件事给我的教训是报错本身往往不是根因依赖冲突的上游才是。遇到这种连锁反应优先看依赖树。5.2 常错动作清单用裸pip而不是python -m pip。多环境机器上踩雷概率极高。在代码目录下直接全局安装包。把依赖装进了系统环境项目环境干干净净运行时照样报错。不激活虚拟环境就安装。shell提示符没有显示(venv)装到了别的环境里。把pip install cryptography当作万能修复。如果你没搞清楚版本冲突装完可能又冒出其他模块缺失。在Docker镜像里不用--no-cache-dir。旧缓存偶尔会导致装到过时版本引起后续连锁问题。5.3 报错速查表异常表现典型原因优先尝试No module named cryptographypip show有版本python和pip指向不同环境统一用python -m pip检查which -a python安装报cant find Rust compiler源码编译缺少Rust工具链换wheel或先装Rust再编译安装报Failed to build cryptography缺少C编译器或OpenSSL头文件安装对应平台的编译依赖安装后import cryptography版本过低依赖树中旧库锁定了老版本升级上游库或调整版本范围内网/离线环境安装失败无法访问PyPI源提前下载wheel使用--no-index --find-links装完新包后原有项目崩了新包upgrade了cryptography用pipdeptree查依赖必要时回滚版本5.4 一些少有人提的细节补充几个容易被忽略的点cryptography对Python版本的支持范围是动态的老版本不会照顾新Python新版本也不会照顾老Python。碰到兼容问题先查官方发布说明不要瞎猜。如果项目有可能长期维护我建议在requirements里直接写明cryptography42.0.0这样的下限约束而不是锁定一个精确版本这样既留了升级空间又不会让pip装到一个奇怪的老版本。Linux下如果用的是基于Alpine的Docker镜像cryptography的wheel往往装不上要走apk add gcc musl-dev libffi-dev openssl-dev之类的步骤编译。这块坑非常深生产环境中尽量改用基于Debian的镜像。我在实际工作中越来越觉得这类ModuleNotFoundError看着低级但它最能暴露你对Python环境管理的理解程度。很多人解决了这一单问题下一次换个机器照样翻车因为他的环境管理习惯没有变。每次碰到这类问题我都会先反思这个项目是不是用了虚拟环境依赖有没有锁定Python版本是不是太乱把这几件事理顺比记住任何一条具体命令都管用。最后分享一个小技巧当你准备给一台新电脑或新服务器部署项目时别急着克隆代码先跑一遍python --version和python -m pip --version确认解释器和pip来源一致后再开始行动。这个动作花不到一分钟能省掉你后面至少一小时的排查时间。环境干净了cryptography就会安安静静躺在依赖里再也不会突然跳出来刷存在感。