電子發票系統怎麼選？2026 加值中心、費用、API 與電商串接比較

電子發票系統怎麼選？2026 加值中心、費用、API 與電商串接比較

內容目錄 顯示
加入為 Google 偏好來源

電子發票系統不是「選最便宜的月費就好」。營業人真正要選的是一套責任分工：誰依交易建立發票，誰管理字軌，誰把資料送到財政部電子發票整合服務平台，誰處理作廢與折讓，以及傳輸失敗時由誰接手。

如果只比較首頁上的張數與價格，很容易把政府平台、傳輸軟體、加值服務中心及購物網站模組當成同一類產品。結果可能是買了服務，才發現仍缺正式字軌、例外流程或既有系統介接。

來源：財政部《電子發票實施作業要點》（查證 2026-07-24）。現行要點分別規範電子發票系統、整合服務平台、字軌、傳輸、加值服務中心及例外處理責任；本文以選型角度重組，不取代主管稽徵機關或專業稅務人員的個案判斷。

電子發票系統是什麼？

對營業人來說，電子發票系統不是單一畫面，而是能依規定建立發票資料，處理必要交易情境，防止字軌錯誤，並把資料送到加值服務中心或財政部整合服務平台的一組功能。購物網站可以是資料來源，卻不必然等於完整的電子發票系統。

合規系統不只要能開立一張發票

依財政部現行作業要點，營業人或加值服務中心使用的電子發票系統，要有資訊安全措施，具備電子發票的開立與接收功能，也能處理作廢、銷貨退回或折讓等情境，並依規定列印電子發票證明聯。

財政部整合服務平台是官方平台，不是商業方案的同義詞

電子發票整合服務平台是財政部提供電子發票相關整合性服務的平台。營業人會在官方流程中使用它處理身分認證、字軌取號或查核資料，系統與平台之間也要依規定傳輸電子發票資訊。

載具是買受人承接資訊的方式，不是商家開票系統

載具是經財政部核准，可記載或連結雲端發票資訊的號碼。顧客在結帳時提供手機條碼或其他適用載具，網站把資料交給開票系統，最終由系統依規定處理。

購物網站模組通常只負責訂單與發票服務之間的連接

購物網站知道商品、金額、付款與退貨狀態，發票服務則依接收到的資料處理發票動作。網站模組的工作，是把符合條件的訂單事件轉成發票服務能理解的請求，再把處理結果寫回訂單。

來源：財政部《電子發票實施作業要點》（查證 2026-07-24）。系統功能、字軌防錯、漏傳檢核、整合服務平台及載具定義取自現行要點；購物網站模組的責任分工是本文依電商資料流整理的選型框架。

Turnkey、加值服務中心、ERP／POS 與購物網站整合差在哪裡？

四種名稱代表不同層級。Turnkey 偏向資料傳輸，加值服務中心提供經核准的電子發票系統與相關服務，ERP／POS 管理企業或門市交易，購物網站整合則把線上訂單接到實際開票路徑。它們可以組合使用，不必四選一。

導入層級主要負責什麼技術門檻常見優點主要風險適合先問的問題
自有系統搭配 Turnkey自行建立發票資料，再透過財政部傳輸軟體與平台交換高控制範圍大，可深度整合既有系統開發、檢測、維運與錯誤處理責任較重團隊能否長期維護資料格式、憑證及重送機制？
加值服務中心提供電子發票系統，以及資料傳輸、資料交換、資料保存等相關服務中至低，依介接方式而異可降低底層建置負擔，通常有後台或 API服務範圍、費用與資料移轉條件依契約而異是否支援所需交易情境，退出時能否完整匯出？
ERP／POS 串接從企業資源或門市銷售系統產生交易資料中至高可與庫存、會計、門市及對帳流程整合前端系統未必自行負責法定傳輸與全部例外後端由哪個開票及傳輸服務承接？
購物網站整合將線上訂單狀態映射成發票動作低至中設定集中，減少重複輸入支援範圍受網站與發票服務的既有介接限制正常訂單與退款流程是否都能驗證？

Turnkey 是傳輸軟體，不是買來就能完整開票的套裝服務

財政部 Turnkey 使用說明書把它定位為電子發票傳輸軟體，供營業人與加值服務中心傳送及接收發票資料檔案，並取得相關確認訊息。使用者仍要有能產生符合規格資料的系統，也要能處理回覆與錯誤。

