相同凭据下Octokit构造函数报错但App类正常的原因是什么

第一种写法的运行逻辑 #

new App()是octokit提供的高层封装实例，调用getInstallationOctokit(installationId)时内部已经把所有认证相关的边界逻辑都处理完了：

• 自动做参数类型转换、格式校验：比如把环境变量读出来的字符串格式App ID转成数字，自动处理私钥里的换行转义问题
• 自动生成符合GitHub规范的App级JWT，自动填充iss（签发人，值为App ID）等必填字段
• 自动拿JWT兑换对应安装ID的Installation访问令牌，还内置了令牌过期自动刷新的逻辑
• 最后用拿到的有效令牌初始化Octokit实例返回，后续发请求直接带合法令牌，自然不会报认证错误。

第二种写法报错的原因 #

你直接用底层Octokit类搭配createAppAuth的写法，是直接调用最底层的基础组件，没有高层封装的默认处理逻辑：

• 最直接的触发点是参数类型问题：环境变量读出来的值默认都是字符串，多数版本的createAppAuth不会自动把字符串格式的App ID转成数字，识别不到合法App ID的情况下，生成JWT时就不会写入iss字段，直接触发你看到的Missing 'issuer' claim401错误。
• 就算你把App ID转成数字修了JWT生成问题，这种写法也不会自动帮你兑换Installation令牌：createAppAuth是动态认证策略，会根据请求的接口路径自动选择认证身份，你就算在初始化时传了installationId，也不会默认让所有请求走安装身份，调用/apps开头的接口时它还是会尝试生成App级JWT，很容易出现身份不匹配的问题。
• 另外你贴的代码还有个手滑的bug：getAuthenticated()接口返回的响应里只有data字段，没有data2，就算认证通过了也会触发解构报错。

第二种写法的修正方案 #

如果一定要直接用底层Octokit+createAppAuth实现，得显式走令牌兑换流程，不要指望auth策略自动判断你需要的身份类型：

const auth = createAppAuth({
  appId: Number(process.env.GITHUB_APP_ID),
  privateKey: process.env.GITHUB_APP_PRIVATE_KEY,
  installationId: Number(process.env.GITHUB_APP_INSTALLATION_ID),
});
// 显式指定要获取installation类型的凭证
const { token } = await auth({ type: "installation" });
const octokit2 = new Octokit({ auth: token });

// 修正解构写法
const { data: data2 } = await octokit2.rest.apps.getAuthenticated();

平时写业务直接用new App()的高层封装就行，不用自己处理认证流程里的各种细碎问题，省很多事。

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