在开发中，区分不同环境（如开发、测试、生产）的配置，核心难点在于构建产物与配置的分离。针对 debug 和 release 以及可能的更多环境，梳理了4种主流方案，从轻量级到企业级，利弊根据团队规模选择。

方案一：基于 Build Profile 的字段注入（最推荐，原生支持）

这是鸿蒙官方推荐的方案，利用 build-profile.json5 中的 buildOption 和 arkOptions，配合 process.env 在编译时注入变量。

• 做法：在 build-profile.json5 的 targets 中定义 debug 和 release，并在 buildOption 中配置 buildProfileFields 注入全局常量。

• 优点：原生支持，无需第三方库；编译时确定，运行时无性能损耗；可以精确控制每个 target 的配置。

• 缺点：配置写法略繁琐；如果环境超过3个（如dev/sit/uat/prod），targets 会变得臃肿。

• 适用场景：绝大多数项目，尤其是只有 dev 和 prod 两套环境时。

方案二：多 Bundle Name / 多 Module 方案（物理隔离）

为不同环境创建独立的 Module 或使用不同的 bundleName（包名），每个模块持有自己的 constants 文件。

• 做法：创建 common-debug 和 common-release 两个 hap 模块，或者利用 HAP 的 target 能力，替换 ets 目录下的配置文件。

• 优点：绝对的物理隔离，即使写错代码也不会混淆；适合大型多人协作项目。

• 缺点：维护成本高，公共代码修改时需要同步多个模块；切换环境需要重新安装应用（因为包名不同）。

• 适用场景：系统级应用 或 有严格安全审计要求 的项目。

方案三：运行时动态读取本地配置文件（JSON/Properties）

将不同环境的 Host 写在 rawfile 目录下的多个 JSON 文件中（如 config.dev.json），通过代码逻辑判断当前是 Debug 还是 Release 模式来读取对应文件。

• 做法：通过 @ohos.bundle.bundleManager 获取应用的 bundleInfo，判断 debug 字段；或者通过 AppStorage 在启动时设置一个全局环境变量。

• 优点：配置修改灵活，甚至可以热更新配置（如果从远端拉取）；代码逻辑直观。

• 缺点：配置文件会打包进应用，如果反编译，所有环境的 Host 都会暴露（安全风险）；需要额外的文件读取 I/O 操作。

• 适用场景：内部测试包 或 对 IP 泄露不敏感 的 Demo 项目。

方案四：基于 AGP/Hvigor 构建脚本生成配置文件（最自动化）

利用鸿蒙的构建工具 Hvigor，在 hvigorfile.ts 中编写自定义 Task。在编译打包前，根据当前的 product 或 target，动态生成一个 Config.ets 文件写入到 entry/src/main/ets/ 目录下。

• 做法：构建时读取环境变量（如 npm run build:dev），脚本往源码目录写入 export const BASE_URL = "https://dev.api.com"。

• 优点：零运行时开销，配置被直接编译进字节码；且构建产物中只有当前环境的 Host。

• 缺点：对团队成员要求较高（需理解 Hvigor 脚本）；如果误操作，容易把开发环境的配置覆盖到正式版。

• 适用场景：成熟的 CI/CD 流水线 项目。

建议

1. 小团队/快速迭代：选 方案一（Build Profile），官方、稳定、够用。

2. 需要 CI/CD 自动打包不同环境：选 方案四（Hvigor 脚本生成），最干净。

3. 安全第一（防逆向）：方案四 或 方案二，千万别用方案三（存明文）。