加值服務中心是經核准提供系統及相關服務的營業人

現行作業要點對加值服務中心有明確定義與申請規範。一般營業人向加值服務中心購買後台或介接服務，是委託其處理一部分電子發票系統與資料交換工作，不是把營業人的全部責任轉給服務商。

ERP 與 POS 負責交易管理，不必然直接負責官方傳輸

ERP 是 Enterprise Resource Planning，中文常譯為企業資源規劃；POS 是 Point of Sale，中文常稱銷售時點系統。白話來說，前者整合企業內部的訂單、庫存、會計與其他資源，後者記錄門市銷售與收款。

購物網站整合降低重複輸入，但能力受既有介接限制

網站內建或擴充的發票模組，可以把付款結果與訂單取消或退貨等事件送到發票服務。它的優勢是減少人工複製訂單資料，也能在同一筆訂單保存發票狀態。

來源：財政部《電子發票實施作業要點》、Turnkey 使用說明書與電子發票 Turnkey 上線前自行檢測作業（查證 2026-07-24）。Turnkey 與加值服務中心定位依官方資料；ERP、POS、API 及購物網站整合的責任拆解是本文提供的系統選型方法，特定產品仍應以官方文件與測試結果確認。

電子發票系統有哪些費用？

電子發票系統費用不能只看一個月費數字。供應商可能採月費、年費或張數制，也可能另外計算設定、通知、紙本列印、API 介接、硬體及移轉服務。比較前要先把每一家報價換成相同期間與相同使用情境。

初始成本包含設定、介接與內部準備

系統設定費通常是首次開通或重新申請時的一次性費用。若商家需要網站、ERP 或 POS 串接，還可能有開發、測試、資料轉換及專案管理成本。採用自有 Turnkey 時，軟體本身不是唯一成本，主機、憑證管理、監控及維運人力也要納入。

固定費與用量費要換算成同一期間

有些方案提供月費或年費內含張數，超過後再加購；有些採總張數包，不限制使用期限；也有方案依當月是否開立及張數區間計費。商家應以平月、旺季及全年總量三組數字試算，不能只用平均月訂單量。

通知、列印、客服與移轉可能另外計價

Email 通知可能包含在方案內，簡訊與超商多媒體列印則可能按次計費。實體門市若需要 POS、掃描器、錢箱或紙材，還要加入設備與耗材成本。

用總持有成本比較，不用單一促銷價排名

TCO 是 Total Cost of Ownership，中文常譯為總持有成本。白話來說，它是把系統取得成本，使用成本，維護成本與退出成本放在一起。名稱的限制是容易被誤解成只有廠商帳單；實際上，內部人力與營運中斷風險也屬於選型成本。

官方公開方案快照設定或啟用主要計費方式額外項目示例閱讀時要注意
綠界電子發票新用戶系統設定費 3,600 元年張數方案；公開頁列出 5,000、20,000 及 120,000 張級距簡訊、超商列印與 POS 設備另有牌價公開價標示未稅；新戶優惠有申辦期間
光貿電子發票首次開通提供三個月免費期免費期後，當月 50 張內月費 99 元，51 張以上月費 199 元當月未開立不計費；已開立後作廢仍會計費公開頁標示含稅，適用條件以當年度申辦說明為準
ezPay 電子發票首次申請系統設定費 3,000 元年費內含每月張數，另有總張數計費方案加購張數與超商列印另計公開頁標示含稅；月配額與加購張數的延續規則不同

來源：綠界電子發票費用說明、光貿電子發票方案介紹與ezPay 電子發票官方方案（查證 2026-07-24）。表格只摘錄可在官方公開頁直接核對的設定費與主要計價模型；優惠期限、含稅狀態、加購規則及適用資格可能變動，採購前應取得正式報價與契約。

不同營業情境要怎麼選電子發票系統？

「哪家最好」沒有脫離情境的答案。低張數門市重視簡單操作，單一購物網站重視既有串接，B2B 與訂閱服務重視例外流程，多通路企業則更在意 ERP／POS 整合與權限管理。

