一、今日學習目標

前面的開發已經完成 Discord /add 指令的建立、日期與時間格式驗證，以及 Google OAuth 2.0 授權流程。

然而，Discord 能夠接收使用者輸入的行程資料，不代表行程已經成功建立在 Google Calendar 中。

因此，這三天的主要目標是將 Discord 指令與 Google Calendar API 整合，讓使用者可以直接透過 Discord 建立 Google Calendar 行程，並加入必要的錯誤處理機制。

本次實作分為三個階段：

1. Day 23：建立 Google Calendar 新增事件功能
2. Day 24：整合 Discord /add 指令
3. Day 25：完整流程測試與錯誤處理

本文以整合流程整理實作重點。下方四張圖片沿用 2026/10/15（Day 20～22）的真實程式與操作紀錄，用來說明功能；不代表 Day 23～25 更新後版本已重新完成端到端驗收。

二、實作過程

Day 23：建立 Google Calendar 新增事件功能

首先需要確認 OAuth 2.0 授權流程已經完成，並且取得具有新增 Google Calendar 行程權限的 Access Token。

Access Token 是 Google 授權伺服器核發的存取憑證，程式可以使用它向 Google Calendar API 發送經授權的請求。

不過，成功取得 Access Token 不代表一定擁有新增行程的權限，還需要確認授權時所要求的 Scope。

完成授權後，就可以透過 Google Calendar API 的 events.insert() 方法新增事件。

新增事件需要提供以下資料：

• calendarId：指定要新增行程的日曆，例如 primary
• summary：行程標題
• start：行程開始時間
• end：行程結束時間
• start.timeZone 與 end.timeZone：行程使用的時區，例如 Asia/Taipei

其中，開始時間與結束時間必須使用 Google Calendar API 支援的日期時間格式，並正確處理時區。

這個階段先將新增事件的功能獨立建立，避免直接把所有 API 邏輯寫進 Discord 指令中，讓後續維護與測試更加容易。

圖一：新增事件服務與 events.insert() 呼叫位置（2026/10/15 程式畫面）。

Day 24：整合 Discord /add 指令

完成 Google Calendar 新增事件功能後，下一步就是讓 Discord 指令能夠呼叫這個功能。

前面已經完成 /add 指令，可以取得使用者輸入的標題、日期及時間，並進行基本格式驗證。

因此，這一天不需要重新建立整個指令，而是將原本已經完成的功能接到 Google Calendar API。

整體執行流程如下：

1. 使用者在 Discord 輸入 /add
2. Discord Bot 接收標題、日期與時間
3. 程式檢查日期與時間是否合法
4. 將資料轉換成 Google Calendar API 支援的格式
5. 透過已授權的 OAuth 2.0 用戶端發送新增事件請求
6. Google Calendar API 回傳執行結果
7. Discord Bot 根據結果回覆使用者

這裡需要特別注意，Discord Bot 不應該在 API 請求完成前就直接顯示新增成功。

因為指令資料通過驗證，只能代表輸入格式正確，無法保證 Google Calendar 已經成功建立行程。

必須等待 Google Calendar API 回傳成功結果，才能向使用者確認行程已新增。

此外，API 呼叫屬於非同步操作，可以使用 async/await 等待請求完成，並處理可能發生的錯誤。

圖二：Discord 顯示行程建立成功，包含標題、開始與結束時間及日曆連結（2026/10/15 操作紀錄）。

Day 25：完整流程測試與錯誤處理

完成整合後，最後一天的重點是確認整個功能能夠穩定執行。

除了測試正常新增行程，也需要考慮使用者輸入錯誤或 Google API 請求失敗時的情況。

本次測試規劃主要包含：

1. 正常輸入標題、日期及時間，確認行程成功新增
2. 輸入不存在的日期，確認程式能夠阻止錯誤資料
3. 輸入錯誤的時間格式，確認驗證機制正常運作
4. 模擬 Google Calendar API 請求失敗
5. 檢查授權失效或權限不足時的處理方式
6. 確認新增失敗時，Discord 不會顯示成功訊息
7. 確認行程建立後，Google Calendar 中的標題與時間正確

圖三：Google Calendar 中的同一筆測試行程，從 2026/10/20 23:30 到 10/21 00:30，使用 GMT+08:00 台北標準時間（2026/10/15 操作紀錄）。

在錯誤處理方面，可以使用 try...catch 捕捉 API 呼叫過程中的例外。

當 API 請求失敗時，程式應該記錄必要的錯誤資訊，並向 Discord 使用者回覆適當的訊息。

另外，也需要區分輸入驗證錯誤與 API 執行錯誤。

輸入驗證錯誤通常可以直接要求使用者修正資料，而 API 執行錯誤則可能與授權、網路連線、服務狀態或請求參數有關。

將不同類型的錯誤分開處理，可以讓程式更容易除錯，也能讓使用者清楚了解問題發生在哪個階段。

圖四：找不到指定日曆及 Google 授權無效時的錯誤回覆（2026/10/15 操作紀錄；圖中重新授權指令為當時版本）。

三、這三天的核心觀念

這次實作最重要的觀念，是了解 Discord Bot 與 Google Calendar API 之間的資料交換流程。

Discord 負責接收使用者指令，Node.js 程式負責處理輸入資料、驗證內容與發送 API 請求，而 Google Calendar 則負責實際儲存行程。

OAuth 2.0 的作用是提供授權機制，讓程式能夠在使用者允許的範圍內存取 Google Calendar。

整個流程可以整理為：

1. Discord 指令
2. Node.js 接收資料
3. 驗證日期與時間
4. 準備 Google Calendar 事件資料
5. 使用 OAuth 2.0 授權用戶端
6. 呼叫 Google Calendar API
7. Google Calendar 建立行程
8. API 回傳結果
9. Discord 顯示執行結果

透過這個架構，可以清楚區分每個部分的責任，讓後續增加查詢、修改或刪除行程功能時，不需要重新設計整個系統。

四、學習心得

這三天的開發重點，從原本的 Discord 指令處理，進一步延伸到外部 API 的實際操作。

在整合過程中，可以發現資料驗證、使用者授權及 API 請求其實是三個不同的階段。

即使 Discord 成功接收到使用者輸入的資料，也不代表 Google Calendar 已經建立行程。只有在完成授權、送出正確的 API 請求並取得成功結果後，才能確認整個操作完成。

另外，錯誤處理也是 API 整合中不可忽略的一部分。除了讓程式在正常情況下能夠運作，也需要考慮授權失效、輸入錯誤及請求失敗等狀況。

這次的實作讓我更清楚理解 Discord、Node.js、OAuth 2.0 與 Google Calendar API 之間的關係，也為後續的行程查詢與其他日曆管理功能建立基礎。

五、參考資料

1. Google Calendar API｜Create events
2. Google Calendar API｜Events: insert
3. Google Identity｜OAuth 2.0 for Desktop Applications
4. Discord.js Guide
5. Google APIs Node.js Client