PyMOL 3.1 在 Apple Silicon Mac 怎么装：2026 科研指南

这篇指南面向需要在 Apple Silicon Mac 上使用 PyMOL 3.1 的研究生、结构生物学研究人员和高校技术支持人员。文章按授权版、Homebrew 开源版、conda 兼容环境和远程科研场景分流，并用结构加载、脚本执行、渲染导出与复现记录判断安装路线是否真正合格。

截至官方页面显示，PyMOL 3.1.8 于 2026 年 3 月 18 日更新。 这说明 3.1 系列仍在提供 macOS 安装包，但“能在 Apple Silicon 上运行”不等于授权版、Homebrew 和 conda 使用同一架构。对于 PyMOL 3.1 Apple Silicon Mac 安装，应先按科研用途选择路线，再处理 Rosetta 2、Python、Qt 和插件依赖。(PyMOL 官方下载页)

判断框：适合先根据许可证、脚本复现和架构要求分流；不适合把授权版、Homebrew 和 conda 包混进同一个环境，因为图形程序、Python、Qt 和插件可能分别属于不同架构。

这篇文章适合 3 类人：需要制作论文结构图、但实验室没有 Mac 的研究生和博士生；需要把 PyMOL 脚本、插件或 conda 环境迁移到 Apple Silicon 的研究人员；以及负责交付统一 macOS 科研环境的高校技术支持人员。

00先按科研任务选择 PyMOL 3.1 安装路线

PyMOL 3.1 Apple Silicon Mac 安装并不是单一教程，而是 3 条用途不同的路线。官方 DMG 适合优先解决“能否稳定使用、能否获得官方支持和许可证管理”；Homebrew 适合愿意维护依赖、希望验证原生 arm64 的用户；conda 则适合必须嵌入既有 Python 科研流程、但可以接受独立 x86_64 环境的用户。

开始安装前，建议先写下以下 4 个条件：

  • 是否用于课堂教学、学术研究，还是论文发表；
  • 是否必须使用官方支持、特定插件或商业许可证；
  • 是否要求主程序、Python 和依赖全部保持 arm64；
  • 是否需要把 PyMOL 接入自动化脚本、批量出图或既有 conda 流程。

如果课题组更重视稳定交付，优先考虑授权版 DMG；如果预算敏感且希望验证原生架构，再评估 Homebrew；如果已有脚本强依赖 conda，则应单独建立兼容环境，不要直接改造现有分析环境。

授权版 DMG：论文发表和课题组交付优先

如果课题需要正式论文出图、特定插件、稳定的 GUI 行为或技术支持，授权版通常是首选。官方支持页目前将 PyMOL 3.0 及以上的 macOS 支持范围写为 macOS 13.0 或更高版本，并包含 Apple Silicon，同时说明了 Rosetta 2 条件。(PyMOL 官方支持说明)

需要特别区分“免费教育用途”和“学术研究、论文发表”。官方教育许可说明，教育版面向课堂教学、作业和高质量图片制作，但不适用于学术研究或发表；论文和正式科研应核对 Academic PyMOL 许可，不能仅因为使用者是学生，就默认符合教育许可。(PyMOL 教育许可说明)

最小安装步骤如下：

  1. 从官方页面获取当前 3.1 系列 macOS DMG。
  2. 双击 DMG，把 PyMOL 拖入“应用程序”文件夹。
  3. 如果系统提示安装 Rosetta 2，按提示完成安装，不要为了强行原生运行而修改应用包。
  4. 首次启动时导入许可证文件，并记录许可证类型和适用范围。
  5. 在终端检查应用实际架构：
file /Applications/PyMOL.app/Contents/MacOS/PyMOL
uname -m

如果结果显示应用依赖 x86_64，就应在环境清单中标注“Rosetta 路线”，不要把它误记为纯 arm64 环境。Apple 的技术文档说明，Rosetta 用于在 Apple Silicon 上运行包含 x86_64 指令的 Mac 应用；同一个进程不能混合执行 arm64 和 x86_64 代码。(Apple Silicon 与 Rosetta 说明)