營業情境優先需求可先評估的路徑容易忽略的風險驗收重點
低張數門市或工作室後台易用，低固定負擔，人工開立加值服務中心網頁後台或適用的簡易方案低價方案缺少批次、API 或進階情境實際執行開立，作廢，查詢與匯出
單一購物網站訂單自動開票功能、載具功能與退款流程網站既有整合搭配相容發票服務只支援正常開立，沒有例外重送付款案例，取消案例，退貨案例及失敗案例
B2B 月結或批次開票統編資料、批次作業、發票對帳與交換需求加值服務中心、ERP 介接或自有系統把 B2C 填統編誤當完整 B2B 流程開立模式、買受人確認及批次錯誤處理
訂閱或定期扣款服務週期性觸發，付款失敗，取消及退款可處理定期事件的網站或後端介接重複開立及付款失敗仍觸發開票每期事件唯一性與補扣款流程
多門市、多網站或 ERP 企業集中字軌，權限，跨系統對帳ERP／POS 整合、自有 Turnkey 或企業級加值服務各通路規則不一致，資料難以追溯分店配號、角色權限及總分帳核對

低張數門市先看日常操作與最低持續成本

每月發票不多，而且沒有網站或 ERP 串接需求的商家，未必需要先做客製 API。比較網頁後台能否快速開立，作廢，查詢與匯出，再評估固定費、最低用量及客服是否符合工作方式。

單一購物網站先確認既有整合的完整度

如果大部分訂單都從同一個網站進入，優先使用已驗證的既有整合，通常能降低開發與維運負擔。但「已整合」要拆成具體功能，不能只看服務商名稱出現在下拉選單。

B2B 月結與訂閱服務都要重視例外事件

B2B 月結常需要批次資料、買受人資訊與對帳流程；訂閱服務則會反覆遇到週期扣款，付款失敗，方案變更及取消。兩者都不適合只用「單筆正常開立成功」作為驗收結論。

多通路企業先畫資料流，再決定系統中心

同時有門市、購物網站、業務訂單與 ERP 的企業，要先決定哪一套系統是交易與發票狀態的主要紀錄來源。若每個通路各自管理字軌與錯誤，後續對帳與權限控管會更困難。

來源：財政部《電子發票實施作業要點》、綠界電子發票 API 官方文件、光貿電子發票 API 官方文件與ezPay 電子發票下載專區（查證 2026-07-24）。情境矩陣依官方系統功能與 API 文件可查範圍整理；路徑建議是本文的選型判斷，不代表對特定供應商的無條件推薦。

詢價電子發票系統前要準備哪些資料？

供應商無法只憑「每月大約幾張發票」做出可比較的完整報價。商家要先整理交易來源、買受人類型、開票時點、例外事件、現有系統與退出需求，再請不同供應商用同一份資料回覆。

先畫出所有會觸發發票動作的交易

先列出訂單從哪裡進來，例如門市 POS、購物網站、業務建單、訂閱扣款或 ERP 批次。接著為每種訂單標示付款成功，取消，全部退貨，部分退貨與資料更正時，預期發生哪一個發票動作。

用平月、旺季與尖峰時段估算容量

準備最近可代表實際營運的訂單資料，分別計算平月總量、旺季總量、單日尖峰及短時間大量開票需求。若新事業尚無歷史資料，就以保守、中性與成長三種情境估算，並註明假設。

把現有網站、ERP、POS 與權限列清楚

提供使用中的購物網站、ERP、POS、會計系統與資料匯出格式，也要說明是否已有開發人員。若要使用 API，請供應商提供正式文件、測試帳號、支援版本與認證方式，不只回覆「可以串接」。

先確認服務水準與退出機制

SLA 是 Service Level Agreement，中文常譯為服務水準協議。白話來說，它把服務可用性、回覆時間或事件處理目標寫成可核對的約定。這個名稱的限制是容易讓人以為有 SLA 就保證永不中斷；實際上仍要看衡量方式、排除條款及未達標時的處理。

用哪 12 項需求比較電子發票系統？

需求矩陣要同時記錄必要性、詢價問法與驗收證據。供應商說「支援」只是起點；商家要能在測試環境完成實際案例，或取得明確文件與合約承諾。

