从源码编译PyMOL全攻略：依赖配置、CMake构建与错误排查

1. 为什么非要自己编译 PyMOL：开源版到底香在哪

在结构生物学、药物设计或者分子模拟这个圈子里，PyMOL 基本是人手一个的分子可视化工具。网上能搜到一大堆编译、安装教程，但是大部分都是讲 conda 直接装预编译包或者下载教育版图形界面安装包，真正涉及到从源码自己编译的教程，要么年份太久，要么用的是已经被官方弃用的老流程。这篇文章把我的实际操作过程、踩过的坑、排查思路完整整理出来，希望能帮你少走弯路。

需要先说清楚一件事：这里说的“开源版 PyMOL”，指的就是 GitHub 上 Schrodinger 公司维护的 pymol-open-source 仓库，它基于经典 PyMOL 内核，以开放源码的形式发布。它和官方教育版、商业版的差别，主要体现在少了一些授权闭源的插件和部分功能封装，但核心的分子渲染、结构比对、表面计算、PDB 文件处理、密度图可视化这些功能都是完整的。换句话说，把它编译出来，日常做科研、做教程、跑自动化脚本，完全够用。

如果你还在纠结“我直接下载一个编译好的二进制包不就行了”，那我先讲讲自编译到底香在哪：

• 可以跟上游代码保持同步，拿到最新版本的特性和 bug 修复；
• 可以自己控制 Python 版本、Qt 版本，避免预编译包和老系统环境冲突；
• 可以自定义安装路径，不污染系统环境，适合服务器上没有 sudo 权限的场景；
• 可以打开调试符号、启用内部 profiling，方便研究源码甚至二次开发；
• 很多功能插件（比如实验室内部脚本、自动化分析管线）对源码结构有依赖，编译版更容易扩展。

当然，编译也确实绕不过一些系统依赖、CMake 配置、Qt 构建这类问题。这篇文章的主体就是围绕这些展开。

1.1 开源版与预编译版、教育版的关键差异

这里有个特别容易踩迷糊的点：PyMOL 社区里经常出现“开源版”和“教育版”的说法，但它们不是同一个东西。

先看开源版。官方的开源仓库地址是https://github.com/schrodinger/pymol-open-source，采用兼容开源许可证（目前是 PyMOL 的开放式许可证，本质上属于 BSD 风格）。源码包里有setup.py、CMakeLists.txt、layer0到layer3的 C/C++ 核心代码，还有modules里的大量 Python 逻辑。只要你的环境满足依赖，就可以自行编译。

再来看教育版和商业版。这两个版本由 Schrodinger 以二进制安装包的形式分发，界面更友好，带有一些面向教学的整合功能，但源码不开放，也无法通过 pip 或者源码方式安装。很多新手在网上搜到“PyMOL 安装”，往往会下载到教育版.dmg或者.exe。那没问题，但我这篇文章针对的是源码编译，强调的是开源仓库自己的构建体系。

1.2 编译任务拆解：你真正要面对的三个环节

我第一次编译 PyMOL 时，最大的错觉是“只要跑 make 就结束了”。后来才理解，PyMOL 的构建链路远不止一次编译，它其实分成三个环节：

1. C/C++ 核心层编译：这一层负责分子渲染、几何计算、OpenGL 调用、表面生成这些性能敏感的部分，编译单元多，对编译器和 C++ 标准库版本敏感；
2. Python 绑定层生成：PyMOL 的 Python API（pymol模块）通过 SWIG 或者 C 扩展模块暴露给解释器，所以你要保证 Python 开发头文件、Python 解释器版本和编译出的动态库严格一致；
3. Qt/GUI 前端装配：开源版默认的图形界面基于 PyQt，启动pymol时会在 Python 环境下加载pymol包，再由 PyQt 驱动主窗口。如果 PyQt 版本、QScintilla 组件、OpenGL 驱动不健全，程序能 import 成功，但一打开窗口就崩溃或者闪退。

把这几个层次分开理解之后，再去排查编译错误就不会一头雾水了。很多报错看起来是在/bin/sh或者 cmake 阶段蹦出来的，根子却是其中一个环节没有满足前置条件。

1.3 我建议的编译路线图

结合我的使用经验，如果你不是非要深入 C++ 二次开发，最简单的路线是：

• 先安装基础编译工具和 Python 开发头文件；
• 再安装 Qt5、PyQt5、QScintilla 相关依赖；
• 接着克隆源码，用 CMake 做预编译配置；
• 然后执行编译和安装；
• 最后在命令行验证pymol能否启动、能否加载 PDB、能否画密度图（density map）。

