Expo Go 撞牆了怎麼辦？4 個訊號告訴你該轉 Development Build

你寫的第一個 Expo app 跑得很順——直到你想加 OAuth 登入、想接 Stripe 收款、想送一封推播通知。然後 Expo Go 就開始打嗝。我們最近在自己內部一個工具的早期 prototype 上撞到同一道牆，回頭看才發現：Expo Go 不是『簡化版的 React Native』，它是『示範用的容器』。 它的設計目標從來不是讓你寫到正式上線。

把這篇當成一份『何時該離開 Expo Go』的判斷指南。會看到 4 個明確訊號、Expo Go 的真實天花板、轉 Development Build 的完整 SOP，以及兩個常見的踩坑。我們會盡量用具體版本（Expo SDK 56、expo-dev-client 5.x）跟可重現的指令來寫，不丟空話。

如果你是想評估『要不要用 React Native』而不是『已經在寫了』，可以先看 我們之前寫過的框架選型完整指南（Flutter / RN / 原生 / No-Code）——本篇預設你已經選了 React Native + Expo。

先說結論：Expo Go 的角色已經被重新定義了

Expo 官方 2024 年起就明確把 Expo Go 定位成『學習與快速原型工具』，從 SDK 50 之後幾乎每個版本都在強化 Development Build 這條路。截至 SDK 56（2026 年 6 月釋出），官方文件第一段就寫得很直接：『Expo Go 不適合做 production-grade 專案』（出處：Expo Go vs Development Builds（Expo 官方部落格））。

這背後反映的是 SDK 設計取向，比語氣本身更值得注意。Expo Go 一次只能裝一個 SDK 版本，新版本一發佈，舊版的 Expo Go 就會從 App Store / Play Store 下架——你的 app 如果還在用舊 SDK，連 demo 都跑不起來。同樣的限制在 Development Build 上完全不存在，因為它是『你自己的 app』，版本由你掌控。

我們的判斷是：Expo Go 的最佳定位是『學習期 + 第一個 demo』，而不是任何超過 4 週的專案。 4 週這個數字不是隨便講——它大約是你開始需要『自訂 URL scheme 做 OAuth』、『接 Stripe 真實付款 SDK』、『遠端推播通知測試』這些 production 級需求的時間點。

4 個訊號告訴你 Expo Go 已經養不起你的 app

下面這四個訊號只要中一個，就該開始準備 Development Build。中兩個以上，你已經在浪費時間。

訊號 1：需要任何不在 expo-modules 清單裡的原生 module

Expo Go 把『可用的原生 module』寫死在它的 binary 裡。你打開 expo-modules 官方清單 會看到完整列表（camera、location、notifications、image picker 等）。不在清單上的 native module 全部裝不起來。 想用 react-native-mmkv（高效能 key-value 儲存）、react-native-skia（2D 繪圖）、react-native-vision-camera（相機 + 深度幀處理）？這三個都是社群熱門，都不在 Expo Go 支援清單裡。

硬要在 Expo Go 跑只會看到一行紅字錯誤： Cannot find native module 'XXX' 。沒有 workaround、沒有 polyfill、沒有 patch。唯一解法就是 Development Build。

訊號 2：要做 OAuth / 第三方登入

OAuth 流程的最後一哩路是『把使用者從瀏覽器導回 app』，這需要自訂 URL scheme（例如 myapp://auth/callback）。Expo Go 只接受預設的 exp:// scheme——你在 app.json 裡寫 "scheme": "myapp" 它也不認，因為這個 scheme 是在原生 binary 編譯時寫入 Info.plist / AndroidManifest 的，Expo Go 沒重新編譯，就讀不到。

結果是：Google / Apple / LINE / Facebook OAuth 全部在 Expo Go 上『callback 之後跳到瀏覽器停住』。你以為是程式 bug，其實是 Expo Go 根本拿不到 callback。這是新手最常被卡的點之一。

訊號 3：要送遠端推播通知

Expo Go 支援『本地通知』（app 內部排程的提醒），但遠端推播通知（Remote Push）要綁定你自己的 APNs / FCM 憑證——這也得編進原生 binary 才行。Expo Go 內建的憑證是 Expo 自己的，不能拿來測你 app 的真正推播流程。

如果你的 app 商業價值有一半建立在『通知用戶』（電商促銷、社群訊息、待辦提醒），這條訊號等於『現在就準備換』。

訊號 4：要做 Deep Link / Universal Link