比較需求為什麼重要詢價時怎麼問可接受的驗收證據
1. 發票模式與買受人類型B2B 與 B2C 的資料及流程可能不同支援哪些開立模式？買受人為營業人時有哪些欄位與流程？各模式測試發票、欄位文件及處理結果
2. 載具、捐贈與證明聯影響結帳欄位及顧客交付方式支援哪些載具驗證、捐贈及證明聯輸出？測試訂單、最終發票內容及交付紀錄
3. 字軌與配號管理錯置期別或號碼會造成正式開票風險字軌如何匯入，配號，檢核與回收未使用號碼？正式前的配號畫面、權限與防錯紀錄
4. 開立時點與訂單觸發避免未付款訂單誤開，或付款後漏開可用哪些訂單狀態觸發？能否延遲或人工覆核？付款成功案例，付款失敗案例及待付款案例
5. 作廢與資料更正正常開立之外仍會出現人工作業支援哪些更正與作廢情境？同意紀錄存在哪裡？測試前後狀態、同意訊息及平台結果
6. 退貨與折讓部分退貨不一定能用單一退款動作處理全部與部分退貨如何映射到發票動作？訂單、退款、折讓與發票狀態對照
7. 錯誤通知與重送發票請求送出不代表平台已接收哪些錯誤會自動重送？如何避免重複開立？錯誤代碼、重送紀錄及人工待辦
8. 顧客通知Email、簡訊與紙本可能有不同費用及責任可用哪些通知方式？失敗是否可補寄或查詢？通知紀錄、補寄結果及費用表
9. 查詢、匯出與對帳財會需要跨訂單、金流與發票核對能匯出哪些欄位、格式與期間？範例匯出檔、發票對帳表及查詢畫面
10. 權限與操作紀錄多人操作時要能追溯誰做了什麼能否依角色限制功能？是否保留操作紀錄？測試角色、權限差異及操作日誌
11. API 與測試環境文件與測試能力決定介接風險是否提供測試帳號、完整文件、版本政策及技術支援？測試請求、回覆、錯誤處理及版本通知
12. SLA、移轉與退出上線後仍要面對中斷、續約或換系統服務中斷如何通知？終止時能匯出什麼，多久可交付？SLA 條款、資料樣本及退場交接書面說明

必要需求與加分需求要分開

先把沒有就不能上線的功能標為必要，例如正式開立、字軌防錯、退款情境與對帳資料。操作介面偏好、額外報表或非近期通路，可以列為加分項，不讓所有功能得到相同權重。

正常流程與例外流程要各有測試案例

正常案例至少涵蓋付款成功後開立，例外案例則依商家情境加入付款失敗，取消，全部退貨，部分退貨及傳輸錯誤。每個案例記錄輸入資料、預期結果、實際結果與負責人。

權限、紀錄與匯出決定日後能否管理

發票系統不是只有開票當下。人員異動、客服查詢、財會對帳與系統更換，都需要可控權限及可匯出的歷史資料。

用同一種評分與證據完成供應商比較

可為每項需求設定「必要」「重要」「加分」三個等級，再把供應商回覆標為「已實測」「文件可證」「書面承諾」或「未證實」。未證實項目不應直接算作具備功能。

來源：財政部《電子發票實施作業要點》、綠界電子發票 API 官方文件、光貿電子發票 API 官方文件與ezPay 電子發票下載專區（查證 2026-07-24）。12 項矩陣以現行法規要求與三家官方文件可查功能為底座；需求權重、證據分級與驗收方法是本文提供的供應商中立選型工具。

電子發票系統選型有哪些常見陷阱？

選錯系統通常不是因為方案完全不能開票，而是商家只驗證了最簡單的單筆開立，沒有看例外事件、正式環境、權限與退出成本。等到退款、旺季或人員異動發生，缺口才會進入日常營運。

常見陷阱當下看起來上線後可能發生選型時的防線
只看最低月費固定支出很低必要功能需加購，總成本反而較高用相同交易量與功能範圍計算 TCO
只測正常開立測試訂單成功取消流程，退貨流程或折讓流程無法完成正常與例外案例都要留下驗收紀錄
測試與正式設定混用測試環境順利正式憑證、字軌或端點錯置建立環境對照表並由第二人覆核
重送沒有防重複失敗後能再次送出同一訂單可能重複開立驗證唯一訂單識別、查詢與重送規則
所有人共用管理者帳號操作方便無法追溯誰變更字軌或作廢發票依角色分權並保留操作紀錄
沒有退出計畫導入時省事換系統時資料、字軌與未結案件難交接簽約前取得匯出樣本及退場條款