接下来的内容会按这个路线逐步展开。这样编排也有一个好处：每一步出现问题时，你都知道该去检查哪一层，不会因为一个 Qt 报错就把整个源码重下载一遍。

2. 编译前的环境准备：依赖装不对，后面全是坑

这一章节极其重要。我见过太多案例，明明命令一行不差，最后卡在 OpenGL 或者 Python.h 找不到上，根本原因就是依赖没有按版本要求对齐。不要小看这一步，PyMOL 的 CMake 过程会同时探测图形、文本、XML、Python、Qt 五类开发库，任何一项缺失都会导致整个配置失败。

2.1 核心依赖到底有哪些

先列一个宏观清单，再讲每个依赖的作用。以下这些是编译开源版 PyMOL 时的常见依赖项：

• 编译工具链：gcc、g++、make
• 构建系统：cmake（某些老版本还用到 autotools，但不推荐）
• 版本控制：git（用来拉取源码和切换分支）
• Python 与开发包：python3、python3-dev
• OpenGL 相关：libgl1-mesa-dev、libglew-dev、freeglut3-dev
• 图像与文本：libpng-dev、libfreetype-dev
• XML 解析：libxml2-dev
• Qt 与 GUI 绑定：qtbase5-dev、pyqt5-dev、qscintilla2-qt5-dev

其中最容易漏掉的是libglew-dev和freeglut3-dev。PyMOL 的渲染循环用到 OpenGL，而 GLEW 负责在运行时动态加载 OpenGL 扩展指针；如果只装了 Mesa 的基础库，CMake 可能会通过，但编译或者运行时会出现 GL 函数找不到的情况。

qscintilla2-qt5-dev也容易漏。PyMOL 内嵌的“命令输入栏”（就是底部那个可以输入fetch 1abc、rotate命令的白框）在源码构建中会用到 QScintilla 这个基于 Qt 的代码编辑器控件。没有它，编译时不一定立刻报错，因为很多发行版会以可选组件的形式处理，但如果脚本里用了相关模块，运行阶段就会出问题。

2.2 我在 Ubuntu / Debian 系的做法

以 Ubuntu 22.04 LTS 为例，这一步基本是：

sudo apt update sudo apt install -y build-essential git cmake python3 python3-dev \ libgl1-mesa-dev libglew-dev freeglut3-dev \ libpng-dev libfreetype6-dev libxml2-dev \ qtbase5-dev pyqt5-dev qscintilla2-qt5-dev

装完之后，建议立刻检查 Python 版本，因为后续编译时PYTHON_EXECUTABLE要和系统 python 对齐：

python3 --version which python3

如果系统里有多个 Python（比如用 pyenv 或 conda 管理），一定要确保接下来使用的 cmake 命令里的PYTHON_EXECUTABLE指向同一个解释器，否则编译出的_pymol扩展模块会被 Python 解释器拒绝加载，报错类似undefined symbol: _Py_NoneStruct。这个话题，我会在第 4.3 节详细展开。

2.3 macOS 和其他平台的小补充

macOS 上我通常用 Homebrew 先装python@3.11、qt@5、glew、glu、freeglut、libxml2。在 Apple Silicon 上需要注意，OpenGL 框架虽然系统自带，但 CMake 找的路径和 x86_64 时代略有不同。建议在 CMake 阶段显式指定：

cmake .. -DOPENGL_INCLUDE_DIR=$(brew --prefix)/include

Windows 上的情况更复杂。开源版的官方构建流程主要以 Linux 和 macOS 为主，Windows 上要么用 WSL，要么用 MSYS2。我个人在 Windows 上的经验是：直接用 WSL2 装 Ubuntu 镜像，再在 WSL 里按 Linux 流程编译，比在原生 Windows 上折腾 Qt 工具链顺利得多。如果你非要在原生 Windows 编译，MSYS2 的环境里需要额外安装 mingw-w64 系列的 Qt、Python、GLEW 包，路径和库名都不一样，建议新手不要轻易尝试。另外，如果你是要在自己的笔记本电脑上跑结构生物学课程作业或者做毕业设计，WSL2 里编译已经完全够用，没必要为难自己。

2.4 依赖版本不匹配带来的连锁反应

