如何向GitHub Action传递可查看调试的环境变量

这类非敏感、需要fork后方便修改的配置，完全不需要用Secrets存储，以下三种方案都能满足可直接查看、运行时不脱敏、调试方便、fork后易调整的需求：

• 方案1：直接在Workflow文件内定义环境变量
  这是最轻量的用法，环境变量明文写在.github/workflows/目录下的工作流配置文件中，支持全局、单作业、单步骤三个作用域，运行时不会被掩码，可直接在日志中打印查看，fork后直接编辑对应yml文件即可修改配置。
  配置示例：

name: 项目构建工作流
on: [push, pull_request]
# 全局变量：当前工作流下所有作业、步骤都可调用
env:
  NODE_VERSION: 20
  DIST_PATH: ./build
  PUBLIC_API_HOST: "https://demo-api.example.com"
jobs:
  build:
    runs-on: ubuntu-latest
    # 作业级变量：仅当前build作业下的步骤可调用
    env:
      BUILD_TARGET: "web"
    steps:
      - uses: actions/checkout@v4
      - name: 安装依赖
        run: npm ci
      # 步骤级变量：仅当前执行步骤可调用
      - name: 执行构建
        env:
          GENERATE_SOURCEMAP: "true"
        run: npm run build

变量调用方式和Secrets一致，既可以在workflow语法中通过${{ env.变量名 }}引用，也可以在shell脚本中直接通过$变量名读取。

• 方案2：独立配置文件存储批量变量
  如果配置项较多，不想全部堆砌在workflow文件中，可以在仓库根目录（或任意固定路径）创建明文的env配置文件，提交到仓库中，工作流运行时先加载该文件为环境变量即可。
  比如创建project.env配置文件：

# 构建相关配置
BUNDLE_ANALYZE=false
API_TIMEOUT=8000
ENABLE_NEW_FEATURE=true

在workflow中添加加载步骤即可读取所有配置：

steps:
  - uses: actions/checkout@v4
  - name: 加载仓库内配置文件为环境变量
    run: cat project.env >> $GITHUB_ENV
  # 后续步骤可直接调用所有配置项
  - name: 打印配置调试
    run: |
      echo "当前接口超时配置：$API_TIMEOUT"
      echo "新功能开关状态：$ENABLE_NEW_FEATURE"

这种方式配置集中独立，fork的使用者不需要梳理工作流逻辑，直接修改这个独立配置文件即可调整参数，调试时直接查看文件内容就能看到全量配置，维护成本更低。

• 方案3：使用GitHub官方提供的Actions Variables功能
  GitHub本身就区分了加密的Secrets和明文的Variables两个配置存储入口，Variables专门用来存放非敏感配置：入口在仓库Settings -> Secrets and variables -> Actions -> Variables标签页。
  这里存储的变量不会被日志掩码，可正常打印调试，同时可以勾选「Allow this variable to be used in workflows from forks」选项，允许来自fork的PR工作流读取变量值。注意fork出去的仓库默认不会同步原仓库的Variables配置，fork的使用者需要在自己的仓库Settings中自行配置对应变量，相比前两种把配置存在代码里的方案，这种方式的fork修改成本稍高。

注意：以上所有方案仅适用于存放非敏感配置，包括但不限于公开接口地址、构建参数、版本号、功能开关等；账号密码、API Token、私钥等敏感信息必须存储在Secrets中，禁止明文提交到仓库。

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