Galaxy 应用配置基线
基本结论
Galaxy 应用的入口工程通常会同时维护三组资源：
@conf：开发调试阶段使用的配置资源@install：发布安装包使用的配置和静态资源@profiles：功能菜单和应用设置相关资源
其中，@conf 和 @install 不属于同一个映射层级，不能简单地理解为“开发版”和“正式版的同目录镜像”。
目录映射规则
@conf
@conf 对应 Galaxy 应用主目录下 conf/ 的根目录。
也就是说，在开发调试阶段，@conf/server.conf、@conf/mongo.db.conf、@conf/organizations.conf 等文件，会以 conf/*.conf 的形式进入运行时主目录。
@install
@install 对应的是 Galaxy 应用主目录根。
它内部再按发布目录结构继续分层：
@install/conf对应应用主目录下的conf/@install/web对应应用主目录下的web/
因此，@install 不是简单替代 @conf，而是用于描述“最终安装包长什么样”。
推荐理解方式
可以把 Galaxy 应用配置理解为两套不同目标的配置资产：
- 开发态配置：让应用在 IDE、本地调试、联调环境里尽快跑起来
- 安装态配置：让最终发布到运行环境的应用目录具有可部署的目录结构
这两套资产的关注点并不相同：
- 开发态更偏向本机端口、调试域名、联调数据库、调试开关
- 安装态更偏向部署目录、多域名资源、对外访问域名、稳定的安装布局
配置覆盖原则
@conf 和 @install 目录中的配置覆盖原则是一致的：
- 不做文件夹整体覆盖
- 按同名文件覆盖
- 平台保留一组不可覆盖的受保护配置文件，具体清单应在后续治理中继续补齐
这意味着：
- 不要假设拷贝一个目录就可以整体替换运行时内容
- 真正稳定的覆盖单位是文件
- 配置治理时应优先管理“关键文件列表”，而不是只管理目录名
配置能力域
Galaxy 应用配置至少可以划分为以下能力域：
- 目录与发布布局
- 服务器网络接入
- 账号与登录注册
- 安全与认证
- 组织机构
- 角色与权限
- Web 与静态资源
- 多域名应用
- MongoDB 与 RocksDB 存储
- 文件服务
- 区块链接入
使用要点
- 把
@conf当作“开发联调入口”，而不是长期运维配置的唯一来源 - 把
@install当作“安装包目录声明”，确保conf/与web/结构完整
