Playwright WebKit vs Safari 27：2026 遠端測試怎麼選

Playwright 的 WebKit 是由 Playwright 維護、供自動化測試使用的 WebKit 瀏覽器版本；它不是直接啟動品牌版 Safari。Playwright 官方亦明確提醒，其瀏覽器所使用的程式碼可能早於 Safari 正式整合，因此「同一個渲染引擎」不能推導出「瀏覽器行為完全相同」。可先查閱 Playwright 對瀏覽器版本與差異的說明，再決定測試結論的可信範圍。

這個差異包含四個層面：

1. 瀏覽器外殼不同：Safari 的分頁、視窗、下載、權限提示與設定狀態，不是 Playwright WebKit 的完整映射。
2. 系統整合不同：字型、媒體解碼、鑰匙圈、攝影機與麥克風權限，都可能受到 macOS 環境影響。
3. 版本時間點不同：WebKit 的測試建置與 Safari 產品版本並非必然同步，某項修正可能先出現在其中一邊。
4. 自動化介面不同：Playwright 透過自身 API 管理瀏覽器；Safari 品牌版則依賴 WebDriver 與 safaridriver，兩者不是同一套控制層。

因此，Linux 上的 Playwright WebKit 可以發現許多引擎層與頁面層問題，但不能單獨關閉所有 Safari 相容性風險。

Linux 上的 WebKit 測試能發現什麼

Playwright 適合放入 Linux、Windows 或 macOS 上的通用 CI，尤其是以下工作：

• DOM 結構、CSS 版面、基本響應式行為與 JavaScript 互動。
• 表單驗證、路由切換、API 錯誤處理與一般登入流程。
• 頁面載入後的元素狀態、請求攔截與基本下載流程。
• 大量且穩定的回歸案例，讓每次提交或合併請求都能快速取得結果。

這些結果對尋找標準 WebKit 渲染差異很有價值，但應在報告中標示為「Playwright WebKit 結果」，而不是「Safari 已通過」。

Safari 27 自動化為何需要 Mac

需要驗證品牌版 Safari 時，測試必須安排 macOS、Safari 與 safaridriver。Apple 的 macOS WebDriver 啟用文件說明了相關設定入口；Safari WebDriver 測試文件則可用來核對驅動模型與操作方式。

以下情況應增加真實遠端 Mac：

• 媒體播放、音訊輸出、攝影機、麥克風與串流格式。
• 系統字型、文字輸入、拖放、檔案選擇與下載權限。
• 鑰匙圈、通知、地理位置及其他需要作業系統授權的流程。
• Safari 擴充功能、Web Inspector 互動，以及只在 Safari 外殼中出現的行為。
• 支付、登入、帳戶設定等發布前不能只依靠單一瀏覽器引擎判定的關鍵路徑。

長期沒有 Mac 的團隊，可先使用 NUKCLOUD 的遠端 Mac 環境做短週期驗證；但仍須先確認測試節點是否能穩定保留圖形工作階段、Safari 設定與自動化授權。

現有 Playwright 腳本不能不經修改就直接控制品牌版 Safari。Playwright 的定位是跨瀏覽器自動化框架，而 Safari WebDriver 是另一種驅動介面；即使測試案例名稱相同，啟動、能力宣告、等待策略與診斷資料仍可能不同。

可按以下步驟接入真實 Safari：

1. 整理關鍵路徑：先選出登入、支付、媒體、檔案上傳、權限授權與發布前煙霧測試，不要一開始搬移整個測試套件。
2. 建立能力對照表：逐項記錄選擇器、等待條件、彈出視窗、分頁切換、上傳下載與視窗管理在兩套驅動中的實作方式。
3. 準備專用 Mac 帳戶：使用獨立測試帳戶與測試資料，限制不必要的鑰匙圈、檔案與系統權限，避免測試污染開發者環境。
4. 啟用並驗證 safaridriver：按照 Apple 的設定文件開啟自動化，先執行瀏覽器啟動、導覽、元素定位與結束流程，再接入完整案例。
5. 固定測試前置狀態：清楚定義 Safari 設定、Cookie、權限提示、下載目錄、字型與測試帳戶的初始狀態。
6. 把結果回傳 CI：保存測試名稱、Safari 版本、macOS 版本、提交識別碼、失敗截圖與 WebDriver 日誌；命令中的主機位址、帳戶和倉庫路徑使用 CI 秘密或占位符。
7. 設定失敗處理：首次失敗先保留現場並重試一次；若節點重啟或圖形工作階段消失，應標記為環境失敗，而不是直接判定產品失敗。

Safari 27 的新 WebDriver 能力只能依照 Apple Safari 27 Release Notes逐項核對。該文件截至 2026 年 9 月 1 日仍將 Safari 27 標示為 Beta，因此 Beta 中記載的變化不能寫成穩定版承諾，也不能據此推斷完整相容範圍。

當 WebKit 通過、Safari 失敗時，第一步不是立即修改產品，而是把兩個環境的證據放在同一份缺陷記錄中。Playwright 可透過 Trace Viewer 與除錯工具保存步驟、截圖、影片與網路活動；Safari 則應搭配 Safari Web Inspector觀察頁面、主控台與資源載入狀態。

每次失敗至少保存：

• 測試提交識別碼、測試名稱與完整操作步驟。
• Playwright WebKit 或 Safari 的瀏覽器版本，以及 macOS 版本。
• 頁面截圖、主控台訊息、網路請求、影片或 Trace。
• 權限提示是否出現、測試帳戶狀態及媒體裝置狀態。
• 能在單一頁面重現的最小測試案例。

若只有 Safari 失敗，可能是品牌版行為、系統整合或 WebDriver 操作差異；若兩邊都失敗，才更可能是網站本身的 WebKit 或通用程式問題。一次通過只能說明該次環境與資料通過，不能作為所有 Safari 版本、裝置或使用者設定均相容的證明。

測試分層的重點不是把所有案例複製到兩邊，而是按照失敗成本安排觸發時機：

• 每次提交：Playwright WebKit 執行穩定的基本回歸，阻止明顯版面、互動和路由問題進入合併請求。
• 合併請求：加入少量 Safari 關鍵路徑，特別是最近修改過的權限、媒體或登入流程。
• 每日建置：在遠端 Mac 執行較完整的 Safari 套件，並保留診斷檔案和節點健康狀態。
• 發布候選版本：把真實 Safari 門禁放在發布前，要求關鍵案例完成且失敗能被分類、重現或明確豁免。

方案比較表

風險路由表

接入前驗收表

若團隊需要更完整的節點規格與權限檢查，可參考 NUKCLOUD 遠端 Mac 使用說明；若要先做一次發布關鍵路徑的短週期試跑，再依實際失敗率決定是否長期納入 CI，可從 NUKCLOUD 遠端 Mac 方案評估合適的測試安排。

對多數前端團隊而言，單用 Linux 上的 Playwright WebKit，缺點是無法覆蓋 Safari 外殼、macOS 權限與媒體整合；只用真實 Safari，則會犧牲大量回歸案例的執行彈性，並增加節點、授權與圖形工作階段維護負擔。把兩者各自放在適合的風險層級，通常比強行二選一更容易維持穩定的發布流程。若需要臨時算力或隔離的測試環境，先在 NUKCLOUD 的遠端 Mac 上驗證一條發布關鍵路徑，確認 Safari 啟動、自動化授權、證據採集與重啟恢復都能重現，再決定是否納入長期 CI，會比直接遷移整套測試更可控。