Gmail 專屬郵件客戶端是什麼？為何新工具不再支援其他信箱

嗯...最近看到一個現象。一些新的 Email App，很有設計感，看起來很酷。像 Mimestream，還有 Notion 也出了 Notion Mail。

但有個怪事。它們都只支援 Gmail。

這就怪了。Notion 這麼大的公司，錢應該不是問題吧？為什麼只做 Google 的生意？市面上明明還有其他 email 啊。

我自己也在做一個 email app，所以...大概猜得到答案。

TL;DR

一句話：因為一個叫做 IMAP 的古老協定太折磨人了，用 Gmail 自己的 API 最省事。

方便的捷徑 vs. 崎嶇的老路

這件事，其實就是一個開發路線的選擇題。

一條是 Google 鋪好的高速公路，叫 Gmail API。專為現代網路設計，用的是大家熟悉的 REST、JSON。對開發者來說，很直覺，開發速度快。就像用現成的組合家具，說明書清清楚楚。

另一條路，就是 IMAP。這是給「所有」email 用的通用協定。但...它是 2003 年的產物。真的，用起來感覺就像那個年代的東西。

沒有 JSON，只有一堆很神秘的專有格式。沒有統一的日期格式，光一個日期就有好幾種寫法。所有東西都跑在 TCP 上，除錯起來...很痛苦。

簡單說，你想讀一封 email 的結構，得先解析像天書一樣的 `bodystructure`。那串東西真的很...反人類。老實說我一開始也想放棄，直接下載整封信就算了，但這樣又會載到一堆附件，不清爽。

所以，很多新的團隊不想碰這個麻煩。他們選擇只用 Gmail API，犧牲掉其他用戶，換來快速開發和上線。這是一種取捨。可以理解，但...嗯。

我把它們的差異整理了一下，感受會更直接。

比較項目	Gmail API	IMAP 協定
開發難度	低。就是現代 web API，很標準，文件也新。	高到爆炸。像在考古，文件老舊，還有一堆奇怪的 edge cases。
支援範圍	僅限 Gmail 和 Google Workspace。市場大概...三成？	幾乎所有 Email 服務商。iCloud, Outlook, Zoho, 還有各國的 ISP...
資料格式	JSON。乾淨、好懂。	專有格式。一堆括號和奇怪的字串，要寫專門的 parser 才行。
開發速度	快。可能幾週就能做出原型。	慢。光是搞懂連線、認證、解析格式就要很久，我自己就卡了很久。
長期風險	被 Google 綁死。他一改規則，你的 App 就得跟著改，沒得選。	很穩定。這東西幾十年沒大改了，可能再戰十年...吧。缺點就是太老。

最諷刺的地方：Google 其實不建議

這就是整件事最有趣的地方。當我一開始也想偷懶，考慮只用 Gmail API 的時候，看到了 Google 官方開發者文件的一段話。

他們...嗯，他們「不建議」用 Gmail API 來做一個完整的 Email 客戶端。

對，你沒看錯。Google 自己都說，這條捷徑不是給你這樣走的。這 API 比較適合用來做一些帳號內的自動化、讀取特定標籤信件之類的功能，而不是一個全功能的收發信軟體。

我看到這個警告就...縮了。決定還是走那條難走的路，硬著頭皮去啃 IMAP。

在地觀點：這在台灣真的行不通

說真的，這種「Gmail-only」的思維在矽谷可能很普遍，但在台灣...完全是另一回事。

你想想，我們身邊有多少長輩、或是一些公家機關、學校，還在用 Hinet、PChome 或學校的 email？我查了一下，像中華電信的 Hinet 信箱，他們的官方說明頁面就是提供 IMAP 和 POP3 的設定資訊。這些帳號，你在 Notion Mail 或 Mimestream 上根本沒辦法用。

這點就跟純美國市場的思考很不一樣。只支援 Gmail，等於是直接放棄了這群龐大的非 Gmail 用戶。對一個想做通用工具的產品來說，這市場缺口太大了。

所以，IMAP 是個討厭的護城河？

繞了一圈回來，好像變成這樣：IMAP 因為太難搞，反而成了一道技術門檻。一道把只想求快、不想處理麻煩事的開發者擋在外面的牆。

我承認，如果沒有現在 AI 工具的幫忙，我可能也早就放棄了。Gemini 幫我回答了超多關於 IMAP 的白癡問題，才讓我把功能做出來。現在我的 App (Tejido) 不只可以收 Gmail，我自己的 `andrewzuo.com` 網域信箱 (用 Zoho) 也能一起看，不用再全部轉寄到 Gmail 了。

支援度更廣，反而成了我的競爭優勢。一個整合式收件匣，這才是很多人真正需要的。