这里分享一个真实案例。有一次我在 CentOS 7 上编译，系统自带 Python 2.7，而 PyMOL 源码较新版本已经要求 Python 3.6+。我图省事装了 python38，但没有把python3-config路径和 CMake 的PYTHON_EXECUTABLE对齐，结果编译出的模块一import pymol就段错误，排查了很久才发现是 Python ABI 不一致。

所以我的建议很明确：编译之前先确定 Python 版本，并且让 CMake、python3-dev、python3三者保持一致，最好全部来自同一个发行版仓库，避免混用源码编译的 Python 和系统自带 Python。这个原则不仅适用于 PyMOL，编译其他带 Python 绑定的 C++ 项目（比如 OpenCV、VTK、一些深度学习工具）时同样适用。

3. CMake 配置与源码编译全流程

依赖准备好之后，接下来进入正式流程。整个环节最核心的是 CMake 预编译配置，很多人一听到“cmake”就头大，其实只要理解了它的逻辑，它就是一台“生成 Makefile 的自动化翻译机”。你告诉它“我要装到哪个目录、用哪个 Python、有哪些依赖”，它根据这些信息生成对应的构建脚本，仅此而已。

3.1 获取源码：git clone 与分支选择

首先把源码拉到本地：

git clone https://github.com/schrodinger/pymol-open-source.git cd pymol-open-source

如果你对稳定发布更敏感，可以查看当前 tag：

git tag git checkout v2.5.0 # 或者你需要的版本

这里有两个细节值得注意。第一，不要直接克隆后切到 master 分支就跑生产环境的项目，master 是滚动开发分支，虽然也能编译，但接口和构建参数可能在变；第二，如果你后续要运行很多依赖于pymolPython API 的脚本，最好记录一下你的源码 commit 号，方便之后复现。比如我习惯把 commit 号写进实验记录的备注里：

git log -1 --format="%H"

这样半年后回去重新跑分析时，还能知道你当时用的是哪一版 PyMOL。这在科研项目的可复现性上价值巨大。

3.2 CMake 预编译配置写法

官方推荐的现代构建方式是通过 CMake 生成构建文件，然后make。以源码根目录为基准：

mkdir build cd build cmake .. \ -DCMAKE_INSTALL_PREFIX=$HOME/software/pymol \ -DPYTHON_EXECUTABLE=$(which python3) \ -DPYTHON_INCLUDE_DIR=$(python3 -c "import sysconfig; print(sysconfig.get_paths()['include'])") \ -DPYTHON_LIBRARY=$(python3 -c "import sysconfig; print(sysconfig.get_config_var('LIBDIR'))")

每个-D参数的意思我拆开讲：

• CMAKE_INSTALL_PREFIX：最终安装路径，我习惯装在用户目录下，不污染系统；
• PYTHON_EXECUTABLE：告诉 CMake 用哪个 Python 解释器来做绑定层和脚本处理；
• PYTHON_INCLUDE_DIR：Python.h 头文件的位置，如果系统里 python3-dev 装好了，一般可以通过 sysconfig 获取；
• PYTHON_LIBRARY：Python 动态库所在目录，某些环境需要再精确到libpython3.x.so的文件路径。

如果你不想在命令行里手动算这些路径，可以写一个简单的配置文件丢给 CMake。比如创建一个my_options.cmake，里面放：

set(CMAKE_INSTALL_PREFIX "$ENV{HOME}/software/pymol") set(PYTHON_EXECUTABLE "$ENV{HOME}/miniconda3/bin/python") set(PYTHON_INCLUDE_DIR "$ENV{HOME}/miniconda3/include/python3.11") set(PYTHON_LIBRARY "$ENV{HOME}/miniconda3/lib/libpython3.11.so")

然后在 build 目录里执行：

cmake .. -C my_options.cmake

-C的写法在社区讨论里经常被称为“cmake 预编译的写法”，本质就是在生成 Makefile 之前预先注入 CMake 缓存变量。这样做的好处是多人协作时，环境相关的配置可以统一管理，避免每次都在命令行拼一长串参数。我自己的习惯是：每台机器上都保留一个pymol_build_options.cmake文件，换机器后直接复用，省掉一大半排查时间。

CMake 配置成功后，终端会显示构建系统的配置摘要。如果你看到Build files have been written，说明这一步顺利通过。如果报错提示找不到 Qt、Python、OpenGL，优先回到第 2 章检查依赖。

3.3 编译、安装与验证

接下来是编译本身：

make -j$(nproc)

