Release 包为什么仍连着测试环境？

一个 App 同时有测试和生产服务，打正式包时加了 --release，并不意味着它一定连接生产后端。Release 决定构建模式，服务器地址仍由应用自己的配置选择。

这个 Flutter 项目使用构建参数选择后端，Android 和 iOS 脚本显式传入生产值。还要处理一种常见路径：命令行联调用过测试环境，随后直接从 Xcode 归档，生成配置中仍可能保留旧参数。

构建模式与后端环境，为什么要分别配置？

Flutter 构建模式区分 Debug、Profile 和 Release，分别用于开发、性能分析与发布。移动端开发中的 JIT、增量编译和发布时的 AOT，也是在决定编译执行方式，参见 Dart 平台说明。这些都不替项目选择服务器。

环境可以通过构建配置注入，避免打包前手动改请求地址、之后再改回来。项目用 APP_BACKEND_ENV，正式脚本分别执行：

flutter build apk --release --dart-define=APP_BACKEND_ENV=prod
flutter build ipa --release --dart-define=APP_BACKEND_ENV=prod

参数在 Dart 中由编译环境声明读取，不是运行时系统环境变量，见 Dart 编译环境声明。它会进入客户端产物，适合环境标识，不适合保存秘密。平台打包仍需要原生宿主、插件、资源、依赖和签名，Dart 编译完成只是其中一步。

两种策略都可选择。拒绝未知值能尽早暴露错误，默认值则能减少遗漏参数造成的中断，但也可能让拼写错误继续生成产物。

项目当前使用下面的选择规则：

因此未知值没有被全面拒绝。若以后改为构建失败，Dart 默认逻辑和平台检查要一起调整，构建记录也应能说明最终选中了哪个环境。

Flutter 联调后会生成 iOS 构建配置，其中可能残留 DART_DEFINES。仓库里的代码没有改地址，不等于本机生成配置没有测试值。

项目在 Flutter 构建脚本前增加检查阶段，解码逗号分隔的值，在精确的 Release、Profile 配置下发现 APP_BACKEND_ENV=dev 就失败退出。

这只覆盖指定配置名和 dev 值。新增自定义配置名称时要一起调整；参数缺失或未知值仍允许继续，由应用默认逻辑处理。它是针对残留测试参数的一道检查，尚未成为全面的环境参数校验。

两个平台脚本会清理生成状态再取依赖，Android 还清 Gradle，iOS 执行 pod install。这能减少旧构建状态干扰，但没有锁住全部 SDK、工具链、依赖和签名条件，因此不代表已经实现可复现构建。

签名或导出配置出错，也不是重新编译 Dart 就能解决。iOS 归档与 IPA 要分别检查：归档在 build/ios/archive/，IPA 在 build/ios/ipa/，见 iOS 构建与发布。项目脚本缺分发证书时先提示，构建后找不到 IPA 则按失败处理。

文件存在还没有验证安装、签名、版本、调试符号或实际后端。交付前应安装这次生成的包，核对版本与连接环境，并保存代码版本、模式、环境参数、工具版本和产物位置，保证后来排查的是同一份包。