PyMOL 3.1 在 Apple Silicon Mac 怎麼裝：2026 科研指南

安裝前不要只問「哪個版本能啟動」，而應先列出課題是否需要官方支援、特定插件、Python 整合、固定腳本，以及能否用於正式學術研究和論文發表。這些條件會直接改變選擇，而不是單純由晶片名稱決定。

若研究成果需要可追溯的商業支援，教育用途的免費授權不能自動等同於學術研究或論文發表授權。PyMOL 的教育授權說明應在安裝前核對，尤其是學校課程、研究室內部研究和正式發表之間的使用邊界。

Apple Silicon Mac 安裝 PyMOL 應該選 DMG 還是 Homebrew？
若首要目標是讓研究人員快速完成結構檢視和論文出圖，DMG 通常是較低維護成本的起點；若課題要求原生 arm64、命令列整合或可重建的套件環境，Homebrew 更值得先做小規模驗證。兩者不要在同一個研究環境中交叉呼叫，也不要因為兩者都叫 PyMOL 就假定插件和 Python 行為完全一致。

官方 DMG 路線的最小操作可以控制在以下範圍：

1. 從PyMOL 官方下載頁取得 PyMOL 3.1 系列安裝檔，記錄下載日期、小版本和檔案雜湊；不要使用課題組聊天群組中無法追溯來源的安裝包。
2. 將應用程式拖入「應用程式」資料夾，首次啟動時依官方支援頁要求處理授權檔案與系統權限。
3. 在「關於本機」或終端機確認主機架構，再檢查 PyMOL 實際程序是否透過 Rosetta 2 執行。Apple 對Rosetta 翻譯環境的說明可用來判斷 x86_64 應用程式的執行條件。
4. 載入一個已脫敏的 PDB 或 mmCIF 結構，切換 cartoon、surface、sticks 等課題會使用的表示方式。
5. 執行最小腳本，完成選擇集、配色、視角和圖片匯出；不要只用「程式能開啟」作為通過標準。

官方支援頁對 macOS、Apple Silicon、Rosetta 2 和授權條件的表述會隨版本更新，應以官方支援說明為準。若啟動時要求安裝 Rosetta 2，先確認該 DMG 確實是 x86_64 路線，再按系統提示安裝；若研究團隊要求全程 arm64，則不應把 Rosetta 當成長期架構解決方案。

提醒： 教學授權可以解決課程練習的授權問題，卻不能直接推導出正式研究、論文圖片或課題組共用環境都獲得相同授權。交付前應保存授權類型、安裝來源和可用範圍。

Homebrew 適合願意自行維護依賴、希望保留命令列工作流，或要優先測試原生 arm64 的研究者。Homebrew 在 Apple Silicon 和 Intel Mac 使用的安裝前綴不同，相關架構差異可參考Homebrew FAQ；生物資訊相關公式則應以Homebrew Bio 公式庫當下狀態為準。

建議先取證，再安裝：

uname -m
which brew
brew --prefix
brew config

uname -m 顯示 arm64 只是主機架構，不等於目前終端機、Homebrew 或所有依賴都以 arm64 執行。若 brew --prefix 指向另一架構的前綴，應先停止安裝，另開同架構終端機或建立乾淨環境。接著在公式庫中確認 PyMOL 公式名稱、可用版本和依賴，再執行公式頁提供的安裝指令，不要照搬過期部落格命令。

安裝後，應使用相同終端機啟動 PyMOL，並分別測試：

• 讀取課題常用的 PDB、mmCIF 和自訂資料檔；
• 載入常用命令腳本，確認選擇語法和物件名稱沒有改變；
• 檢查字型、透明度、光照、抗鋸齒和渲染設定；
• 匯出課題指定的 PNG、TIFF 或其他格式，確認尺寸與色彩設定；
• 以命令列方式重跑同一腳本，保存終端機輸出和錯誤訊息。

PyMOL 開源專案的上游倉庫說明不等於商業授權版的支援、文件和整合工具清單。若開源版無法載入課題依賴插件，應回到授權版或把插件相關工作留在原有環境，不要為了追求「原生」而犧牲可交付性。

conda 路線的主要風險不是安裝指令本身，而是把 x86_64 套件、arm64 套件和既有科研環境的 Qt 依賴混在一起。PyMOL 官方conda 文件對 macOS ARM 的平台限制和可用套件狀態應在每次建立環境前重新核對；包狀態變化不能由過去成功安裝的截圖代替。

PyMOL conda 環境在 macOS arm64 上為甚麼可能裝不上？
常見原因包括目前套件沒有對應的 macOS arm64 建置、Qt 依賴需要另一種架構，或終端機在 Rosetta 下執行而 conda 卻從 arm64 頻道取包。解法不是反覆覆蓋安裝，而是先記錄架構和來源，再決定要建立兼容環境，或改採 Homebrew 開源路線。

