通过composer的scripts功能可实现配置文件自动化生成。1. 在composer.json中定义post-install-cmd和post-update-cmd钩子执行生成脚本；2. 创建generate-config.php读取环境变量或模板文件；3. 使用str_replace填充占位符并写入目标文件；4. 确保权限为600并忽略敏感文件于.gitignore，避免覆盖已有配置。
Composer 本身不生成应用级配置文件，也不支持运行时动态切换环境配置；所谓“生成文件”靠的是 scripts 钩子 + 自定义 PHP 脚本，“动态配置环境”实际是靠环境变量注入 + 配置文件模板替换，不是 Composer 自身能力。
post-install-cmd 脚本怎么触发生成 config.php 或 .env
它只在 composer install（非 update）后自动执行，适合首次部署或本地初始化：
- 必须在
composer.json的scripts段里显式注册，例如："post-install-cmd": ["php scripts/generate-config.php"] - 脚本路径要可读，且 PHP CLI 环境能执行（Windows 下注意
.php关联和扩展启用） - 如果目标文件（如
.env）已存在，脚本应主动跳过或报错退出，否则会覆盖已有配置 - CI/CD 中若需每次构建都生成，得额外加
post-update-cmd，否则composer update不会触发
如何用环境变量填充模板生成配置
硬编码值进脚本极不安全，推荐用 .env.example 或 config.php.dist 做模板，再用 str_replace() 替换占位符：
- 模板中用
{DB_HOST}、{APP_KEY}这类大括号包裹的标记，避免和 PHP 语法冲突 - 脚本里用
getenv('DB_HOST') ?: 'localhost'获取值，未设置时提供合理默认值 - 敏感字段（如
DB_PASS）绝不设默认值，缺失时应exit(1)中断，防止静默生成空密码 - 生成后立即调用
chmod 600 $targetFile（PHP 中用chmod($file, 0600)），尤其对.env
composer config 命令能“动态”改哪些配置
composer config 只修改磁盘上的 composer.json 或 auth.json，所有操作都落盘，所谓“动态”只是免去手动编辑 JSON：
- 项目级配置：如
composer config process-timeout 600会写入composer.json的config段 - 全局镜像：用
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，影响后续所有新项目 - 凭据必须走
--auth：如composer config --auth http-basic.repo.example.com user token，否则写进composer.json会泄露 - 删配置用
--unset：如composer config --unset repositories.packagist，点号路径拼错会导致静默失败
COMPOSER_AUTH 和 COMPOSER_HOME 怎么影响运行时行为
这两个环境变量绕过文件读取，是真正“不落盘”的运行时控制方式：
-
COMPOSER_AUTH是 JSON 字符串，内容等效于auth.json，例如：export COMPOSER_AUTH='{"http-basic":{"repo.example.com":{"username":"u","password":"p"}}}'—— CI 中用 secret 注入最安全 -
COMPOSER_HOME决定auth.json和全局config.json存哪，CI 多 job 共享机器时必须隔离，否则凭据互相污染，典型做法是COMPOSER_HOME=/tmp/composer-$CI_JOB_ID - 它们只影响 Composer 自身行为（如鉴权、缓存路径），对项目生成的
.env或config/app.php完全无感 - 改了这两个变量后，必须新开 shell 进程才能生效，旧终端里的
echo $COMPOSER_HOME可能还是旧值
最容易被忽略的是：环境变量注入只在脚本执行那一刻有效，generate-config.php 里 getenv() 拿不到 CI 系统变量，除非你在 composer install 前就 export 好——很多 pipeline 就是这一步漏了，导致生成空配置还查不出原因。
