現在怎麼 debug 手機網頁：從裝一堆工具到幾乎不用裝

2020 到 2022 年間，在 Windows 上遠端 debug iPhone 網頁，常見流程是安裝 scoop、ios-webkit-debug-proxy、libimobiledevice、iTunes，再透過轉接器把 iOS 的 WebKit Debug 資訊接到 Chrome DevTools。工具與裝置必須按順序啟動，少一個環節就可能連不上。

那套現在不建議再用了——remotedebug-ios-webkit-adapter 已經多年未維護。這篇講現在實際會怎麼做。

Android：變得更簡單了

chrome://inspect 那套沒變，但現在多了無線偵錯，不用一直插著線。

無線偵錯（Android 11+）

1. 手機開啟「開發人員選項」→「無線偵錯」
2. 點「使用配對碼配對裝置」，會顯示一組配對碼與 IP:port
3. 電腦執行：

adb pair 192.168.1.100:37251
# 輸入手機上顯示的配對碼

adb connect 192.168.1.100:5555

4. 開 chrome://inspect/#devices，裝置就會出現

配對只需要做一次，之後同一個網路下 adb connect 就能連上。手機可以拿在手上測捲動、測橫置，不會被線扯住。

埠轉發：讓手機連到你的 localhost

• 這個功能很多人不知道，但幾乎每次都會用到。手機沒辦法直接開 localhost:3000，因為那是電腦的 localhost。
• chrome://inspect/#devices → Port forwarding → 加一條 3000 → localhost:3000。
• 之後手機的 Chrome 直接開 http://localhost:3000 就會連到你電腦上的開發伺服器。
• 而且它算在安全來源裡，所以 Service Worker、getUserMedia、Web Crypto 這些需要安全環境的 API 都能正常測試，不用另外弄憑證。

iOS：老實說，選項還是不多

核心限制沒變：Safari 的偵錯要靠 Safari，而 Safari 只有 macOS 有。

有 Mac 的話

這是唯一順暢的路：

1. iPhone：設定 → Apps → Safari → 進階 → 網頁檢閱器開啟
2. Mac 的 Safari：設定 → 進階 → 勾選「顯示網頁開發者功能」
3. USB 接上（或同一個 Apple ID 下用無線）
4. Mac 的 Safari → 開發 → 選你的 iPhone → 選要偵錯的分頁

功能跟桌機的 Web Inspector 一樣。

沒有 Mac 的話

老實講，沒有好答案。實務上的選擇是：

• ios-webkit-debug-proxy：這個專案本身還在維護，配合 RemoteDebug iOS WebKit Adapter 的老路子有時候還能通，但相容性看 iOS 版本，會踩到什麼很難預期。
• 雲端裝置服務：BrowserStack、LambdaTest 這類，提供真機加上 DevTools。要付費，但對「只是要確認某個 iOS 版本上會不會壞」很有效率。
• on-device console（見下一節）：不能設中斷點，但看 log 與網路請求夠用。

要接受的現實是：在 Windows 上完整偵錯 iOS Safari，至今沒有輕鬆的解法。

on-device console：塞一段程式就有 DevTools

不管什麼平台都能用的土法煉鋼，但意外好用。Eruda 或 vConsole 會在頁面上疊一個浮動按鈕，點開就是簡化版的 DevTools。

<script src="https://cdn.jsdelivr.net/npm/eruda"></script>
<script>eruda.init();</script>

看得到 Console、Network、Elements、localStorage。設不了中斷點，但「這支手機上到底噴什麼錯」這個問題它答得出來。

只在開發環境載入，不要進正式站：

if (import.meta.env.DEV) {
  const eruda = await import('eruda');
  eruda.default.init();
}

這招在 App 內建的 WebView（LINE、Facebook 內開的頁面）特別有價值——那些環境根本接不上任何遠端偵錯工具，但問題偏偏常常只在裡面發生。

先用模擬器排除掉一半的問題

真機偵錯很麻煩，所以先確認問題是不是真的跟裝置有關。

Chrome DevTools 的 Device Mode（Ctrl+Shift+M）可以模擬螢幕尺寸、觸控事件、prefers-reduced-motion 與網路節流。版面破掉、觸控目標太小這類問題，在這裡就看得出來，不用接手機。

Playwright 更適合放進自動化流程：

import { chromium, devices } from '@playwright/test';

const browser = await chromium.launch();
const context = await browser.newContext({
  ...devices['iPhone 15'],
});
const page = await context.newPage();
await page.goto('http://localhost:3000');
await page.screenshot({ path: 'mobile.png' });

devices 內建各種裝置的視窗大小、DPR、UA 與觸控設定。

但要講清楚它的界線：Playwright 的 devices['iPhone 15'] 跑的還是 Chromium，只是把外觀參數換掉。真正的 Safari bug（WebKit 的 CSS 差異、日期解析、100vh 行為）它抓不到。要測真的 WebKit 就得用 webkit 這個 browser type，那比較接近，但仍然不等於 iOS 上的 Safari。

模擬器負責排除版面問題，平台專屬的 bug 還是得上真機。

本機開發用 HTTPS

現在很多 API 只在安全來源下可用（Service Worker、getUserMedia、Web Bluetooth、剪貼簿）。手機要連你電腦的開發伺服器測這些功能時，http://192.168.1.x:3000 會被擋。

三個做法：

1. Chrome 的埠轉發（前面提過）——最省事，localhost 天生算安全來源。只適用 Android。
2. 本機憑證：用 mkcert 產生自簽憑證，把根憑證裝進手機。Vite 設定 server.https 帶入憑證即可。
3. 對外通道：cloudflared tunnel 或 ngrok，給你一個真的 HTTPS 網址。方便，但流量會經過第三方，測試含敏感資料的頁面前先想清楚。

對照表

參考資料

• Chrome DevTools：Remote debugging Android devices
• Android 無線偵錯
• Safari Web Inspector
• Eruda
• Playwright 裝置模擬
• mkcert