GitLab Runner构建Flutter Linux桌面应用的flutter_dotenv环境变量问题

在受控环境下用GitLab Runner构建Flutter桌面应用时，动态生成.env文件是完全可行且符合最佳实践的方案，不用纠结是否该由Runner负责生产环境的配置生成——这正是CI/CD流程管理环境配置的标准做法。以下是具体实现思路和优化建议：

核心方案：用GitLab CI变量+动态生成.env #

1. 把环境配置存在GitLab CI变量中 #

在项目的Settings > CI/CD > Variables页面，按环境（prod/test）分别存储敏感或环境专属的配置项，比如：

• 生产环境：PROD_API_URL、PROD_APP_KEY
• 测试环境：TEST_API_URL、TEST_APP_KEY
• 给敏感变量勾选Masked（隐藏输出）和Protected（仅在受保护分支生效），避免配置泄露。

2. 在CI脚本中动态生成.env文件 #

直接在.gitlab-ci.yml的构建阶段添加生成.env的命令，确保Flutter构建前文件存在。示例配置：

stages:
  - build

# 生产环境构建
build_prod:
  stage: build
  only:
    - main  # 仅在主分支触发
  script:
    # 生成生产环境.env
    - echo "API_URL=$PROD_API_URL" > .env
    - echo "APP_ENV=production" >> .env
    - echo "APP_KEY=$PROD_APP_KEY" >> .env
    # 执行Flutter构建
    - flutter build linux --release
    # 上传构建产物到GitLab Packages
    - <你的上传命令，比如用curl或GitLab CI内置工具>

# 测试环境构建
build_test:
  stage: build
  only:
    - test  # 仅在测试分支触发
  script:
    # 生成测试环境.env
    - echo "API_URL=$TEST_API_URL" > .env
    - echo "APP_ENV=testing" >> .env
    - echo "APP_KEY=$TEST_APP_KEY" >> .env
    - flutter build linux --release
    - <你的上传命令>

3. 优化：抽离生成逻辑到脚本（可选） #

如果环境配置项较多，可把生成.env的逻辑抽成单独的shell脚本（比如generate_env.sh），放在项目根目录：

#!/bin/bash
# generate_env.sh

case "$CI_COMMIT_BRANCH" in
  main)
    echo "API_URL=$PROD_API_URL" > .env
    echo "APP_ENV=production" >> .env
    echo "APP_KEY=$PROD_APP_KEY" >> .env
    ;;
  test)
    echo "API_URL=$TEST_API_URL" > .env
    echo "APP_ENV=testing" >> .env
    echo "APP_KEY=$TEST_APP_KEY" >> .env
    ;;
esac

然后在CI脚本中调用：

script:
  - chmod +x generate_env.sh
  - ./generate_env.sh
  - flutter build linux --release
  - <上传命令>

为什么这是合理的最佳实践？ #

• 配置与代码分离：生产环境的敏感配置不会出现在代码仓库中，避免泄露风险；
• 环境隔离清晰：不同环境的配置仅在CI层面管理，不用修改代码或维护多份.env文件；
• 符合flutter_dotenv的设计初衷：文档要求.env加入.gitignore，动态生成正好满足这一点，同时解决构建时文件缺失的问题。

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