JULIA 1.13 APPLE SILICON MAC 怎麼裝
2026 科研指南

症狀：Julia 可以啟動，但套件、artifact 或圖形工具在 Apple Silicon Mac 上出現載入錯誤。 最快解法：新專案優先用官方 juliaup 安裝 Julia 1.13，確認執行架構後建立獨立的 Project.toml 與 Manifest.toml；舊專案先保留原環境，再在隔離環境完成套件、結果與圖形任務回歸。

本文的判斷基準截至 2026 年 9 月 19 日；版本狀態與安裝資訊已按 Julia 官方下載頁及官方平台安裝說明核對。

這篇指南適合哪些科研使用者

如果你只有 Windows 或 Linux 裝置，卻需要驗證 Julia 專案在 macOS arm64 上的行為，本文適合你。準備把舊版 Julia 課題遷移到 Julia 1.13，並擔心套件或二進位依賴失效的科研人員，也可以用這套流程降低風險。

若你是高校技術支援人員，需要替課題組建立可重現的 Julia 環境，文中的取證順序、停止條件與遠端驗收方式，比單純列出下載按鈕更重要。

先固定版本與安裝來源，避免環境起點不一致

截至上述核對日期，Julia 1.13.0 已於 2026 年 9 月 9 日發布，Julia 官方將其列為目前穩定版本，並提供 macOS Apple Silicon 建置；官方典型安裝路徑是使用 juliaup。版本日期與穩定版狀態應以Julia 1.13 發布資訊與官方下載頁為準，不要把搜尋結果中的第三方舊封裝當成標準來源。

在終端機執行官方安裝方式後，先不要急著安裝科研套件：

curl -fsSL https://install.julialang.org | sh
juliaup status
julia --version
which -a julia

安裝基線至少要記錄三件事：

1. julia --version 是否確實回傳 julia version 1.13.0 或你核准的 1.13 補丁版本。
2. juliaup status 顯示的通道，以及目前預設通道是否是預期版本。
3. which -a julia 是否只把你預期的入口放在優先位置。

穩定版適合新課題與一般科研工作；LTS 適合依賴較保守、需要長時間維持的舊專案；固定版本的論文專案則應依原始環境回歸，不應因新版本已發布就直接覆蓋。開發預覽版只應用於明確的相容性測試。 <

選擇	適合情境	風險控制
Julia 1.13 穩定版	新專案、需要 Apple Silicon 原生驗證	先固定 Project 與 Manifest，再測試科研套件
LTS	舊課題、課題組希望降低升級頻率	依官方目前通道確認，不自行猜測版本狀態
舊版 Julia	論文結果、課程或既有流程依賴舊套件	保留原 Manifest，與新環境並行
開發預覽版	回報問題或測試尚未發布功能	不作為正式科研結果的唯一環境

注意：命令能啟動，只代表入口可用，不代表架構、套件 artifact、外部 C/Fortran 函式庫與圖形工作流程都已通過。

第一步：取證 Apple Silicon 與 Julia 的實際架構

Apple Silicon Mac 的硬體架構、Julia 執行檔架構與外部命令列依賴，必須分開核對。先執行：

uname -m
julia -e 'println(Sys.ARCH)'
julia -e 'println(Sys.BINDIR)'

在原生 Apple Silicon 條件下，Mac 通常應回傳 arm64；Julia 的 Sys.ARCH 也應與目標架構一致。若 uname -m 與 Sys.ARCH 不一致，先查 which -a julia、juliaup status 及 Shell 啟動檔，而不是立刻安裝 Rosetta。

常見症狀是：套件解析成功，但 artifact 下載後無法載入；C 或 Fortran 函式庫找不到；外部可執行檔存在，卻因架構不符而無法啟動。這些問題屬於不同層級，不能用重新執行 instantiate 反覆碰運氣。Julia 的 artifact 機制會依平台取得二進位內容，細節可參考官方 Artifacts 文件。

若某個舊依賴確實沒有 arm64 路線，才建立隔離的 Intel 相容環境，並把它標註為例外。不要讓 Rosetta 成為所有問題的預設解法，否則你最後驗證的可能不是課題組要部署的原生環境。

第二步：處理 Shell、PATH 與 juliaup 通道衝突

終端機找不到 julia、不同 Shell 啟動不同版本，或你切換通道後版本仍然不變，通常是入口衝突，不一定需要重裝。

低風險處理順序如下：

1. 保存 juliaup status、which -a julia 與 julia --version 的輸出。
2. 分別在你實際使用的 zsh、bash 或 IDE 終端機重複檢查。
3. 查看 Shell 啟動檔是否加入舊版 Julia 路徑。
4. 只移除重複的 PATH 入口，保留專案目錄與使用者設定。
5. 用 juliaup 設定預設通道，再重新開啟終端機驗證。

不要使用無差別刪除主目錄、整個清空套件環境或重新格式化硬碟的方式「修復」版本切換。這樣可能把可供回溯的套件快取與設定一併抹掉，卻沒有解決真正的路徑問題。

第三步：用錯誤首個有效位置排查科研套件

科研套件安裝失敗時，先記錄第一個有意義的錯誤，不要只截取最後一行。至少要區分以下層級：