-j参数表示并行编译的线程数，nproc会返回当前 CPU 核数。第一次编译可能会比较久，尤其在你的 CPU 核数多的情况下，并行编译能明显缩短时间，但如果你内存较小，建议控制并行数，比如make -j4。这个建议不是空话，PyMOL 里某些 C++ 编译单元展开后极其吃内存，并行度开高了，轻则变慢，重则被系统 OOM Killer 直接杀掉。

编译完成后，安装：

make install

安装结束后，把bin目录加入PATH，同时确认 Python 模块可以被导入：

export PATH=$HOME/software/pymol/bin:$PATH python3 -c "import pymol; print(pymol.cmd.get_version())"

如果能够输出版本号，说明 C++ 内核、Python 绑定和 PyQt 前端三部分全部装配完成。为了以后每次打开终端都能直接使用pymol，可以把export PATH=...这行写进~/.bashrc或者~/.zshrc。

3.4 快速启动图形界面和命令行模式

图形界面模式直接运行：

pymol

如果服务器没有显示器，或者你只需要用 Python API 做批量处理，可以进入“无头模式”（headless mode）：

pymol -cq

-c表示命令行模式，-q表示减少启动日志。在这种模式下，你可以执行fetch 1cbs、load xxx.pdb、show surface这类命令，其中fetch依赖网络从 PDB 数据库拉取结构文件。无头模式是我在日常批量渲染中最常用的方式，后面第 5 章我会给出一套可直接用的示例命令。

4. 高频编译错误与排查实录

这一章是整篇文章里我最想写的部分。编译 PyMOL 很少有一遍过的，下面这些报错我全部在实际环境里遇到过，每个都对应一个真实场景。我尽量还原当时的报错现场和排查顺序，这样你遇到类似问题时可以按图索骥。

4.1 QScintilla 相关的错误

QScintilla 在 PyMOL 里负责命令行输入控件，它在编译阶段经常以“找不到头文件”或者“Python 绑定不全”的形式出现。

典型报错之一：

fatal error: Qsci/qsciglobal.h: No such file or directory

排查思路：先确认 qscintilla 开发包是否已经安装。在 Ubuntu 上：

dpkg -l | grep qscintilla

如果没有，安装：

sudo apt install libqscintilla2-qt5-dev

还有一类情况是 PyQt 的 QScintilla Python 包缺失。当你编译完 PyMOL，启动后输入框区域不显示或者程序报：

ModuleNotFoundError: No module named 'PyQt5.Qsci'

这是因为 PyQt5 的部分组件是通过单独包分发的。Ubuntu 上需要：

sudo apt install python3-pyqt5.qsci

如果你是在 conda 环境里编译，可以用：

conda install -c conda-forge pyqt qscintilla2

这里有一个容易引发连锁反应的细节：如果你手动下载 QScintilla 源码并编译安装，一定要保证它和 PyQt5 用的是同一个 Qt 版本，而且 Python 绑定所依赖的 SIP 版本也必须匹配。否则会出现“QScintilla 装上了，但 PyQt5 里 import 不到”的诡异情况。

4.2 OpenGL / GLU 头文件缺失

PyMOL 的核心渲染层调用 OpenGL 和 GLU，如果系统缺少开发头文件，编译时会出现类似：

fatal error: GL/glu.h: No such file or directory

或者 CMake 阶段直接找不到 OpenGL：

Could NOT find OpenGL (missing: OPENGL_glu_LIBRARY)

解决办法非常简单，但有些人会卡很久：

sudo apt install libglu1-mesa-dev freeglut3-dev

libglu1-mesa-dev提供 GLU 库，freeglut3-dev提供更多窗口工具函数。PyMOL 编译时并不是一定需要完整的 Qt 窗口才需要 OpenGL，它连离屏渲染（例如把分子渲染成图片而不弹窗）也需要 GL 环境。我记得在某个裸机服务器上第一次跑ray命令时，界面没弹出来，但任务管理器里能看到 CPU 在疯狂计算，最终 PNG 文件正常生成，靠的就是这套离屏 GL 链路。

4.3 Python 版本与开发头文件不一致

这个报错往往不是最直观的，它可能出现在编译中途，也可能出现在安装后启动瞬间。

编译时报错：

Python.h: No such file or directory

说明缺少python3-dev，安装后重试即可。但还有一种更有迷惑性的场景：编译完全通过，import pymol却报：

ImportError: /usr/local/lib/python3.10/dist-packages/pymol/_pymol.cpython-310-x86_64-linux-gnu.so: undefined symbol: _Py_NoneStruct

