API key 與認證 header
大多數有用的 並不對全世界開放。公司需要知道是誰在提問，這樣他們才能統計用量並向你收費。他們會給你一個 API key——一長串能標識你賬戶的金鑰字串。你把它附在每個請求上，通常放在一個叫 Authorization 的 header 裡，就像上面那行 Bearer sk_live_...。
把 API key 完全當成密碼來對待，因為它本來就是密碼。任何拿到它的人都能以你的身份發請求——並刷爆你的賬單或讀走你的資料。這直接關聯到安全那一章，而其中最重要的有一條規則：
- **絕不要把 API key 放進會發到瀏覽器裡的程式碼。**你前端裡的任何東西都是公開的——使用者可以開啟開發者工具讀到它。AI 被要求"從頁面裡呼叫 API"時，會樂呵呵地把你的金鑰直接貼在那兒。攔住它。金鑰屬於伺服器。
- **絕不要把 key 提交進 。**就算你之後刪掉它，它也會永遠活在歷史記錄裡，而機器人會在幾分鐘內掃描公開倉庫裡的 key。
- 把 key 存在環境變數裡，而不是程式碼本身裡——這和安全那一章講的是同一個模式。
key 必須從一個安全的地方出發，絕不能從瀏覽器出發。設想一下這兩條路——一條安全，一條洩露：
安全 ✓ 洩露 ✗
┌──────────┐ key ┌──────────┐ ┌──────────┐ key ┌──────────┐
│ 伺服器 │ ───▶ │ API │ │ 瀏覽器 │ ──▶ │ API │
│ (你的 │保密 │ │ │ (任何人 │ │ │
│ 後端) │ │ │ │ 都能 │ │ │
└──────────┘ └──────────┘ │ 看到) │ └──────────┘
key 在環境變數裡 └──────────┘
前端裡的 key = 公開
如果你哪天看到一個真實的 key 出現在一段 diff 裡、一個前端檔案裡、或一條聊天訊息裡，就把它當成已經洩露了：立刻輪換它（生成一個新的，停用舊的）。