必须在命令前显式赋值，如app_env=prod composer install；多变量用空格分隔；ci/cd和docker中须通过env块或--env显式注入；仅composer_*前缀变量及config.http-basic等特定字段支持${var}插值。
Composer 本身不加载 .env 文件，也不自动继承 shell 环境变量到 scripts 中——你传不进去，它就真拿不到。
composer install 时怎么让脚本读到 APP_ENV
必须在命令前显式赋值，不能靠 .env 或 export：
-
APP_ENV=prod composer install是唯一可靠写法；多变量用空格分隔，如APP_ENV=staging DB_HOST=localhost composer install - scripts 里写的
$APP_ENV是由 shell 展开的，不是 Composer 解析的；写成"post-install-cmd": "echo $APP_ENV"没问题，但"post-install-cmd": "APP_ENV=${APP_ENV} php artisan config:clear"是错的——${VAR}在 scripts 字符串里不生效 - CI/CD（如 GitHub Actions）中必须用
env:块注入，不能依赖本地.env；Docker 要用--env或environment:显式传递，.env文件默认不进容器
哪些环境变量 Composer 真正会识别
只认文档明确列出的 COMPOSER_* 前缀变量，自定义变量（如 MY_FLAG=1）完全无效：
-
COMPOSER_NO_INTERACTION：强制非交互模式（等价于-n） -
COMPOSER_NO_SCRIPTS：跳过所有post-install-cmd等脚本 -
COMPOSER_MEMORY_LIMIT：设 PHP 内存限制（注意：它调的是ini_set()，不是 CLI 的-d memory_limit） -
COMPOSER_HOME和COMPOSER_CACHE_DIR：路径类变量能被正确继承，且优先级高于配置文件 -
HTTP_PROXY/HTTPS_PROXY：影响包下载，但优先级低于config.http-proxy
Windows 下传环境变量的写法差异
CMD 和 PowerShell 不支持 VAR=val composer install 这种 Unix 风格写法：
- CMD 必须用
set VAR=val && composer install（&&是关键，否则变量只在set行生效） - PowerShell 推荐绕过变量作用域问题：
cmd /c "set VAR=val && composer install"，比$env:VAR="val"; composer install更稳 - Git Bash 或 WSL 可直接用 Unix 写法：
APP_ENV=dev composer install - 如果用了
export COMPOSER_NO_INTERACTION=1再跑composer update却没效果，大概率是 Composer fork 子进程时丢失了该变量——直接前置赋值最保险
COMPOSER_HOME 改了为什么 auth.json 还不生效
COMPOSER_HOME 是 Composer 启动时硬读的唯一路径，但它不会自动迁移旧配置：
- 改完必须手动创建目录：
mkdir -p $COMPOSER_HOME（Windows 用mkdir D:\my-composer） - 把原
~/.composer/auth.json（或%APPDATA%\Roaming\Composer\auth.json）拷过去，并确保权限为600（Linux/macOS）或关闭继承权限（Windows） - 全局安装的包（如
phpunit）不会自动重装，得补一次composer global install - IDE 或 CI 脚本里调用
composer，要确认其启动环境也加载了新COMPOSER_HOME（GitHub Actions 需显式用env:注入）
最容易被忽略的一点：所有变量插值（${VAR}）只在 composer.json 的特定字段生效，比如 config.http-basic 和 repositories[].url；其他地方写了也是白写，既不报错也不生效。