低價方案要先補齊缺少功能的成本

方案月費低，不代表完成同一件事的總成本低。若載具驗證、批次匯入、API、簡訊或資料匯出需要加購，要把所有必要項目加回 TCO，再與其他方案比較。

只測開立成功會漏掉真正耗時的例外

正常訂單通常是最容易通過的案例。營運成本更常出現在付款失敗，取消，部分退貨，傳輸錯誤與顧客資料更正，因為這些情境需要跨網站、金流、發票與人工處理。

正式環境與錯誤重送要一起驗收

測試帳號成功，不代表正式憑證、商家識別、字軌期別與 API 端點都已正確。正式切換前，要把每個環境的設定來源與保管人列在同一張對照表，敏感值則放在受控位置。

權限、資料匯出與退出條款不能留到續約時才問

共用管理者帳號雖然省設定時間，卻會讓日後難以追溯變更。至少區分日常操作與敏感管理權限，並確認作廢操作、字軌管理、權限管理及資料匯出等關鍵操作是否有紀錄。

來源：財政部《電子發票實施作業要點》、電子發票 Turnkey 上線前自行檢測作業與前述三家官方 API 文件（查證 2026-07-24）。字軌防錯、漏傳檢核、自行檢測與例外處理責任依官方規範；環境對照、權限分工、重送防重複與退出驗收是本文提供的選型風險控制方法。

小型購物網站怎麼實際比較電子發票系統？

以下為假設案例，不代表任何真實商家或供應商。某小型購物網站以 B2C 訂單為主，需要載具、捐贈、統編、全部退貨、部分退貨、API 開票與每週對帳，並希望由客服處理一般查詢，財會負責作廢與折讓。

先把年度張數與尖峰需求算開

假設網站一年有 10 個平月，每月 400 筆成功訂單；另有 2 個旺季月，每月 800 筆。先把兩段需求分開：

  • 平月需求：400 筆 × 10 個月 ＝ 4,000 筆。
  • 旺季需求：800 筆 × 2 個月 ＝ 1,600 筆。
  • 基礎年度需求：4,000 ＋ 1,600 ＝ 5,600 筆。
  • 10％ 緩衝：5,600 × 10％ ＝ 560 筆。
  • 規劃張數：5,600 ＋ 560 ＝ 6,160 筆。

用必要需求先淘汰不能上線的方案

案例先設定 8 項必要需求，再談價格：

必要需求最低驗收標準
購物網站 API測試訂單可送出並回寫發票號碼與狀態
B2C 與統編欄位一般消費者與需統編訂單都能正確開立
載具與捐贈欄位可驗證，最終發票內容與訂單選擇一致
全部與部分退貨各完成一筆測試並保留狀態對照
錯誤通知與重送可收到失敗原因，重送不會重複開立
查詢與對帳能以訂單編號反查並匯出期間資料
角色權限客服與財會只能使用各自需要的功能
資料移轉可取得歷史資料樣本與退場書面說明

同時比較年度總量與每月用量限制

假設取得三種不具名報價模型，先不填價格，只比較張數規則：

假設方案方案張數依本案例計算還要詢問
A 年度方案每年內含 6,000 張6,160 － 6,000 ＝ 160 張超額超額單價是多少，是否可以加購，以及到期規則為何
B 月度方案每月內含 500 張平月無超額；旺季每月 800 － 500 ＝ 300 張，2 個旺季共 600 張超額月內未用張數能否延續及旺季加購
C 總張數包一次購買 10,000 張10,000 － 6,160 ＝ 3,840 張餘量使用期限、退款與下期延續規則
  • A 的 TCO ＝設定與介接費＋年度服務費＋160 張超額費＋通知費＋內部維運。
  • B 的 TCO ＝設定與介接費＋12 個月固定費＋600 張超額費＋通知費＋內部維運。
  • C 的 TCO ＝設定與介接費＋10,000 張數包＋通知費＋內部維運＋未用張數風險。

用受控試跑與退場證據完成決策

最後讓通過必要需求的候選方案跑相同案例：一般 B2C、統編訂單、載具、部分退貨，以及一次模擬傳輸失敗。每個案例保存網站訂單、API 結果、發票服務紀錄與平台狀態。