• 註冊表無法存取：檢查 Julia 套件註冊表與權限。
• 套件伺服器無法連線：檢查校園防火牆、代理與 HTTPS。
• Git 下載失敗：確認課題組是否使用私有儲存庫或額外認證。
• artifact 取得失敗：檢查平台建置是否包含 arm64。
• 本機編譯失敗：查看 C、Fortran 編譯器及系統函式庫需求。

校園網路若攔截 HTTPS、要求代理或使用特殊憑證政策，應請學校網路管理員核對，不要以繞過安全策略的方式取得套件。Julia 的套件通訊與協定行為可對照[官方 Pkg 協定文件](https://pkgdocs.julialang.org/dev/protocol/)。

先選一個最小科研套件和一個可公開或已脫敏的課題資料集，完成：

using Pkg
Pkg.instantiate()
Pkg.status()

最小任務通過後，才進入完整專案。某個複雜套件是否支援 arm64，必須回到該套件的官方文件或版本公告核實，不能因為 Julia 本身可啟動就推定所有套件相容。

第四步：隔離 Project 與 Manifest，保住可重現性

全域環境可以用來短暫試用，但論文、課程與課題組專案都應有自己的 Project.toml 與 Manifest.toml。Project.toml 描述直接依賴，Manifest.toml 則鎖定解析後的具體依賴狀態；格式與用途可參照TOML 檔案說明。

在新目錄中建立 Julia 1.13 專用環境：

mkdir julia113-check
cd julia113-check
julia --project=. -e 'using Pkg; Pkg.instantiate()'

實際課題專案應先複製，而不是直接改動原目錄：

cp Project.toml Project.toml.backup
cp Manifest.toml Manifest.toml.backup
julia --project=. -e 'using Pkg; Pkg.instantiate()'

若舊專案需要與 Julia 1.13 並存，應使用不同版本專用的 Manifest，而不是讓一次解析覆蓋原本環境。Pkg 官方文件說明了不同 Julia 版本使用不同 Manifest 的做法。

<

驗收項目	僅算「可啟動」	可作為科研遷移依據
Julia 版本	REPL 能開啟	版本、通道、路徑均有紀錄
套件狀態	using 不報錯	Project.toml 與 Manifest.toml 已保存
資料處理	範例程式能執行	脫敏資料得到關鍵輸出
圖形工作	能開繪圖套件	圖形輸出、檔案寫入與畫面互動均通過
長任務	REPL 算術測試成功	斷線後可恢復，結果檔完整

用條件分支決定繼續、雙軌或回退

• 若 uname -m、Sys.ARCH、juliaup 通道與版本輸出一致，而且最小套件與代表性任務通過，則可以把 Julia 1.13 作為新專案環境。
• 若原論文結果尚未在新環境重現，則保留舊版 Julia 和舊 Manifest，採用雙軌，不要刪除原環境。
• 若只有單一套件的 arm64 artifact 或外部函式庫失敗，則先查該套件官方支援狀態；沒有原生路線時，回退到隔離的舊版或相容環境。
• 若失敗發生在校園代理、憑證或防火牆，則交由網路管理員處理；不要把網路問題誤判成 Julia 版本問題。
• 若圖形輸出、資料寫入或長任務仍未通過，則不能以「套件已安裝」作為放行條件，應繼續保留現有可用環境。

沒有可用 Mac 時，你可以先參考[遠端 Mac 科研環境的使用入口](https://macgpu.com/zh-Hant/index.html)，再用同一份驗收表測試 Julia 1.13。遠端主機的價值不是替你保證所有套件相容，而是提供一個可記錄、可重複的 Apple Silicon macOS 驗證條件。

常見遷移判斷與停止條件

穩定版與 LTS 的選擇，不應只看版本新舊：新課題優先考慮 Julia 1.13，舊論文則先以原環境重現為目標。是否需要 Rosetta，取決於特定舊依賴是否真的沒有 arm64 建置，而不是取決於你是否看到一個安裝錯誤。

遠端 Apple Silicon Mac 可以執行終端計算、VS Code 或 Notebook 工作區，以及需要圖形視窗的科研任務，但你仍要驗證連線中斷後的狀態、檔案寫入與長時間執行。Linux 專案可以共享程式碼與部分套件設定，卻不應未經測試就把 Linux 的 Manifest.toml 當成 macOS arm64 的完整保證。

如果關鍵輸出、隨機種子、資料處理結果與依賴狀態無法在新環境一致，這就是停止遷移的訊號。先保住可發表結果，再處理新版本相容性。

你目前以 Windows 或 Linux 為主的方案，通常少了原生 macOS arm64 驗證條件，遇到 Apple 專屬工具時還要處理虛擬機限制、架構差異與額外的檔案傳輸；直接購買 Mac 則會帶來一次性硬體成本、設備管理與閒置期間的成本。若你已整理好專案檔、依賴清單和代表性測試，短期租用 MACGPU 的遠端 Apple Silicon Mac，會更適合先完成 Julia 1.13 回歸，再決定長期購機、繼續租用，或維持 Linux 與 macOS 雙軌。若課題需要長期滿載計算、特殊實體介面或校內資料不得離開指定網段，則應先確認合規與硬體需求，遠端租用未必是最佳答案。

你可以從MACGPU 的繁體中文 Mac 方案開始核對連線方式與使用條件；先以驗收結果作決策，再安排長期環境，比直接重建整個科研工作流程更安全。