上个月我接手一个老项目，代码里全是只能跑在 Python 3.7 上的依赖。我打开终端，在刚换的 M2 MacBook Pro 上很自然地敲下这行命令：
conda create -n legacy-py37 python=3.7结果 conda 先是在 solving environment 阶段卡了半天，最后甩给我一个PackagesNotFoundError: The following packages are not available from current channels: python=3.7。我第一反应是网络问题，于是反复检查源、删~/.condarc、重装 conda，一下午全耗在同一个报错上。
后来我才彻底搞明白，这个报错背后其实是两个独立的问题：一个是 Python 3.7 已经结束生命周期，Anaconda 默认源不再提供它的构建包；另一个是 M 系列芯片的 conda 默认走osx-arm64平台，而 Python 3.7 在 arm64 生态上几乎没有完整构建。这篇文章就完整复盘一下我当时的排查思路、最终验证过的解决方案，以及环境建好之后还会遇到的坑。如果你也卡在这个报错上，照着做应该能省下好几个小时。
1. 报错现场与真正的定位：这不是网络问题，是仓库缺包
1.1 还原一条典型的 PackagesNotFoundError 日志
很多人看到solving environment: failed就觉得是 conda 连不上服务器，其实不是。我当时那台机器上的完整日志大概是这样的：
conda create -n py37 python=3.7 Collecting package metadata (current_repodata.json): done Solving environment: failed with initial frozen solve. Retrying with flexible solve. Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source. Solving environment: failed with repodata from repodata.json, will retry with next repodata source. Solving environment: failed PackagesNotFoundError: The following packages are not available from current channels: - python=3.7注意两个关键点。
第一，日志里Collecting package metadata显示的是done，说明 conda 已经成功从所有配置的 channel 里拉取了包索引。它能拿到索引，但索引里没有你要的包。
第二，报错类型是PackagesNotFoundError，而不是UnsatisfiableError。conda 的报错体系里，这两者含义完全不同。PackagesNotFoundError是"仓库里根本没有这个包或这个版本"；UnsatisfiableError是"包存在，但是这个版本和依赖树里的其他包冲突"。前者相当于你去餐厅点菜，服务员说菜单上没这道菜；后者是菜单上有菜，但厨师发现配菜和你之前点的冲突，做不出来。
很多人在PackagesNotFoundError上浪费大量时间，去调 channel 顺序、换 Python 版本、甚至重装 conda，这是因为他们没意识到，问题根本不是"网络没连上"或"求解失败"，而是从最初开始，你配置的 channel 里就没有 Python 3.7 这个选项。
1.2 conda 的求解器到底在做什么
理解这一点，得先知道 conda 解决环境的机制。conda 每次执行create、install时，会先从你配置的所有 channel 里下载一份最新的repodata.json，可以理解成该 channel 的"完整菜单"。这里面记录了每个包的所有版本、依赖关系、适用的操作系统和 CPU 架构。
然后 solver 会做的事情是：把你命令行里的约束（比如python=3.7）、当前环境的约束（比如已经装了 numpy 1.21）、以及目标平台的约束放到一起，试图找出一组不冲突的包版本。这本身是一个组合问题，也是 conda 历史上被吐槽最多的"卡在 solving environment"的来源。
当 solver 怎么都找不到一个满足python=3.7的包时，它最终会抛出PackagesNotFoundError。注意，这里"找不到"不等于"全世界都没有 Python 3.7"，而是"当前所有 channel + 当前平台 + 当前约束条件下没有"。所以排查这个报错，第一件事永远是确认两件事：你的 channel 配置里有没有包含 conda-forge，以及你的 conda 跑在哪个平台架构上。
1.3 时间线才是头号元凶：Python 3.7 已从默认源退役
为什么五年前大家一条conda create -n py37 python=3.7就能成功？因为那时候 Python 3.7 还在活跃维护期，Anaconda 官方源（也就是 defaults channel）一直会为它生成新的包。
Python 3.7 在 2023 年中正式结束生命周期，进入 EOL 状态，Anaconda 也随即停止为默认源提供 3.7 的构建包。如果你现在打开 defaults 的repodata.json去搜，里面可能还留着部分历史版本，但 conda 的新增求解逻辑会在很多情况下把这类已停止维护的版本排除在外，尤其是当你想新建一个干净环境时，很容易直接得到PackagesNotFoundError。
conda-forge 社区也做了同样的事情：它虽然保留了 Python 3.7 的历史构建，但基本停止了为主要生态包补新的 3.7 版本。这就带来一个连锁效应：即使你能装上一个 3.7，后续想装依赖时依然会缺这缺那。所以，在处理这个报错前，先接受一个事实：Python 3.7 生态整体已经进入"存量维持"状态，而不是"随时可装"状态。这不是 conda 的 bug，而是软件生命周期走到头之后，所有发行渠道都会发生的正常现象。
2. Intel 和 Apple Silicon 是真分歧点：osx-arm64 没有完整的 3.7 生态
2.1 先确认你的 conda 跑在哪个平台
Mac 上最容易隐藏问题的一层，就是平台架构。同样是"Mac"，conda 眼里分两种：
osx-64：Intel 芯片的原生平台，也是 Apple Silicon 通过 Rosetta 转译后兼容的平台。osx-arm64：M1、M2、M3 系列的原生平台。
绝大多数情况下，Intel Mac 上安装的 conda 是 x86_64 架构，平台显示为osx-64；M 系列 Mac 上安装的 conda 则默认是 arm64 架构，平台显示为osx-arm64。
可以先跑这条命令确认：
conda info | grep platform也可以直接看 base 环境里的 Python 架构：
python -c "import platform; print(platform.machine())"如果显示arm64，说明你现在跑的 conda 是原生osx-arm64；显示x86_64，则是osx-64或 Rosetta 下的环境。
为什么要先确认这个？因为很多人拿着 M 系芯片的电脑，踩的其实是同一个坑：conda 默认只在你当前的平台目录下找包，所以它完全是按osx-arm64的规则去求解 Python 3.7 的，而 arm64 平台上根本不提供完整的 3.7 构建。
2.2 为什么 arm64 平台上没有 Python 3.7
这里涉及一点历史背景。conda-forge 社区从 2020 年底开始正式支持osx-arm64，当时做了一次大规模的"迁移"（migration），把当时还在活跃维护的 Python 3.8、3.9 及其核心生态包都补上了 arm64 构建。
Python 3.7 的处境很尴尬：它当时已经过了主要功能开发期，进入了只有安全修补的维护模式。conda-forge 的许多底层包在处理 arm64 迁移时，根本没有把 3.7 纳入新平台的支持范围。所以你可以理解为：Python 3.7 在 conda-forge 上完成了 x86 平台的历史使命，但它从未系统性地进入 arm64 时代。
Anaconda 官方源虽然也从 2020 年起发布了osx-arm64的 conda 包，但覆盖的 Python 版本同样只有当时活跃的 3.8、3.9、3.10。你去搜官方源里osx-arm64目录下有没有python-3.7的构建包，答案是几乎没有。这就导致了一个非常典型的"平台断层"：
- Intel Mac（
osx-64）加 conda-forge，可以装 Python 3.7； - M 系列 Mac 原生跑
osx-arm64，即使加了 conda-forge，也大概率装不上 Python 3.7。
这个结论我是在多次尝试之后才确认的，因为它和很多老旧教程的直觉正好相反。老教程里"随便装 3.7"的经验，在 M 系列 Mac 上恰恰是最先失效的。
2.3 一个容易迷惑的现象：搜索能看到 3.7，但创建还是失败
有朋友可能会问：我用conda search python=3.7 -c conda-forge明明能搜到一堆版本号，为什么创建环境还是报PackagesNotFoundError？
这里有两个陷阱。
第一个陷阱是：conda search默认展示的是当前平台下可用的包。如果你是osx-arm64的 conda，并且直接把python=3.7传给conda create，solver 会优先在当前平台目录里找。它不会因为你搜到了osx-64的构建就自动帮你装到osx-arm64环境里，平台不一样，包是装不进去的。
第二个陷阱是：即使你在某个渠道里找到了一个适配当前平台的python=3.7构建，也不代表能成功创建环境。Python 是一门解释型语言的运行时，但它不是孤立存在的。创建环境的时候，solver 会把python=3.7和它依赖的libpython、openssl、readline、zlib、ncurses等一系列底层库放到一起求解。3.7 的历史依赖链条在 arm64 上并不完整，只要其中一个依赖没有对应版本的构建，solver 就会整体放弃，最后仍然报同样的错误。
换句话说：即使你找到了"果盘里有 3.7"的证据，它旁边还缺配套的"餐具"和"配料"，厨师依然做不了这道菜。这种"看起来存在但装不上"的情况，是最容易让人在错误方向上死磕的。
3. 从验证到落地：三套亲测可行的解决方法
3.1 解法一（先试这个）：让 conda-forge 参与求解
这一步的价值很直接：conda-forge 是目前唯一还保留着大量 Python 3.7 历史构建的大型 channel。只要你的平台不是 arm64，或者你愿意用 Rosetta 跑 x86 环境，conda-forge 基本都能救你。
先添加 channel 并确认能搜到包：
conda config --add channels conda-forge conda config --set channel_priority flexible CONDA_SUBPOLATFORM=osx-64 conda search python=3.7 -c conda-forge注意，不要为了"优先使用 conda-forge"而把 channel_priority 设成 strict。Python 3.7 的依赖链条本来就不完整，strict 模式会让 solver 在依赖不满足时直接失败，反而更容易报错。保持默认的 flexible 模式，solver 才有机会在多个 channel 之间补全依赖。
确认搜到之后，创建环境：
conda create -n py37 python=3.7 -c conda-forge --yes在 Intel Mac 上，这条命令基本可以直接成功。在 M 系列 Mac 的osx-arm64原生 conda 下，如果你上一段搜索出来的是空结果，那就直接跳到下面的解法二。
这里我给一个选型对照表，方便你一眼定位自己该走哪条路：
| 你的 Mac 芯片 | conda 平台 | 直接官方源 | 加 conda-forge | 推荐方案 |
|---|---|---|---|---|
| Intel | osx-64 | 大概率失败 | 通常成功 | 解法一 |
| M1/M2/M3 | osx-arm64 | 必然失败 | 通常仍失败 | 解法二 |
| M1/M2/M3 | Rosetta 下的 osx-64 conda | 容易失败 | 通常成功 | 解法三 |
3.2 解法二（M 系列专用）：用 Rosetta 2 建 osx-64 环境
既然 Python 3.7 在 arm64 原生生态里缺失，最实用的破解办法不是硬怼 arm64，而是让 conda 去创建一套osx-64平台的环境，跑在 Rosetta 2 转译之上。
如果你的 Mac 还没装过 Rosetta，先执行：
softwareupdate --install-rosetta安装完成后，用一个环境变量告诉 conda 去拉osx-64的包：
CONDA_SUBPOLATFORM=osx-64 conda create -n py37 python=3.7 -c conda-forge --yes这个CONDA_SUBPOLATFORM=osx-64是关键的临门一脚。它让 conda 暂时忽略当前原生平台，转而去订阅osx-64的包索引。这样 conda-forge 里完整的 Python 3.7 构建就重新进入视野了，solver 也能正常求解。
环境创建好之后，一个极其容易踩的坑是：激活 py37 后，再安装任何包，都必须继续带上CONDA_SUBPOLATFORM=osx-64。
conda activate py37 CONDA_SUBPOLATFORM=osx-64 conda install numpy=1.23.5如果不带这个变量，conda 会按当前原生osx-arm64平台去解析，在一个已经全是 x86 包的环境里强行找 arm64 版本，结果要么是PackagesNotFoundError，要么是干脆告诉你"不适用于当前平台"。这两种报错都会让人心态崩溃。
关于性能，我实测下来 Rosetta 转译的损耗没有想象中高。在 M2 上跑一个三年多前的 TensorFlow 1.x 老训练脚本，性能损失大约在 10% 到 20% 左右，完全能接受。真正让你抓狂的从来不是转译速度，而是环境装不上。
3.3 解法三（想长期舒服的）：换 Miniforge 发行版
如果你长期需要在 Mac 上维护 Python 3.7 老环境，并且已经受够 Anaconda 默认源的种种限制，我会建议直接换掉发行版。
Anaconda 默认源的主频道是 defaults，它的问题我在第 1 节说过：官方已经停止维护 3.7，所以你会持续遇到这个报错。而Miniforge 从安装第一天起，默认 channel 就是 conda-forge，conda-forge 又恰好是保留 3.7 历史构建最完整的地方。省掉 channel 配置这一步，后面很多问题都不会出现。
现在的 Miniforge 新版本里已经集成了libmambasolver，老 conda 那个慢悠悠的 classic solver 被替换掉了。我在同样一台 M2 上创建环境，明显感觉 solving environment 阶段耗时从几十秒缩短到几秒。虽然这个加速不能帮你凭空找到不存在的包，但至少排查问题时反馈快得多。
如果你愿意，甚至可以把 Miniforge 以 x86_64 模式装到 M 系列 Mac 上，让整个 conda base 都跑在 Rosetta 下。这样创建环境时连CONDA_SUBPOLATFORM=osx-64都不用写，直接当作 Intel 机器用。缺点是所有环境都走 Rosetta，优势是非常省心，适合那些代码里本来就有一堆只兼容 x86 老库的人。
3.4 临时救急方案：不折腾 conda，用 pyenv 和 Docker 兜底
如果你的诉求只是"临时跑一段 Python 3.7 脚本"，不一定非得在 conda 上死磕。
pyenv 是个不错的备选。pyenv install 3.7.17装的是官方源码包，不走 conda 的 channel 体系，所以没有PackagesNotFoundError的问题。但它需要在本机编译，在较新的 macOS 上直接用默认参数编译 3.7 经常会遇到 OpenSSL 头文件缺失或编译参数不兼容的报错，需要针对 macOS SDK 做额外配置，折腾成本并不低。
Docker 是另一种更干净的兜底方案。直接把python:3.7镜像拉下来跑容器，前提是 Apple Silicon 拉到的镜像大概率是 x86 的，同样要走 Rosetta 转译。它适合处理无图形界面的脚本任务，但如果你依赖 GUI 程序、需要频繁挂载宿主机文件，容器方式就不是那么好用。
我的看法是：这两种方式可以作为应急手段，但如果你要长期维护一个项目，还是老老实实按解法二或解法三搞一套干净的可复现 conda 环境，一劳永逸。
4. 镜像源、代理和求解顺序：按国内网络环境的实战配置
4.1 镜像配置里最常见的翻车点
很多读者在 Mac 上遇到这个报错，会先去配国内镜像加速。这个方向本身没错，但我在实践里见过两种很容易翻车的配置。
第一种是只配了default_channels，没有配custom_channels。比如你用清华 TUNA 的 Anaconda 镜像，正常情况下它会帮你加速 defaults 的三个频道，但如果你在创建环境时不加-c conda-forge，solver 依然只会在已经停止提供 3.7 的官方源里求解，结果照样报PackagesNotFoundError。镜像加速解决的是"下载慢"，解决不了"仓库里没有这个版本"。
第二种是手动把conda-forge的 URL 直接拼进-c参数里，结果走的是官方地址，速度慢得离谱。国内网络环境下，conda-forge 官方源经常处于"能连但龟速"的状态，solver 甚至可能因为一直拉不下repodata.json而卡死在 metadata 阶段。
4.2 一份可以直接抄的 .condarc
我自己在 Mac 上用的.condarc长这样，用的是清华镜像：
channels: - defaults show_channel_urls: true default_channels: - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2 custom_channels: conda-forge: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud这里有一个容易混淆的点：custom_channels只负责把conda-forge这个频道名映射到镜像域名，它不影响频道在列表里的优先级。channels列表里的顺序才是 conda 实际求解时的优先级顺序。
如果你在创建环境时用了-c conda-forge，conda 会把 conda-forge 临时加进频道列表前端。配合上面的custom_channels映射，它实际访问的就是清华的 conda-forge 镜像，既保留了 conda-forge 的包完整性，又享受国内访问速度。
想检查当前配置是否生效，可以执行：
conda config --show channels conda config --show custom_channels conda config --show default_channels4.3 用 conda search 做一次"包存在性"体检
遇到PackagesNotFoundError，最忌讳的是不经过验证就反复换 channel。我建议先做一次"体检"，把问题一次性定位清楚。
在当前平台下搜索：
conda search python=3.7 -c conda-forge再看osx-64平台下是否真的有包：
CONDA_SUBPOLATFORM=osx-64 conda search python=3.7 -c conda-forge第一条命令如果返回空，而第二条命令有结果，那破案了：问题就是平台架构，走解法二。两条都有结果，说明你的 conda 或源配置有问题，走解法一就行。两条都空，那就得回过去检查网络代理和镜像源是否真的访问到了 conda-forge。
这个体检过程很值得养成习惯，因为PackagesNotFoundError的根因可能是一层叠一层的：源缺包、平台缺包、源没配好、代理没配好。先验证，再动手，比瞎试省太多时间。
4.4 代理设置也别忽略
在公司网络里还有一个容易误判的情况。如果你设置了全局代理，但代理挂了，conda 在拉取repodata时会报RepodataFetchError或直接卡在Collecting package metadata，那个报错和PackagesNotFoundError是两回事。
如果确实需要走代理，可以直接给 conda 配：
conda config --set proxy_servers.http http://127.0.0.1:7890 conda config --set proxy_servers.https http://127.0.0.1:7890注意不要把这个和PackagesNotFoundError混为一谈。PackagesNotFoundError是已经成功取得索引之后的结论，和代理是否畅通基本无关；如果你看到的是RepodataFetchError、ConnectionError、超时，才需要往网络代理方向排查。
5. 环境建好以后：3.7 老环境的兼容性收尾
5.1 pip 安装依赖时的版本墙
不要天真地以为环境创建成功就万事大吉了。Python 3.7 环境创建好后，你大概率会在pip install阶段遇到第二堵墙：主流包新版大多已经声明Requires-Python >=3.8。
我踩过的实际案例是：一个项目依赖里写着pandas>=1.5，pip 在 3.7 环境下直接报"pandas requires Python>=3.8"。这不是 pip 的问题，而是包本身已经放弃对 3.7 的支持。
如果你必须在 3.7 里装依赖，建议主动锁定那些"3.7 生命周期内最后一代"的版本。以我自己的经验，几个常见大包的锁定版本大概是这样：
numpy==1.23.5：这是最后支持 Python 3.7 的 1.x 版本线之一。pandas==1.5.3：最后一批支持 3.7 的 pandas 版本。scipy==1.10.1：1.10 系列仍兼容 3.8 和部分 3.7。matplotlib==3.5.3：3.6 之后基本不再兼容 3.7。requests、certifi这类纯 Python 包相对友好，但也尽量别追新。
不要在 3.7 环境里硬装新版本依赖，那样大概率会引出一堆二进制兼容问题，比如某个底层库没有 cp37 的 wheel，pip 被迫走源码编译，然后编译又报错，循环折腾。
5.2 系统库与编译链的坑
就算把 conda 环境搭好了，旧 Python 跑在新版 macOS 上依然有系统层面的兼容性问题。
我遇到过的典型情况是两个。
第一个是导入某些 C 扩展包时出现Symbol not found或dlopen错误。这是因为 conda 环境里的旧包链接的是旧版libffi、openssl等库，而 macOS 新系统带的动态库版本已经变了，两者对不上。我的处理方式是在 3.7 环境里显式装兼容的底层库，而不是裸依赖系统库：
CONDA_SUBPOLATFORM=osx-64 conda install -n py37 openssl=1.1.1 libffi=3.3第二个是本地pip install需要编译 C 扩展时，新版 clang 对旧代码的警告升级成了错误。这种情况可以试试显式指定 macOS SDK 路径：
export SDKROOT=$(xcrun --show-sdk-path) export CFLAGS="-stdlib=libc++ -mmacosx-version-min=10.9"坦白说，这些补丁式的做法不一定对每个人的项目都有效。如果编译一直失败，我更推荐考虑切换环境：到 Python 3.8 或 3.9 上跑那个项目，大概率兼容性更好，省下的时间远大于维护 3.7 的成本。
5.3 一个务实的项目划分建议
经历这一次之后，我给自己定了一个规则：3.7 环境只用于"运行老项目"，绝不用于开发新功能、绝不用于安装新依赖。
原因很简单：Python 3.7 生态已经停止增长，每装一个新的包，你都在和"版本墙"和"档案库缺失"作斗争。老项目可以像古董车一样被收藏、偶尔开出去转一圈，但你不能指望古董车天天上高速。
所以我的目录规划是这样的：
py37环境：只保留老项目本身的依赖，全部锁死版本，能跑就行；py310环境：日常开发主力，所有新项目都放这里；- 老项目如果未来需要大规模升级依赖，优先尝试迁到 Python 3.8 或 3.9，而不是往 3.7 里强行塞新组件。
这样一来，即便 conda 环境出问题，你也不会把新项目的进度搭进去。这是一个很务实的环境治理思路，和具体报错无关，但对长期维护多个项目的 Mac 用户来说，真的值得参考。
我在 M2 上最终跑通那个老项目的方案是：Miniforge 作为 conda 发行版，单独建了一个osx-64的 py37 环境，把 numpy、pandas、scipy 全部锁定在 3.7 最后支持的版本线上。运行起来很顺，唯一代价是每次装包都要记得带CONDA_SUBPOLATFORM=osx-64。如果你也卡在PackagesNotFoundError，先别急着怀疑网络或卸载 conda。花两分钟跑一下conda search做个体检，确认到底是"默认源没有 3.7"还是"arm64 平台没有 3.7"，再决定走哪条路线。我当初就是没分清这两个原因，白白多折腾了一下午。