这里的停止条件是：如果课题组要求所有 Python 插件、外部库和主程序均为 arm64，那么授权版 DMG 不能直接视为合格答案。此时应转向开源构建，或把可视化环境与分析环境拆开，分别维护和验收。

01第二步：用 Homebrew 验证原生 arm64 开源路线

Homebrew 路线更适合预算敏感、需要本地脚本调用，或者希望让 PyMOL 与 Apple Silicon 科研工具保持同一架构的研究者。它的代价是：开源构建与授权版在许可证、技术支持、文档、插件和预置集成工具方面不能默认等同。

Homebrew 在 Apple Silicon 上的默认前缀是 /opt/homebrew，而 Rosetta 2 环境通常使用 /usr/local。因此，安装前应先确认当前终端和 Homebrew 本身没有混架构。(Homebrew 架构与安装前缀说明)

uname -m
which brew
brew --prefix
arch

如果目标是原生 arm64，通常应看到：

arm64
/opt/homebrew

随后核对当前科学软件仓库中的 PyMOL 公式状态。相关仓库采用 brewsci/bio/FORMULA 的安装形式，但公式会随依赖、macOS 版本和维护状态变化，因此不要直接复制旧文章中的固定版本号。(Homebrew 生物信息软件公式仓库)

brew update
brew tap brewsci/bio
brew info brewsci/bio/pymol
brew install brewsci/bio/pymol

如果 brew info 找不到公式，或安装过程开始编译大量不兼容依赖，应停止继续堆叠命令，先查看公式仓库的当前状态，再决定改用源码构建或授权版 DMG。Homebrew 官方也提示，非默认前缀可能无法使用预编译 bottle，转为源码编译后，失败概率和维护成本都会上升。

安装完成后，不能只看窗口是否出现。应依次验收：

  • 读取一个脱敏的 PDB 文件和一个课题常用的 mmCIF 文件；
  • 执行 load、hide、show、color、select 等基础命令；
  • 运行课题已有脚本，确认 Python 调用没有导入错误；
  • 检查字体、标签、透明度、ray tracing 和 PNG 或 TIFF 导出；
  • 对比同一输入文件在旧环境中的选择集、视角、配色和图片尺寸。

上游开源仓库将 PyMOL 定义为商业产品的开源基础，并以 BSD 风格许可发布代码；这并不意味着开源构建自动获得商业版支持和全部集成组件。(PyMOL 开源仓库说明)

02第三步：需要 conda 时，主动隔离 x86_64 环境

PyMOL conda 环境在 macOS arm64 上装不上，常见原因不是某一个 Python 包单独损坏，而是平台标签已经发生冲突。PyMOL 官方 conda 文档目前明确写明，conda-forge 不支持 Native Mac ARM，因此 Apple Silicon 用户需要先创建 osx-64 环境，再安装 pymol-bundle。(PyMOL 官方 conda 文档)

推荐把它当成专门的可视化环境，而不是现有生物信息学环境的附加包：

conda create --platform osx-64 --name pymol31-x86 python=3.10
conda activate pymol31-x86
conda install -c conda-forge -c schrodinger pymol-bundle
pip install PyQt5
pymol

上面的 Python 版本只是隔离示例，最终应以官方当前包元数据和环境解析结果为准。真正重要的是 --platform osx-64，以及不要把这个环境里的 Python、Qt 和 PyMOL 包复制到原有 arm64 环境。

可用以下命令取证：

conda info
python -c "import platform; print(platform.machine())"
python -c "import sys; print(sys.executable)"
conda list | grep -E "pymol|python|qt|pyqt"

如果终端中的 Python 显示 x86_64，而外部脚本由 /opt/homebrew/bin/python3 的 arm64 Python 调用，就属于两个不同执行环境。此时不要通过设置 PATH 反复覆盖，应该明确选择：脚本也放入 x86_64 conda 环境，或将 PyMOL 只作为独立 GUI 程序使用。