說明：本節的訂單量、方案張數與計算結果皆為選型教學用的假設資料，不代表綠界、光貿、ezPay 或秒站的實際方案。計算方法用來示範如何把平月、旺季、緩衝、超額與未用張數分開；正式決策應改用商家真實訂單與供應商正式報價。

內文精華總結

  • 電子發票系統是什麼：對營業人來說，電子發票系統不是單一畫面，而是能依規定建立發票資料，處理必要交易情境，防止字軌錯誤，並把資料送到加值服務中心或財政部整合服務平台的一組功能。
  • 合規系統不只要能開立一張發票：依財政部現行作業要點，營業人或加值服務中心使用的電子發票系統，要有資訊安全措施，具備電子發票的開立與接收功能，也能處理作廢、銷貨退回或折讓等情境，並依規定列印電子發票證明聯。
  • 財政部整合服務平台是官方平台，不是商業方案的同義詞：電子發票整合服務平台是財政部提供電子發票相關整合性服務的平台。
  • 載具是買受人承接資訊的方式，不是商家開票系統：載具是經財政部核准，可記載或連結雲端發票資訊的號碼。

想把電子發票系統規劃成能長期營運的網站？

先用秒站建立可操作的網站，再依實際內容、功能與營運需求調整。你可以先試用，查看方案，或從真實案例確認適合自己的方向。

延伸閱讀

電子發票系列文章

秒站現在不只是一套版型。你可以從現成架構快速開始，用頁面編輯器拖曳、複製與調整版面；需要更高自由度時，也能和 AI 協作，把自製頁面放進 Vibe 畫布。上線速度與設計自由不必二選一。

秒站所說的「輕電商」，輕的是適用的營運量級，不是功能。電商行銷百寶箱把商品上架、折價券、購物點數、訂單通知、付款與運送規則，以及折扣活動集中在同一套後台，再接上金流、發票與物流，讓中小品牌建立從商品上架到訂單溝通的銷售流程。

重點整理

電子發票系統哪家好？

沒有脫離情境的單一最佳選擇。先確認 B2B／B2C、每月張數、載具與捐贈、作廢與折讓、API、通知及客服責任，再用同一份情境向供應商詢價與對帳。適合別人的低價方案，不一定涵蓋你的交易例外與維運需求。

電子發票系統費用怎麼比較？

把設定費、月費或年費、內含張數、超額張數、通知與列印、API 串接、移轉及內部人力換成同一期間的總持有成本。不要只拿月費比年費，也不要忽略第二年續約、超量與退場成本。

電子發票可以自己申請嗎？

可以依官方程序自行確認資格，完成身分認證，申請字軌並選擇傳輸方式，也可以委託加值服務中心協助部分系統工作。無論採哪條路，營業人仍要確認發票內容、開立時點、例外交易及對帳責任。

Turnkey 與加值中心差在哪裡？

Turnkey 偏向企業端與財政部平台之間的資料傳輸軟體；加值服務中心則提供經核准的電子發票系統與相關商業服務。自行使用 Turnkey 需要較多開發與維運能力，加值中心通常降低技術負擔，但會有方案與用量等服務邊界。

電子發票系統常見缺點有哪些？

常見限制包括超量或通知另計，API 功能不完整，測試與正式環境差異，作廢折讓流程受限，以及資料匯出與退場困難；有些客服也只處理系統，不處理訂單規則。簽約前應用正常與例外交易逐項驗收。

B2B、B2C、載具與捐贈都會支援嗎？

不一定，必須逐方案確認。除了是否有欄位，還要測試買受人統編、載具驗證、捐贈碼、開立時點、退貨、部分折讓與對帳結果。只看到功能名稱，不能證明所有交易情境都能正確完成。

作廢與折讓怎麼處理？

交易尚未成立或符合規定的情況可能使用作廢；已成立交易後發生退貨或金額調整，則可能需要銷貨退回、進貨退出或折讓。實際程序依發票類型與交易狀態判斷，網站、金流、訂單及發票系統的狀態也要同步。

電子發票 API 要比較哪些功能？

至少比較測試環境、認證方式、版本與停用政策、錯誤碼、重送與防重複、開立結果查詢、Webhook 或回寫、作廢與折讓、速率限制及服務水準，並另外確認對帳匯出。正式採用前要用同一組測試案例驗證，不只看文件有沒有 API。

分享此文章：

相關文章