可以按以下順序建立證據：

uname -m
conda info
conda config --show channels
python -c "import platform; print(platform.machine())"

在乾淨環境中依官方文件建立 PyMOL 環境，並記錄 Python、Qt、PyMOL 套件的版本與來源。若專案必須純 arm64，卻只能取得需要 Rosetta 的官方 bundle，應停止硬裝；可把可視化環境與數值分析環境拆開，或轉向已驗證的開源建置。這比在既有 conda 環境中混裝後再追查匯入錯誤更容易復現。

怎樣確認 PyMOL 腳本和插件遷移後結果一致？
不能只比較 PyMOL 是否開啟；應使用同一份結構檔案和腳本，逐項比對選擇集、物件數量、配色、視角、渲染設定及輸出圖片。插件若涉及外部命令、Python 模組或 Qt 介面，還要另存匯入日誌和套件清單，否則一個成功開啟的會話檔案不足以證明結果可重現。

沒有 Mac 時怎樣遠端執行 PyMOL 並製作論文圖片？
可先使用遠端 Apple Silicon Mac 完成環境驗證，但必須分開評估主機端渲染和操作端畫面傳輸：VNC 適合圖形介面操作，SSH 適合執行腳本、檢查檔案和批次匯出，兩者不應互相取代。遠端連線的互動感受、渲染耗時和連續運行穩定性只能根據實際測試，不能從本機 Mac 體驗外推。

遠端驗收可按以下步驟執行：

1. 準備已脫敏的代表性 PDB 或 mmCIF、最小腳本、插件清單和論文圖片規格。
2. 透過 VNC 登入，確認滑鼠旋轉、縮放、選取物件和切換表示方式均可完成。
3. 透過 SSH 上傳結構檔案，執行最小腳本並保存標準輸出、錯誤輸出及環境清單。
4. 在遠端主機完成渲染和圖片匯出，再下載原始圖片、腳本和日誌；不要只截取 VNC 畫面。
5. 中斷連線後重新登入，檢查程序狀態、工作目錄和未完成檔案，確認會話恢復策略。
6. 以課題真實任務重跑一次，記錄是否出現插件缺失、字型替代、視角改變或格式差異。

NUKCLOUD 提供的遠端 Mac 使用說明可用來先核對連線方式和權限邊界；若課題需要按週期使用，可再查看Mac 遠端租用方案。不過，任何租用環境都應先以課題結構檔案驗收，不能把「有 Apple Silicon」當成全部插件必然相容的承諾。

完成測試後，應把結果整理成一份可交接的環境清單，而不是只保存一個無法解釋依賴的 .pse 會話檔案。清單至少包括 PyMOL 版本、安裝路線、CPU 架構、macOS 版本、Python 與 Qt 來源、插件版本、結構檔案雜湊、腳本、輸出格式和已知限制。

• [ ] 用課題真實 PDB 或 mmCIF 完成載入驗收。
• [ ] 用同一份腳本比對選擇集、配色、視角與物件名稱。
• [ ] 分別測試 GUI 操作和 SSH 腳本執行。
• [ ] 保存套件來源、架構資訊及授權類型。
• [ ] 匯出論文圖片並核對解析度、字型、色彩與檔案格式。
• [ ] 在乾淨環境重新執行最小腳本，確認不依賴個人目錄。
• [ ] 為繼續使用、回退或雙軌保留設定明確停止條件。

若三條路線都能重現關鍵視圖和圖片，應選維護成本最低、授權最清楚的一條；若只有某條路線能正常載入插件，則應保留該路線，並把原生 arm64 作為獨立驗證環境，而不是強行合併。若遠端連線能完成腳本與出圖，但互動操作不適合長時間使用，可採「SSH 批次處理加 VNC 最後校圖」的雙軌方式。

對於實驗室現有的 Windows 或 Linux 方案，真正的限制通常是沒有 macOS 專屬驗收環境、跨架構依賴難以重建，以及研究人員要共用檔案時缺少一致的授權和版本記錄；臨時購買一台 Mac 又會帶來一次性硬體支出、設備管理和閒置成本。若只是完成一個課題週期的 PyMOL 驗收，NUKCLOUD 的遠端 Apple Silicon Mac 可讓研究團隊按需要保留合格路線，再依授權類型、連線方式和使用週期選擇環境，而不必先承諾所有插件都能相容。

完成結構檔案、腳本和論文圖片驗收後，可從NUKCLOUD 繁體中文服務入口核對可用環境；若課題需要物理介面、長期固定重負載，或必須由學校統一採購與管理，則自購 Mac 或保留既有實驗室設備可能更合適。