如果项目的硬性要求是“纯 arm64”，而官方 conda 路线仍要求 osx-64，就不要把时间耗在强行安装上。回退到 Homebrew 开源构建，或者将分析、插件和可视化拆成两个明确环境，通常比混装后再排查更可控。

最小通过标准包括：pymol 能启动，命令行脚本能够调用 PyMOL，Qt 界面正常，结构文件可读取，图片可以按课题要求导出。若只有 GUI 能启动、脚本无法调用，或者插件依赖被装进了另一个架构环境，这条路线就不能交付。

03没有本地 Mac 时，先验收远程科研链路

实验室没有 Mac，并不意味着必须立即购买一台设备。对于只在某个课题阶段制作结构图、验证脚本或检查 macOS 兼容性的用户，可以先通过远程 Apple Silicon Mac 完成一次完整任务验收，再判断是否值得长期采购。

远程使用时必须把两件事分开：

  • 主机端负责 PyMOL 的程序执行、结构解析、脚本运行和图像渲染；
  • 操作端只负责通过 VNC 或网页控制台接收画面、发送鼠标键盘操作，或通过 SSH 执行命令。

因此，远程画面是否流畅，不能直接推断主机渲染速度；本地窗口拖动是否顺滑，也不能推断断线重连和大图导出是否稳定。交互体验、渲染耗时和连续运行稳定性，必须以实际远程主机测试为准，不能把本地 Mac 的体验直接外推。

远程验收可按以下顺序执行：

  1. 准备脱敏的 PDB 或 mmCIF 文件、课题脚本、插件清单和一份预期输出图片。
  2. 通过网页控制台或 VNC 登录远程 Mac，确认图形界面可以打开 PyMOL。
  3. 通过 SSH 上传结构文件和脚本，记录远程主机上的绝对路径。
  4. 在 GUI 中完成结构读取、表示方式切换、选择集创建、配色和视角调整。
  5. 通过 SSH 执行同一份脚本，比较 GUI 操作结果与脚本结果。
  6. 导出 PNG、TIFF 或课题要求的其它格式，下载到本地后检查分辨率、字体、透明背景和裁切。
  7. 主动断开 VNC，再重新连接，确认会话、文件和已保存结果没有丢失。
  8. 保存环境清单、脚本、输入文件校验值和最终图片，不要只保存一个无法解释依赖的 .pse 文件。

如果需要先了解 NUKCLOUD 的远程 Mac 使用方式，可从 NUKCLOUD 中文首页 查看整体服务入口；需要临时为一个课题周期准备环境时，再根据连接方式和使用周期查看 Mac 远程租赁方案。

04用真实课题任务决定继续、回退还是双轨保留

PyMOL 3.1 Apple Silicon Mac 安装是否成功，最终不应由“程序能否打开”决定，而应由课题交付物决定。建议从实际论文或实验任务中选一份代表性结构，最好同时包含结构文件、脚本、插件和最终出图要求。

建议记录的复现信息

  • PyMOL 版本和安装来源；
  • macOS 版本与主机芯片架构；
  • PyMOL 主程序是 arm64、x86_64 还是通用二进制；
  • Python、Qt、PyQt 和 conda 平台；
  • 插件名称、版本和安装目录；
  • 输入 PDB 或 mmCIF 文件的校验值；
  • 脚本文件、命令参数和导出格式；
  • 选择集、配色、视角、标签和渲染设置；
  • 输出图片与旧环境结果的差异。

PyMOL 官方教程把加载 PDB 文件、调整三维视图和使用脚本列为基本工作路径；对于论文图，视角和脚本中的 set_view 等状态应写入可复现文件，而不是依赖手动拖动后的临时窗口状态。(PyMOL 官方结构可视化教程)

