开发配置与发布配置的目录映射
典型样例
以 digital-platform-server 为例，Galaxy 应用的入口工程同时包含：
digital-platform-server/ # 入口工程(gapp)
├── @conf/
├── @install/
│ ├── conf/
│ └── web/
└── @profiles/
这套结构可以直接作为 Galaxy 应用配置布局的参考模板。
开发调试阶段
开发调试阶段重点看 @conf。
常见文件包括：
server.confmongo.db.confdomains.confdomains.mongo.db.conforganizations.confroles.conf- 业务扩展配置，例如
emall.conf
这套配置的作用是让应用在本地或开发环境中完成启动、登录、调试和联调。
发布安装阶段
发布安装阶段重点看 @install。
其结构不是“另一个配置目录”，而是“安装包目录的映射源”：
@install/conf/*用于生成安装目录中的conf/*@install/web/*用于生成安装目录中的web/*
在 digital 项目里，@install/web/domains/*/application.json 还提供了多域名场景下的站点级静态配置样例。
不对等映射是设计重点
这一点最容易误解。
@conf 直接映射到 conf/ 根，而 @install 直接映射到应用主目录根，所以：
@conf/server.conf的对标位置是运行时conf/server.conf@install/conf/server.conf的对标位置也是安装后的conf/server.conf@install/web/domains/...的对标位置则是安装后的web/domains/...
因此，@conf 与 @install 不是一一对应的平级目录树。
资源映射由项目模板统一定义
@conf、@install、@profiles 与安装目录之间的资源映射，通常由 Galaxy 项目模板在创建入口工程时统一定义。
对应用开发者而言，日常工作的重点是维护这些目录中的实际配置文件和静态资源，而不是手工改写 pom.xml 中的资源映射。
只有在排查历史工程、模板漂移或发布结果异常时，才需要回到入口工程的 pom.xml 与发布插件配置继续核对。
常见整理方式
建议按以下方式理解并维护不同目录中的配置资源：
- 开发联调配置：只在
@conf管理 - 安装部署配置：只在
@install/conf、@install/web管理 - 跨阶段共享的配置规则：通过统一文档说明，不直接复制文件内容
变更时的检查清单
- 新增配置文件时，先确认它属于开发态还是安装态
- 如果配置项既要开发态生效，也要安装态生效，应分别维护
@conf与@install/conf的同名文件 - 如果配置与站点静态资源或域名品牌化相关，应优先检查
@install/web - 不要把
@conf的目录结构机械复制到@install
相关AI skills
galaxy-app-configgalaxy-app-config-layoutgalaxy-app-config-publish-layout
