composer本身不读取.env文件，环境变量需由框架或脚本显式加载；scripts中使用变量须通过env键声明或composer_script_前缀注入，否则因子进程环境隔离而为空。
composer install 本身不主动读 .env 文件
它根本不会去扫描项目根目录下的 .env，也不会调用 phpdotenv 或任何框架的加载逻辑。你看到的 APP_ENV 生效，大概率是 post-install-cmd 脚本里调用了 artisan 或自定义 PHP 脚本——那些脚本才负责读 .env。直接在 composer.json 的 scripts 里写 echo $APP_ENV，基本为空。
环境变量只靠 shell 继承，且受限于执行上下文
composer install 启动的子进程，默认只继承父 shell 的白名单变量（如 PATH、HOME），其他变量是否传入，取决于你启动 composer 的方式：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 本地终端里先运行
export APP_ENV=dev && composer install，通常能生效 - CI/CD 流水线（如 GitHub Actions）中，必须显式用
env:块或export指令设置，否则变量丢失 - 用
sudo composer install时，sudo默认清空大部分环境变量，除非加-E参数 - Windows PowerShell 中用
$env:APP_ENV="prod"设置后，需确认是否传递给了 cmd 子进程（PowerShell 和 cmd 环境隔离较严）
scripts 中想安全用变量，得靠 COMPOSER_SCRIPT_ 前缀或 env 键声明
Composer 提供了两种可控方式让脚本访问变量：
- 在
composer.json的scripts里，用"env": {"APP_ENV": "testing"}显式注入，该变量会在脚本执行时通过getenv('APP_ENV')可读 - 或在 shell 中设
COMPOSER_SCRIPT_APP_ENV=staging，然后脚本里用getenv('COMPOSER_SCRIPT_APP_ENV')—— 这种方式绕过白名单限制，但需手动维护前缀 - 避免在 scripts 中直接依赖
$_ENV，它在 Composer 启动的子进程中通常为空
全局配置 ≠ 环境变量，别混淆 composer config -g 和 export
composer config -g http-basic.repo.example.com user pass 存的是认证凭据，不是运行时环境变量；COMPOSER_HOME 是路径变量，影响缓存和全局 bin 目录位置，但它本身不是“供 install 阶段读取的业务变量”。真正容易踩坑的是：COMPOSER_HOME 设错（比如含 ~ 或 $HOME）、没重启终端、PATH 没配对，导致 composer global require 安装的命令找不到——这和 APP_ENV 是否生效完全是两回事。