通过标准与停止条件

  • 继续使用授权版 DMG：许可证合规、插件可用、脚本结果一致，且课题组更重视官方支持。
  • 继续使用 Homebrew 开源版：主程序与依赖保持 arm64，结构读取、脚本、字体和导图全部通过，且课题组能接受自行维护。
  • 保留 conda 双轨：项目必须依赖现有 x86_64 Python 或插件，但可视化环境与分析环境边界清晰。
  • 回退：关键插件无法加载、脚本输出不一致、图片渲染异常，或团队成员无法复现同一结果。
  • 双轨保留：论文交付依赖授权版，而开发和自动化测试依赖原生开源版，两者分别记录环境，不互相覆盖。

可以用下面的清单完成最终验收：

  • [ ] 已确认使用场景是教学、学术研究、论文发表还是脚本开发。
  • [ ] 已记录 PyMOL 来源、版本、许可证状态和 macOS 版本。
  • [ ] 已执行 uname -m、file 和 Python 架构检查。
  • [ ] 已避免在同一 conda 或 Homebrew 环境混装 arm64 与 x86_64 依赖。
  • [ ] 已读取课题真实使用的 PDB 或 mmCIF 文件。
  • [ ] 已运行至少一份真实脚本并保存终端输出。
  • [ ] 已验证插件、字体、选择集、配色、视角和渲染设置。
  • [ ] 已导出论文图片，并在本地打开检查格式和清晰度。
  • [ ] 已测试远程连接、SSH 文件传输和会话恢复。
  • [ ] 已保存环境清单与最小复现脚本，而不是只保存会话文件。

05常见问题：安装和迁移时最容易误判的地方

M 系列 Mac 使用授权版 PyMOL 时应怎样处理 Rosetta 2？

官方支持页目前将 Apple Silicon 与 Rosetta 2 一起列入 PyMOL 3.0 及以上的 macOS 支持说明。授权版 DMG 应先按这一条件准备；开源 arm64 构建则必须单独检查实际二进制和依赖，不能因为芯片是 M 系列就自动判定为原生运行。

DMG 和 Homebrew 应该怎么选？

需要许可证、官方支持和较少维护工作时，选 DMG；需要原生 arm64、脚本集成和较低软件成本，并且能承担依赖维护时，再选 Homebrew。两者可以分别安装用于比较，但不要让不同来源的 Python、Qt、插件和启动脚本相互引用。

为什么 conda 路线会出现架构冲突？

因为官方 conda 文档当前要求 Apple Silicon 用户创建 osx-64 环境。若已有环境是 arm64，却直接安装依赖 x86_64 的 PyMOL 包，解析器可能无法解决，或安装成功后在 Qt、插件和 Python 调用阶段失败。

没有 Mac 能否远程完成论文出图？

可以，但必须验证完整链路，而不是只看远程窗口能否打开。结构文件上传、脚本执行、图形交互、渲染导出、图片下载和断线恢复都应使用脱敏真实样例测试；其中任何一项不稳定，都不应直接承诺可用于论文交付。

怎样判断迁移后的结果真的一致？

至少比较输入文件、脚本、PyMOL 版本、架构、插件、选择集、视角、配色、字体、渲染参数和最终图片。只比较 .pse 文件并不充分，因为会话文件可能隐藏外部插件、路径和运行时依赖。

06最后的方案判断：先验收，再决定是否长期保留 Mac 环境

如果现有方案只能依赖实验室的 Windows 或 Linux 机器，常见问题是缺少 macOS 专属运行环境、无法验证 Apple Silicon 架构差异，以及远程 HPC 或共享服务器通常不提供稳定的图形会话。临时借用个人 Mac 还会遇到许可证归属、插件版本不一致、文件传输和设备不可用等问题。

完成结构文件、脚本和论文图片导出测试后，如果实验室仍无法提供 macOS 环境，按课题周期使用 NUKCLOUD 的远程 Apple Silicon Mac，会比为了单次出图立即购买整机更容易控制成本和环境变量。需要长期高负载渲染、物理接口或完全离线工作时，自购 Mac 仍可能更合适；如果只是临时验证 PyMOL 3.1、迁移脚本或完成一轮论文出图，则可以先根据所需授权、连接方式和使用周期查看 NUKCLOUD 可用 Mac 环境，再保留已经通过验收的路线。