actions/github-script中github.request()无法覆盖部分HTTP请求头

actions/github-script@v6中内置的github对象是预配置完成的Octokit客户端，默认绑定了当前工作流的GitHub Actions鉴权逻辑，同时内置了GitHub API专属的默认请求规则：

• 自动向所有请求注入当前工作流的GitHub Token作为authorization头，格式固定为token ghs_xxx
• 自动给所有请求加上GitHub API专属的accept头，默认值为application/vnd.github.-preview+json

这两个默认逻辑的优先级高于手动传入的headers配置，所以不管请求目标是不是GitHub API域名，这两个头都会被覆写。content-type和user-agent不在强制覆写范围内，所以手动设置的content-type能正常生效，user-agent是实例初始化时添加的默认值，不会被自动清除。

可以通过两种方式实现完全自定义请求头：

方案1：保留使用github.request，加配置关闭默认注入 #

在请求参数中添加两个配置项，跳过Octokit的默认鉴权和默认Accept头注入即可：

const response = await github.request('POST https://example.com', {
  // 关闭自动注入GitHub Token鉴权头
  auth: false,
  // 关闭默认GitHub专属Accept头注入
  mediaType: {
    default: false
  },
  headers: {
    authorization: 'Bearer xxx',
    accept: 'application/vnd.heroku+json; version=3',
    'content-type': 'application/json'
  },
  // 其余请求配置，比如通过data字段传递请求体
});
console.log(response);

该配置下传入的所有请求头都会原样发送，不会被自动修改。

方案2：用Node.js内置能力发请求，绕开Octokit拦截器 #

actions/github-script@v6的Node.js运行时版本为16.x，已经原生支持fetch API，可以直接用原生fetch发请求，完全不受Octokit默认规则影响：

const response = await fetch('https://example.com', {
  method: 'POST',
  headers: {
    authorization: 'Bearer xxx',
    accept: 'application/vnd.heroku+json; version=3',
    'content-type': 'application/json'
  },
  // 其余请求配置，比如通过body字段传递JSON.stringify序列化后的请求体
});
const result = await response.json();
console.log(result);

这种方式不需要记忆Octokit的特殊配置项，所有请求行为完全可控，适配性更强。

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