美國免稅州地址完整指南：數位商品、Apple ID、訂閱和測試怎麼選

先說結論：不要只記五個州名

你搜「美國免稅州地址」，大多是為了找一個帳單地址，用在 Apple ID、Google Play、Steam、SaaS 訂閱、軟體購買，或用來測試結帳表單。常見的五個州是特拉華、俄勒岡、蒙大拿、新罕布什爾和阿拉斯加。

這五個州都沒有州級的一般銷售稅，但它們並不是完全一樣。特拉華最乾淨，俄勒岡也很穩定，蒙大拿和新罕布什爾適合補充測試樣本，阿拉斯加因為可能有地方銷售稅，更適合做邊界測試，而不是預設選擇。

所以更實用的判斷方式不是「哪個州免稅」，而是「我的場景需要多穩定」。如果你只是需要一個預設零稅路徑，選特拉華；如果你要測系統能不能處理地方稅差異，才考慮阿拉斯加。

五個美國免稅州對比

下面這張表按實際使用價值排序。重點不是稅法課本定義，而是你在帳單地址、數位商品和軟體測試裡會遇到什麼差異。

特拉華：最適合作為預設免稅州地址

如果你只想選一個最省心的免稅州地址，優先選特拉華。原因很簡單：它沒有州銷售稅，也沒有地方銷售稅。對普通使用者來說，特拉華地址最接近「填了以後不容易出現額外銷售稅」的預期。

對軟體測試來說，特拉華也很好用。你可以把它固定為「零稅路徑」的標準樣本：同一個商品、同一個帳號條件下，如果特拉華地址突然出現銷售稅，測試人員就能快速發現平台規則、商品分類或稅務計算邏輯發生了變化。

俄勒岡：第二個穩定的零稅樣本

俄勒岡同樣沒有一般銷售稅，實際使用中也很穩定。它的價值在於可以作為特拉華之外的第二組零稅樣本，尤其適合你想覆蓋西岸地址、不同城市名和不同 ZIP 郵遞區號時使用。

如果一個系統只用特拉華測試，很容易漏掉 UI 寬度、城市欄位、州名翻譯、ZIP 校驗等問題。加入俄勒岡，可以在不引入複雜稅費變數的前提下，讓測試資料更接近真實使用環境。

蒙大拿和新罕布什爾：適合補充覆蓋，不適合偷懶當萬能答案

蒙大拿和新罕布什爾也經常被列進免稅州名單，但它們更適合作為補充樣本。比如你要測試多個州的地址格式、州縮寫、電話號碼區號、CRM 地區欄位，加入 MT 和 NH 會比只測試 DE、OR 更完整。

需要注意的是，沒有一般銷售稅不等於所有場景都沒有稅。餐飲、住宿、通信、度假區、特定服務等規則可能不一樣。如果你的測試目標是數位商品或軟體訂閱，問題通常不大；如果測試實體配送、酒店、餐飲或本地服務，就不要把它們簡單當成「永遠零稅」。

阿拉斯加：最容易被誤用的免稅州

阿拉斯加沒有州銷售稅，但部分地方政府可以徵收地方銷售稅。這就是它和特拉華、俄勒岡最大的不同。很多人看到 Alaska 出現在免稅州名單裡，就把它當成預設免稅地址，這是不穩的。

阿拉斯加真正適合的場景是邊界測試。比如你的結帳系統、稅費服務或帳單地址邏輯需要判斷地方稅，那麼阿拉斯加地址可以幫你測「州稅為 0，但地方可能有稅」的情況。

不同場景怎麼選地址

實際使用時，不要每次隨機換州。更成熟的做法是給每類場景準備固定樣本，這樣結果才可重現。

• Apple ID、Google Play、Steam、SaaS 訂閱：優先使用特拉華，其次俄勒岡。
• 軟體測試的預設零稅路徑：固定使用特拉華，方便回歸測試。
• 第二組零稅樣本：使用俄勒岡，覆蓋不同城市和 ZIP。
• 地方稅邊界測試：使用阿拉斯加，確認系統不會把所有免稅州都當成完全零稅。
• 有稅對照樣本：保留加州、紐約、德州等地址，確認稅費行能正常出現。

數位商品、Apple ID、Google Play、Steam 和 SaaS 要注意什麼

很多平台會把帳單地址作為稅費判斷的一部分，但它通常不是唯一因素。帳號地區、付款方式、商品類型、平台自己的稅務規則、購買時間，都會影響最終結果。

所以，如果你只是做表單測試，重點是城市、州、ZIP 和地址格式一致；如果你要測真實結帳稅費，就必須記錄商品類型、帳號地區、付款方式和測試日期。

這裡最容易犯的錯誤，是把「免稅州地址」當成某個平台一定免稅的保證。更準確的說法是：免稅州地址可以作為測試變數，但不能替代平台自身的稅務規則。