Google Web App仅通过浏览器访问时生成日志的异常问题排查

核心现象 #

隐私窗口直接访问URL时，doGet正常触发且日志可见；但通过同标签页Fetch API（偶尔无日志）、Postman或Klavio发送请求时，POST请求从未生成日志，部分执行记录显示"已完成"却无法展开、无内容，所有请求均返回200状态码。

可能原因及解决方法 #

1. 日志与执行记录的延迟/缓存 #

Apps Script的日志和执行记录并非实时同步，外部请求触发的执行可能存在5-10分钟的延迟；部分执行记录会因Google缓存机制暂时无法展开，并非真的无日志。

• 解决：等待10分钟后刷新执行记录页面，不要立即查看。

2. POST请求参数解析问题 #

你的doPost直接输出JSON.stringify(e)，但如果请求的Content-Type不匹配（比如未设为application/json或表单格式），e.postData或e.parameter可能为空，导致日志输出空内容，看起来像无日志；Postman/Klavio若未正确设置请求头或参数格式，也会导致e对象无有效数据。

• 解决：
  优化doPost的日志输出逻辑，明确打印关键信息：

  function doPost(e) {
    Logger.log("POST请求触发");
    Logger.log("Content-Type: " + e.contentType);
    if (e.postData && e.postData.contents) {
      Logger.log("POST内容: " + e.postData.contents);
    } else {
      Logger.log("无有效POST数据");
    }
    return HtmlService.createHtmlOutput('<h1>Thanks for using Apps Scripts</h1>');
  }
  

  Postman测试时，设置Content-Type为application/json，并在Body中填写JSON格式数据；或使用x-www-form-urlencoded格式传参。

3. CORS预请求（OPTIONS）未处理 #

浏览器跨域Fetch请求会先发送OPTIONS预请求，若Web App未处理该请求，Google会默认返回200，但不会触发doGet/doPost——你看到的200可能是预请求的返回，而非实际业务请求的执行结果。

• 解决：
  添加doOptions函数处理预请求，并在doGet/doPost的返回中加入CORS头：

  function doOptions(e) {
    return HtmlService.createHtmlOutput("")
      .setHeaders({
        "Access-Control-Allow-Origin": "*",
        "Access-Control-Allow-Methods": "GET, POST, OPTIONS",
        "Access-Control-Allow-Headers": "Content-Type"
      });
  }
  
  function doGet(e) {
    Logger.log("GET");
    Logger.log(JSON.stringify(e))
    return HtmlService.createHtmlOutput('<h1>Thanks for using Apps Scripts</h1>')
      .setHeaders({"Access-Control-Allow-Origin": "*"});
  }
  
  function doPost(e) {
    Logger.log("POST");
    Logger.log(JSON.stringify(e))
    return HtmlService.createHtmlOutput('<h1>Thanks for using Apps Scripts</h1>')
      .setHeaders({"Access-Control-Allow-Origin": "*"});
  }
  

4. Web App部署设置异常 #

若部署时未选择"任何人，甚至匿名"访问权限，Postman/Klavio的无认证请求会被静默处理（返回200但不执行脚本）；若修改代码后未重新部署新版本，旧脚本也不会应用新的日志逻辑。

• 解决：
  重新部署Web App，确认访问权限设为"任何人，甚至匿名"，并选择"创建新版本"，使用新生成的部署URL测试。

5. 日志输出限制 #

Logger.log存在内容大小限制，若e对象过大（如POST数据量多），日志会被截断或不显示；外部请求触发的执行，Logger日志同步可能不稳定。

• 解决：
  避免直接输出完整e对象，只打印关键字段（如e.parameter、e.postData.type）；或用临时存储验证请求是否被接收：

  function doPost(e) {
    PropertiesService.getScriptProperties().setProperty("last_post_request", JSON.stringify(e));
    Logger.log("POST请求已记录");
    return HtmlService.createHtmlOutput('<h1>Thanks for using Apps Scripts</h1>');
  }
  

  之后在脚本编辑器中通过PropertiesService.getScriptProperties().getProperty("last_post_request")查看请求数据。

验证步骤 #

1. 重新部署Web App，确保为最新版本且权限为"任何人，甚至匿名"；
2. 用Postman发送设置好Content-Type的POST请求，等待10分钟后查看执行记录；
3. 添加CORS处理逻辑后，用跨域Fetch请求测试日志是否正常生成。

内容的提问来源于stack exchange，提问作者fweth