為什麼我做了「神速．郵遞區號」

有一次我要幫忙處理一批要寄出的年節禮盒，收件清單有三十幾筆地址，每一筆都要填正確的 3+3 郵遞區號。我打開一個查詢網站，貼上第一筆地址、等結果、複製、貼到清單裡；再貼第二筆、再等、再複製……做到第十筆的時候，我已經在想：這件事本來就該是「貼上一整份清單、拿回一整份結果」，為什麼所有工具都只讓我一次查一筆？

這就是「神速．郵遞區號」的起點。

問題不是查不到，是查得太慢

市面上的郵遞區號查詢工具，資料通常沒問題——中華郵政的 3+3 資料是公開的，難的從來不是「有沒有這筆資料」，而是「使用者要花多少力氣才能拿到答案」。

如果你手上只有一筆地址，這件事很小；但只要清單一長，問題就會被放大：電商賣家要核對出貨地址、行政人員要處理報名名單、朋友要幫忙寄喜帖——這些情境的共同點是「地址不是一筆，是一批」。既有工具的設計預設你一次只查一筆，於是「查郵遞區號」這件事被拆成無數次重複的貼上、等待、複製，工具本身反而變成了瓶頸。

所以我決定把核心體驗定義成：貼上一整份清單，答案逐行自己跑出來。

為什麼查一整批也能很快

批次查詢聽起來像是把「查一筆」的動作重複幾十次，但如果真的這樣做，三十筆地址就要等三十次的往返時間，快不起來。神速能做到「貼上就出答案」，靠的是幾個技術上的取捨。

整個查詢都在瀏覽器裡跑，不經過任何伺服器。 這代表貼三十筆地址不是三十次網路請求，而是你的裝置在本機同時算三十筆——省下的不是運算時間，是網路來回的時間，而那才是真正拖慢查詢的地方。這個決定還有一個附帶好處：你打的地址一個字都不會送到伺服器，查完就查完，沒有留存。

資料不是一次全部載入，而是分層、按需要才拿。 第一次跟頁面互動時，瀏覽器只需要讀不到 3 KB 的核心資料（縣市與行政區），實測中位數花費是 0.12 毫秒；之後查到需要哪個行政區的道路、門牌規則，才去拿對應的那一份，全部拿齊也只是幾毫秒等級。這個分層設計把舊版本一次要吞 250 KB 的索引，拆成大部分查詢只需要碰到最小那一層。

結果不是等全部算完才出現，而是邊算邊填。 貼上三十筆地址後，畫面會立刻鋪出三十列的骨架，然後隨著每一列算完就即時填上郵遞區號，卡片頂端有一條進度條同步往前推進。你不用盯著空白畫面等待，查詢的過程本身是看得到的。

跑完之後，畫面會秀出這批查詢用了幾毫秒、平均每秒處理幾筆——這也是「神速」這個名字想直接讓你看到的東西：速度不是宣稱出來的，是每次查完都攤在你眼前的數字。

查不到，就老實說查不到

批次處理最怕的不是慢，是為了給出答案而給錯答案。神速的判斷邏輯很保守：只有分數夠高、而且明確收斂到單一郵遞區號時，才會直接回傳結果；如果地址資訊不足，或者同一個地址剛好對應多個專用郵遞區號，系統不會硬猜一個看起來合理的答案，而是把那幾列標成待確認，讓你自己判斷。

寧可讓你在幾十筆裡多看一眼那兩三筆，也不要讓一整批清單裡混著幾筆錯的郵遞區號——尤其這批資料很可能直接就拿去寄件了。

查完了，然後呢

批次查詢的最後一步是把結果拿走，所以整批結果卡片右上角只有一顆「一鍵複製」：郵遞區號跟地址用 Tab 字元分隔複製起來，直接貼回 Excel 或 Google Sheets 就是乾淨的兩欄，不用再手動調整格式。

這篇先記錄「為什麼」跟「怎麼做到快」。如果你想知道實際怎麼操作、怎麼把自己手上的地址清單貼進去拿到結果，可以接著看下一篇的使用教學。