以前做 D3 資料圖表時，我就把資料放在 Google 試算表。原因很簡單：資料好建立、可以找人一起整理，而且不用每改一筆資料就重新改網站程式。

現在如果要做一個小型活動頁，我也會先想想這個做法。假設網站要顯示活動名稱、日期和報名網址，你可以把這些資料一列列放進試算表；網站讀取後，再排成大家看得懂的活動卡片。資料有變，回到表格修改就好。

但在開始串接以前，要先決定一件事：這份資料可以公開嗎？ 答案不同，後面的做法就不一樣。

第一種：本來就要給大家看的資料

活動時間、公開菜單、作品列表，這些內容原本就準備放在網站上。你可以把它們整理在一份專門放公開資料的試算表，透過 Google 試算表的「發布到網路」選擇要發布的工作表與格式，讓網站取得資料。Google 官方也提供發布單一工作表的選項。（來源：Google Docs Editors Help：Make Google Docs, Sheets, Slides and Forms public）

這條路的好處是設定相對少，適合先把畫面做出來。不過，公開資料就真的會被別人取得。不要把報名者的電話、Email 或內部備註放在同一份公開用的檔案裡，再期待網站只讀某幾欄就沒事。要分開，就直接分成兩份試算表。

Google Sheets API 也能依試算表 ID 和範圍讀取儲存格。例如 活動!A2:D20，意思是讀取「活動」工作表的 A2 到 D20。回傳的資料再由網站整理成卡片、清單或表格。（參考：Google for Developers：JavaScript quickstart）

第二種：只有特定帳號能看的資料 🔐

如果放的是內部名單或個人紀錄，就不能把表格發布到網路。這時需要由有權限的 Google 帳號登入，經過授權後，再讀取試算表。登入不會憑空取得權限：那個帳號本身還是要能存取這份檔案。

我之前整理過一份 Google Cloud 設定筆記，下面把跟這篇有關的畫面挑出來。截圖是 2025 年的介面，Google Cloud 左側選單後來有調整；如果位置對不上，照目前官方文件找 Google Auth Platform → 品牌／目標對象／用戶端。（參考：Google for Developers：JavaScript quickstart）

先啟用 Google Sheets API

在 Google Cloud 選好專案，搜尋 Google Sheets API，進入服務頁後啟用。這一步是告訴 Google：「這個專案要用試算表 API。」

啟用 API 之後，網站還不能直接讀私人表格。接下來要設定「誰要使用這個應用程式」以及「使用者同意它做什麼」。

再設定授權畫面

在 Google Auth Platform 填應用程式名稱、支援信箱與目標對象。如果是個人帳號要先做測試，通常會選「外部」；只有 Google Workspace 組織內部的人使用，才考慮「內部」。

如果「外部」應用程式還在測試狀態，要把自己的 Google 帳號加進測試使用者名單。不然常會出現自己能登入、換個帳號卻被擋下的狀況。（參考：Google for Developers：Configure the OAuth consent screen and choose scopes）

建立網站用的 Client ID

接著建立「網頁應用程式」類型的 OAuth 用戶端。這裡最容易填錯的是「已授權的 JavaScript 來源」：它要填網站實際執行的來源，包含 https://、網域，若是本機開發還要對上埠號，例如 http://localhost:5173。不用把 /login 之類的頁面路徑一起貼進去。正式網站應使用 HTTPS；下面的舊截圖還留著 HTTP 範例，請看欄位位置就好，網址不要照抄。（參考：Google for Developers：JavaScript quickstart）

Client ID、Client Secret，差在哪裡？

這兩個名字很像，但不用一起塞進前端。Client ID 是應用程式的識別資訊，瀏覽器端的 Google 授權流程會用到它。使用者登入並同意之後，程式才會取得有期限的 Access Token，拿這個 Token 去呼叫 Sheets API。Client ID 本身不能拿來讀別人的私人表格。（參考：Google for Developers：JavaScript quickstart）

Client Secret 是後端流程可能用到的機密。如果架構需要它，就只能留在後端；不能放到前端程式，也不要提交到 Git。Google 的瀏覽器 JavaScript 範例使用 Client ID，沒有要求把 Client Secret 放到網頁裡。（參考：Google for Developers：JavaScript quickstart）

還有一個容易漏掉的地方：授權範圍。網站只要讀取，就別先要求寫入；Google 也建議只要求功能真正需要的權限。在讓別人授權以前，要先看清楚畫面上實際要求了什麼。（參考：Google for Developers：Configure the OAuth consent screen and choose scopes）

網站是誰在讀表格？
上面這種瀏覽器授權，讀取的是「登入者本來就有權限」的試算表。如果你想讓所有訪客看到同一份不公開的表格，不能只把自己的 Client ID 放在前端；需要另外設計後端存取與網站自己的權限規則。

試算表什麼時候不夠用？

我會先看資料怎麼用。如果只是幾十筆活動、作品或課程資訊，試算表很好改，也方便請不寫程式的夥伴一起維護。以前做圖表時，我看上的也是這一點。

但如果開始有大量使用者同時寫入、每人只能改自己的資料，或是訂單和庫存不能互相覆蓋，就該評估正式資料庫。不是試算表不能用了，而是需求已經變成另一個等級。

先挑一份確定可以公開的小資料做練習，讓網站讀出第一張卡片。等你要處理私人資料，再回來走 Google 授權這條路。這樣比較容易知道每一步是在解決什麼問題。🙂

文章同步發表於 https://book.casper.tw/it2026/google-sheets-as-database