如何使用GITHUB_TOKEN拉取私有Go包？解决权限失败问题

结论先行：完全可以用GITHUB_TOKEN代替PAT，不用再手动维护个人令牌，你遇到的报错是因为GITHUB_TOKEN的权限配置和认证方式没做对，下面是具体解决步骤：

问题根源 #

1. GITHUB_TOKEN默认只对当前工作流所在的仓库有读写权限，没法访问同组织下的其他私有仓库
2. 你用的全局Git替换配置，要么没正确传递令牌，要么和Go模块的缓存逻辑冲突，导致认证失败

具体解决步骤 #

1. 给GITHUB_TOKEN开跨仓库访问权限 #

在你的工作流YAML文件里，显式设置permissions，赋予读取私有仓库的权限：

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read  # 必须项，允许读取仓库内容
      packages: read  # 如果私有Go包是通过GitHub Packages发布的，需要加这个
    steps:
      - uses: actions/checkout@v4
      # 后续测试步骤

2. 优化Go模块的认证方式 #

别用全局Git配置替换，改用更适配Go模块的方案：

方案一：用.netrc配置认证

在测试脚本run-tests.sh里加一行：

echo "machine github.com login ${GITHUB_TOKEN} password x-oauth-basic" > ~/.netrc

同时在工作流里传递必要的环境变量：

- name: Run tests
  run: scripts/run-tests.sh
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    GO111MODULE: on
    GONOSUMDB: github.com/MyOrg/*  # 跳过私有仓库的sumdb校验，避免拉取失败

方案二：改用仓库级Git配置（兼容原有脚本）

如果想保留原来的Git替换逻辑，别用--global，只对当前仓库配置：

git config url.https://${GITHUB_TOKEN}@github.com/.insteadOf https://github.com/

全局配置容易和其他工具的认证逻辑冲突，仓库级配置更安全。

3. 清理Go模块缓存（可选但建议） #

如果之前用PAT拉过依赖，缓存里的旧认证信息可能干扰新令牌，加个清理步骤：

- name: Clear Go module cache
  run: go clean -modcache

额外权限检查 #

确保你的私有Go包仓库做了以下配置：

• 进入私有仓库 → 设置 → Actions → 通用
• 在「工作流权限」里选「读取仓库内容和包权限」
• 如果是组织内仓库，确保当前工作流所在的仓库（或所属团队）在私有Go包仓库的「协作和团队」里有「读取」权限

为什么用GITHUB_TOKEN更好 #

• 不用手动续期，GitHub自动生成临时令牌，工作流结束就失效
• 权限可以精确控制，避免PAT拥有过大的全局权限
• 泄露风险更低，临时令牌生命周期极短

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