这个_Py_NoneStruct符号在不同 Python 版本中是不同的，尤其是 Python 3.10 之后改动频繁。遇到这种问题，先确认编译时的PYTHON_EXECUTABLE和运行时 import 用的 Python 是不是同一个解释器。如果服务器上有 conda 和系统 Python 并存，极容易出现“CMake 用的系统 Python，运行时用了 conda Python”的情况。

我的排查命令组合：

which python3 python3 -c "import sys; print(sys.executable)"

再对比 CMake 缓存里的PYTHON_EXECUTABLE：

grep PYTHON_EXECUTABLE build/CMakeCache.txt

两者必须一致。这个检查也适用于其他 C 扩展模块的编译问题，算是排查这类问题的一个通用套路。

4.4 Qt / QML 编译错误

有些较新版本的 PyMOL GUI 依赖 Qt Quick / QML 组件，编译时可能遇到：

Could not find a package configuration file provided by "Qt5Qml"

或者运行时报：

module "QtQuick" is not installed

这种情况下，除了qtbase5-dev，还要安装额外的 Qt 模块：

sudo apt install qtdeclarative5-dev qml-module-qtquick2

在更新版本或者使用 Qt6 时，还要注意 PyMOL 源码的 CMake 默认找的是什么版本。如果你系统里同时装了 Qt5 和 Qt6，CMake 可能优先找到 Qt6，但 PyMOL 的某个依赖组件还没适配 Qt6，就会出现“QML 编译错误”。这时可以在 CMake 阶段显式指定：

cmake .. -DQT_DIR=/usr/lib/x86_64-linux-gnu/cmake/Qt5

QML 报错还有一个隐蔽来源：某些经过精简的 Docker 镜像或者轻量系统根本没有安装 Qt Quick 模块，你只装了qtbase5-dev，觉得“Qt 应该全了”，但实际libqt5qml5、libqt5quick5都没有。所以出现问题后，先别急着改源码，直接检查这几个包是否存在会更高效。

4.5 其他零散报错与排查速查表

除了上面四个大项，我还整理过一个速查表，很多问题都能对号入座：

这里我特别想提醒一个容易忽略的点：如果你是在 Docker 容器或者轻量虚拟机上编译，内存轻易不要少于 2 GB。PyMOL 的 C++ 编译单元里很多模板展开非常吃内存，我遇到过 1 GB 内存的容器编译到一半直接被 OOM Killer 干掉的情况。业界有一个快速缓解办法：先关闭图形界面跑make -j2，同时给系统加上 swap 空间，能避免大部分 OOM。

4.6 为什么有些人用一键安装脚本也能成功

最近“鱼香ROS一键安装”这类脚本在机器人社区很火，有人问能不能用类似思路装 PyMOL。事实上，PyMOL 也有社区维护的一键安装方案，比如 Ubuntu 上直接sudo apt install pymol，或者 conda 上conda install -c conda-forge pymol-open-source。这些方案之所以省事，本质上是把第 2 章的依赖和第 3 章的编译步骤全部封装好了。

但如果你自己做科研项目，我仍然建议至少手动走一遍编译流程。原因很简单：你要用的插件、脚本、自动化管线很可能直接调用pymol模块的内部接口，只有理解了模块安装到了哪里、Python 路径是什么、Qt 版本是什么，才能定位那些“源代码没错却跑不起来”的诡异问题。另外，一键安装通常会把 PyMOL 放到系统全局路径，在集群环境里可能导致多个用户互相干扰，自编译到用户目录就没有这个烦恼。

5. 装好之后别急着关终端：功能验证与日常使用要点

编译安装成功的成就感确实很大，但我建议先别急着打开一个炫酷的分子就开始旋转，先花几分钟做几项基础验证，确保渲染、Python API、密度图处理这些核心功能都正常。这一章主要解决“装好了怎么确认没问题”以及“怎么在日常工作中用好它”这两件事。

5.1 快速功能自检

最简单的自检命令：

pymol -cq -d "fetch 1cbs; hide everything; show cartoon; raytrace 320,240"

这条命令的含义是：启动 PyMOL 命令行模式，从 PDB 数据库拉取 1cbs 结构，隐藏所有默认显示，只显示卡通模型，再以 320x240 的分辨率做一次光线追踪渲染。如果没有报错且目录下生成了 PNG 图片，说明底层 OpenGL 调用、PDB 网络下载、渲染管线都是正常的。