客戶傳 https://yourapp.com/product/123 給朋友，希望點下去直接開 app 並導向產品頁——這是 Universal Link（iOS）/ App Link（Android）。要做到需要『app 跟網站雙向綁定』，網站要在 .well-known/apple-app-site-association 公佈你的 bundle ID，app 也要在 entitlements 裡列網域。

這兩邊都涉及 native 編譯時注入，Expo Go 不可能跑。

Expo Go 真實天花板對照表（截至 SDK 56）

下面這張表是我們整理官方文件加上自己踩過的坑做出來的，比官方文件的清單更實用：每一項都標『會在什麼情境下撞牆』，而不只是『能不能用』。

這張表的隱藏訊息是：『撞牆情境』那一欄涵蓋了 90% 真實上架 app 一定會遇到的需求。 你不會做 OAuth、不送推播、不用第三方 native module、不做 deep link 的 app——大概率還停留在 demo 階段，離『真實 app』有段距離。

Development Build 是什麼？跟 Expo Go 在底層哪裡不同

Development Build（開發建置）的官方定義是 『加裝了 expo-dev-client 的 Debug 版你自己的 app』。它跟 Expo Go 看似類似（都連到 Metro bundler 跑 JS），但兩件事根本不同：

• Binary 是你自己的：bundle ID、icon、splash、原生套件全部按你 app.json 編譯，不是 Expo 的容器。
• 可以離線、可以共享：build 完成的 .apk / .ipa 可以裝在沒裝 Expo Go 的測試員手機上，照樣連 dev server，照樣跑 JS hot reload。

簡單說：Development Build = 你 app 的 debug 版本 + 開發者工具（dev menu、network inspector、deployments switcher）。它不是另一個工具，它本身就是你的 app，只是還沒上 release 模式。

expo-dev-client 究竟在你的 app 裡做什麼

expo-dev-client 這個 npm package 在原生層注入一個 launcher UI——按下搖晃手機之後出現的開發者面板。它做三件事：

1. Server switcher：可以在多個 Metro bundler（本機 / 同事的電腦 / EAS Update preview branch）之間切換，方便團隊內部測試。
2. Network inspector：直接在手機上看 fetch / XHR 的 request body 跟 response，不用開 Chrome DevTools。
3. OTA preview：可以下載任何 EAS Update branch 的最新 JS bundle 來預覽，PM 測 staging 流程超方便。

第一次 Development Build 完整 SOP（30 分鐘版）

從零做一次 Development Build 大約 30 分鐘——前 5 分鐘設定，剩下 25 分鐘等 EAS Build 跑完。下面是我們驗證過可重現的指令流，假設你已經有一個現成的 Expo 專案。

Step 1：裝 expo-dev-client

# 在你的 Expo 專案根目錄
npx expo install expo-dev-client

用 npx expo install 而不是 npm install，原因是它會自動挑跟你 SDK 版本相容的版本。直接 npm install 可能會裝到不相容版本。

Step 2：登入 EAS 並 init

# 登入 Expo 帳號（沒帳號的話 expo.dev 註冊）
npx eas login

# 在專案 init EAS
npx eas init

init 完之後會在 app.json 加一個 eas.projectId，這個 ID 把你的本機專案綁到 EAS 雲端服務。

Step 3：產生 development build profile

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "android": { "buildType": "apk" },
      "ios": { "simulator": false }
    }
  }
}

把這段加到 eas.json 的 build 區塊裡。distribution: internal 表示這個 build 不會上 App Store / Play Store，只用來內部裝機。android.buildType: apk 是因為 internal Android build 直接給 apk 比 aab 更方便。

Step 4：跑 build

# Android 第一次建議跑這個（簡單、快、不用 Mac）
npx eas build --platform android --profile development

# iOS（需要 Apple Developer 帳號 + provisioning profile）
npx eas build --platform ios --profile development

Android 第一次大約 15-25 分鐘（EAS 雲端 build），iOS 大約 20-35 分鐘（含 credentials 設定的話再加 10 分鐘）。build 完成會收到一個下載 URL，掃 QR code 直接裝到實機。

Step 5：在新的 Dev Build 上跑 dev server

# 啟動 Metro dev server
npx expo start --dev-client

--dev-client 旗標關鍵，少了它會啟動 Expo Go 模式，新裝的 Dev Build 連不上。

從 Expo Go 切到 Development Build 的 3 個常見陷阱

教學流程都看起來簡單，但實際切的時候總有人卡住。下面三個是我們自己踩過、或在 Expo GitHub issues 跟 Stack Overflow 最常看到的問題。

陷阱 1：忘記加 --dev-client 旗標

