鸿蒙开发中 区分不同环境的配置

在开发中区分不同环境如开发、测试、生产的配置核心难点在于构建产物与配置的分离。针对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/prodtargets会变得臃肿。适用场景绝大多数项目尤其是只有 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 流水线项目。建议小团队/快速迭代选方案一Build Profile官方、稳定、够用。需要 CI/CD 自动打包不同环境选方案四Hvigor 脚本生成最干净。安全第一防逆向方案四或方案二千万别用方案三存明文。