如果你想导出高质量图片，可以用png命令，比如：

pymol -cq -d "fetch 1cbs; hide everything; show cartoon; ray 1280,960; png my_render.png"

实测下来，ray之后直接png能保证输出的是光线追踪渲染结果，而不是屏幕截图的低清版本。如果你不调用ray，png默认保存的是当前 GL 窗口的离屏渲染，画质取决于屏幕分辨率，这对于论文配图来说往往不够。

5.2 PDB 文件与密度图处理的常用实操

编译版和预编译版在 PDB 处理上没有任何区别，但你既然亲手编译了自己的一份 PyMOL，理解这些底层逻辑会更有意义。

• 加载本地 PDB 文件：load example.pdb，PyMOL 会自动解析原子坐标、氨基酸序列、B-factor 等信息；
• 从 PDB 数据库在线拉取：fetch 1cbs，依赖网络，适合快速获取标准化结构；
• 查看晶体学信息和密度图：如果 PDB 文件包含CRYST1记录，PyMOL 会自动建立晶胞参数；用symmetry命令可以显示/隐藏对称分子；
• 加载密度图：常见的密度图格式包括 .ccp4 / .mrc / .map。命令是：

load density.ccp4, mymap isomesh mesh1, mymap, 1.0

这里的isomesh是等值面网格命令，第三个参数是等值面水平（sigma 倍数）。密度图在结构解析和模型修建中非常常用，尤其是你处理冷冻电镜数据或者晶体衍射数据时。如果你是第一次用，建议先从fetch 2MCP这种带实验数据的结构开始，边看密度图边调整等值面水平，体会一下不同 sigma 阈值下网格的显示差异。

• 查看和操作表面：show surface会生成分子表面，表面计算比较耗费 CPU，如果以后需要批量跑表面，建议用脚本而不是手动一个一个点。例如：

fetch 1cbs hide everything show surface set surface_color, lightblue ray 800, 600 png surface.png

5.3 后续扩展与维护建议

编译版 PyMOL 的优势之一是可以自行扩展 Python API。你可以在~/.pymolrc文件里写入自定义启动逻辑，比如设置默认背景色、加载自定义插件路径、预定义常用命令别名。一个简单的示例：

from pymol import cmd cmd.set('ray_opaque_background', 0) cmd.set('cartoon_transparency', 0.2)

另外，建议设置环境变量PYMOL_SCRIPTS和PYMOL_DATA：

export PYMOL_SCRIPTS=$HOME/pymol-scripts export PYMOL_DATA=$HOME/software/pymol/data

这样自定义脚本和数据文件都有统一位置，后续写自动化分析流程时不会乱。如果你的工作流里经常要处理批量结构文件，可以自己写一个 Python 脚本，循环加载目录下的所有 PDB，统一输出 PNG：

import glob import pymol from pymol import cmd pymol.finish_launching(['pymol', '-cq']) for pdb in glob.glob('*.pdb'): cmd.load(pdb) cmd.hide('everything') cmd.show('cartoon') cmd.png(pdb.replace('.pdb', '.png'), width=800, height=600, dpi=150, ray=1) cmd.delete('all')

这类脚本在生产环境里非常实用，比手动一个个打开 PyMOL 再截图高效得多。

5.4 升级源码版本时怎么做

如果你希望跟上新版本，升级也是一门学问。我的做法是：

cd pymol-open-source git pull rm -rf build mkdir build && cd build cmake .. make -j$(nproc) make install

这里重申一句：升级前最好备份~/.pymolrc和你的插件目录，否则新的安装包可能会覆盖部分默认配置。虽然概率不高，但我在 PyMOL 升级时遇到过自定义插件路径被重置的情况，备份一下总没坏处。如果你在用某个内部脚本且升级后发现 API 行为变化，可以通过git diff查看上游改动，定向适配，而不是把整个环境推倒重来。

关于 PyMOL 的编译安装，我能分享的核心经验就这些。实际编译过程中，每个人遇到的报错可能都不一样，但只要把握住“C++ 核心层、Python 绑定层、Qt/GUI 前端”这三条线索，把依赖和版本对齐，绝大多数问题都能迎刃而解。我个人在实际操作中的体会是：不要怕编译报错，每一个报错都在告诉你环境里缺了哪一块“拼图”，把它补上，整个构建链条就通了。最后再分享一个小技巧——把 CMake 的配置参数写成一个文件保存起来，下次重装或者换机器时，你会感谢自己当初多做了这一步。