啟動 Metro 用 npx expo start 預設會顯示 『按 a 開 Android』『按 i 開 iOS』 之類選單——它在等你連 Expo Go。你新裝好的 Dev Build 不認識這個 server，會一直停在 splash。

解法：永遠用 npx expo start --dev-client。可以把它寫進 package.json 的 scripts.start，這樣 npm start 就 default 走 dev-client 模式。

陷阱 2：app.json 改了沒重 build

app.json 裡的設定（icon、splash、bundle ID、permissions、URL scheme）改了之後要重新 build，不是改完就生效。原因是這些設定會在 build 時寫進 Info.plist / AndroidManifest——你的 Dev Build 已經是上次 build 出來的 binary，不會回頭讀新的 app.json。

判斷方式：問自己『這個變更會不會動到原生程式碼』。動到 → 重 build；只動 JS → hot reload 即可。如果還不確定，可以查 Expo 官方的 development workflow 文件 對照表。

陷阱 3：把 expo-dev-client 留在 production build 裡

expo-dev-client 是 dev tool，包進 production 會讓 binary 體積多 2-3 MB、也會在某些情境下觸發 Apple App Review 的 dev tool 警告。

解法：在 eas.json 把 production profile 設定成不包含 expo-dev-client。具體做法是另開一個 production profile 並把 developmentClient 設為 false 或乾脆不寫。EAS 會在 production build 自動排除 dev-client。

不是每個情況都該離開 Expo Go——三條判斷線

為了 fairness 也要說：Expo Go 仍然是某些情境的最佳工具，不該為了『升級』而升級。

關於『純 React Native CLI』還剩什麼角色

有人會問：『那我直接用 React Native CLI（非 Expo）不是更乾淨？』我們的判斷是：除非你在做的事情明確需要 fork React Native 核心、或要做 brownfield（把 RN 嵌進既有原生 app），不然 2026 年的 RN CLI 已經沒有比 Expo 更好的理由。 Expo 文件、Expo Modules API、EAS Build / Update / Submit、Expo Router——每一塊都比 RN CLI 同類工具成熟很多。

下面這張表整理 RN CLI / Expo + Dev Build / Expo + Expo Go 三條路徑各自的成本與適用情境，給你做決策參考——

官方甚至寫了 Use Expo（Expo 官方教學主頁） 直接建議『2026 年的新專案默認用 Expo + Development Build』。我們同意這個方向。如果你還在更前一步——想評估 App 開發大概要花多少錢，可以對照 APP 開發報價 8 萬 vs 80 萬 那篇看完整預算建議。

另外可以參考 Expo 官方 workflow 比較頁 看完整的工作流程說明。

我們怎麼看：跨平台手機開發的工具鏈正在『去 Mac 化』

如果把時間拉長三年看，從 React Native CLI → Expo Go → Development Build + EAS 這條路徑反映一件事：跨平台 app 開發正在脫離『你必須有一台 Mac 才能 build iOS』這個 20 年的硬性枷鎖。 EAS Build 是雲端 build，TestFlight 上架可以一行指令搞定，App Store Review 之前的所有步驟全部在瀏覽器或 CI 跑——這個方向會繼續走，而且贏家不會是『某個框架』，而是『把 build / deploy 流程做得最像 web』的那條工具鏈。

對中小企業老闆來說，這意味著兩件事：第一，不需要為了做 iOS app 而採購 Mac 或 Mac mini CI——EAS 一個月幾百元台幣就解決。第二，不要再把『手機 app 開發週期』想成 3 個月起跳——用 Expo + EAS Update，bug fix 可以當天上線（不用過 App Store Review），這比兩年前的 release cycle 快了一個量級。如果你的競品還在用 2024 年的工具鏈，光是工具差距就讓你產品 iteration 快 3-5 倍。

如果想把 Expo App 跑進你的業務流程

如果你看到這裡是因為手上有一個內部工具 / 客戶端 app 想做，但不確定『要自己學還是外包』，我們很樂意 聽你聊聊現況。我們會直接告訴你『這個值得自己學嗎、外包大概多少預算、用什麼方案最划算』——這個階段我們陪你一起想，後面真的要動手再談範圍跟費用。

想看更系統的『要不要做 App』、預算怎麼抓，可以對照 APP 開發報價 8 萬 vs 80 萬差在哪 跟 客製化 APP 框架選型完整指南 這兩篇——一篇講錢、一篇講技術選型，跟本篇的『Expo Go 是不是夠用』剛好拼成完整決策圖。