<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Doget on Tarragon</title><link>https://tarrragon.github.io/blog/tags/doget/</link><description>Recent content in Doget on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Mon, 06 Jul 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/doget/index.xml" rel="self" type="application/rss+xml"/><item><title>doGet / doPost</title><link>https://tarrragon.github.io/blog/automation/knowledge-cards/doget-dopost/</link><pubDate>Mon, 06 Jul 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/automation/knowledge-cards/doget-dopost/</guid><description>&lt;p>&lt;code>doGet&lt;/code> 與 &lt;code>doPost&lt;/code> 是 Apps Script web app 的兩個進入點函式：端點收到 GET 請求時平台呼叫 &lt;code>doGet(e)&lt;/code>，收到 POST 請求時呼叫 &lt;code>doPost(e)&lt;/code>。它們是 &lt;a href="https://tarrragon.github.io/blog/automation/knowledge-cards/web-app-deployment/" data-link-title="Web App Deployment（Web App 部署）" data-link-desc="把 Apps Script 專案掛成一個有公開網址、可被任何 HTTP 請求呼叫的端點時的部署模型與存取設定">web app 部署&lt;/a>後對外行為的定義處——寫什麼在裡面，端點被呼叫時就執行什麼。參數 &lt;code>e&lt;/code> 帶著請求內容：&lt;code>doGet&lt;/code> 從 &lt;code>e.parameter&lt;/code> 拿 query string，&lt;code>doPost&lt;/code> 從 &lt;code>e.postData.contents&lt;/code> 拿請求主體。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>事件物件只帶請求的內容，&lt;strong>不帶任何 HTTP 標頭&lt;/strong>——&lt;code>User-Agent&lt;/code> 與來源 IP 在這裡都讀不到。伺服器端常見的 UA 比對與 IP 判斷因此不可用，需要那些資訊時只能由前端蒐集後放進請求主體送來（見&lt;a href="https://tarrragon.github.io/blog/automation/06-reading-the-data/automated-traffic/" data-link-title="辨識自動化流量" data-link-desc="接收端讀不到 HTTP 標頭時在前端蒐集訊號分辨機器與真人；多數 AI 訓練爬蟲不執行 JavaScript，因此不會出現在這份統計裡">辨識自動化流量&lt;/a>）。&lt;/p>
&lt;p>兩個函式都必須回傳一個 &lt;code>ContentService&lt;/code> 或 &lt;code>HtmlService&lt;/code> 的輸出，這是平台的硬性要求；不回傳會被當成執行沒有正常結束。接收 &lt;a href="https://tarrragon.github.io/blog/automation/knowledge-cards/beacon/" data-link-title="Beacon" data-link-desc="瀏覽器在頁面事件發生時主動送出、送出後不等回應的一則事件回報請求，用於靜態站把資料回傳給接收端">beacon&lt;/a> 這類「送資料進來」的場景用 &lt;code>doPost&lt;/code>，因為 &lt;code>sendBeacon&lt;/code> 送的是 POST，主體放在 &lt;code>e.postData.contents&lt;/code>（是個字串，需要自己 &lt;code>JSON.parse&lt;/code>）。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>一個影響靜態站的關鍵限制是：Apps Script &lt;strong>沒有&lt;/strong> &lt;code>doOptions&lt;/code>。跨網域請求的 CORS preflight 會送 &lt;code>OPTIONS&lt;/code>，但它打不到你的程式、平台的預設回應也不帶 CORS 許可標頭，於是 preflight 失敗、真正的請求送不出去。&lt;/p>
&lt;h2 id="判讀方式">判讀方式&lt;/h2>
&lt;p>這是「用 &lt;code>fetch&lt;/code> 送 &lt;code>application/json&lt;/code> 打 Apps Script 得到 CORS 錯誤」的根因，繞法是讓請求成為不觸發 preflight 的 simple request，見&lt;a href="https://tarrragon.github.io/blog/automation/02-analytics-beacon/frontend-beacon/" data-link-title="前端 beacon 與 CORS 障礙" data-link-desc="靜態站用瀏覽器送瀏覽事件到 Apps Script 時，為什麼要用 sendBeacon 送 text/plain 才不會被 CORS preflight 擋下">前端 beacon 與 CORS 障礙&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p><code>doGet</code> 與 <code>doPost</code> 是 Apps Script web app 的兩個進入點函式：端點收到 GET 請求時平台呼叫 <code>doGet(e)</code>，收到 POST 請求時呼叫 <code>doPost(e)</code>。它們是 <a href="/blog/automation/knowledge-cards/web-app-deployment/" data-link-title="Web App Deployment（Web App 部署）" data-link-desc="把 Apps Script 專案掛成一個有公開網址、可被任何 HTTP 請求呼叫的端點時的部署模型與存取設定">web app 部署</a>後對外行為的定義處——寫什麼在裡面，端點被呼叫時就執行什麼。參數 <code>e</code> 帶著請求內容：<code>doGet</code> 從 <code>e.parameter</code> 拿 query string，<code>doPost</code> 從 <code>e.postData.contents</code> 拿請求主體。</p>
<h2 id="概念位置">概念位置</h2>
<p>事件物件只帶請求的內容，<strong>不帶任何 HTTP 標頭</strong>——<code>User-Agent</code> 與來源 IP 在這裡都讀不到。伺服器端常見的 UA 比對與 IP 判斷因此不可用，需要那些資訊時只能由前端蒐集後放進請求主體送來（見<a href="/blog/automation/06-reading-the-data/automated-traffic/" data-link-title="辨識自動化流量" data-link-desc="接收端讀不到 HTTP 標頭時在前端蒐集訊號分辨機器與真人；多數 AI 訓練爬蟲不執行 JavaScript，因此不會出現在這份統計裡">辨識自動化流量</a>）。</p>
<p>兩個函式都必須回傳一個 <code>ContentService</code> 或 <code>HtmlService</code> 的輸出，這是平台的硬性要求；不回傳會被當成執行沒有正常結束。接收 <a href="/blog/automation/knowledge-cards/beacon/" data-link-title="Beacon" data-link-desc="瀏覽器在頁面事件發生時主動送出、送出後不等回應的一則事件回報請求，用於靜態站把資料回傳給接收端">beacon</a> 這類「送資料進來」的場景用 <code>doPost</code>，因為 <code>sendBeacon</code> 送的是 POST，主體放在 <code>e.postData.contents</code>（是個字串，需要自己 <code>JSON.parse</code>）。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>一個影響靜態站的關鍵限制是：Apps Script <strong>沒有</strong> <code>doOptions</code>。跨網域請求的 CORS preflight 會送 <code>OPTIONS</code>，但它打不到你的程式、平台的預設回應也不帶 CORS 許可標頭，於是 preflight 失敗、真正的請求送不出去。</p>
<h2 id="判讀方式">判讀方式</h2>
<p>這是「用 <code>fetch</code> 送 <code>application/json</code> 打 Apps Script 得到 CORS 錯誤」的根因，繞法是讓請求成為不觸發 preflight 的 simple request，見<a href="/blog/automation/02-analytics-beacon/frontend-beacon/" data-link-title="前端 beacon 與 CORS 障礙" data-link-desc="靜態站用瀏覽器送瀏覽事件到 Apps Script 時，為什麼要用 sendBeacon 送 text/plain 才不會被 CORS preflight 擋下">前端 beacon 與 CORS 障礙</a>。</p>
]]></content:encoded></item></channel></rss>