Composer本身不读取环境变量，也不加载.env文件；APP_ENV等变量仅在scripts中由shell显式传入（如APP_ENV=prod composer install）时生效，且PHP子进程需手动继承，应用启动时才由框架（如Laravel/Symfony）通过phpdotenv加载。
Composer本身不读取环境变量
Composer不是运行时环境，它在安装或更新依赖时执行，不会主动加载.env文件或shell环境变量。你看到的APP_ENV=production这类变量，对composer install命令本身没有直接影响——除非你在composer.json里显式引用它们（比如通过scripts调用PHP脚本），或者用插件介入流程。
在composer.json中使用环境变量需靠shell展开
只有在scripts字段中、且命令由shell执行时，环境变量才可用。注意：这依赖宿主shell，Windows cmd、PowerShell、Linux bash行为不同，推荐统一用bash/sh兼容写法。
例如，在composer.json中写：
"scripts": {
"post-install-cmd": "php -r \"echo 'Current env: ' . getenv('APP_ENV') . PHP_EOL;\""
}
但这样实际运行时getenv('APP_ENV')仍为空——因为PHP子进程默认不继承父shell的环境变量（尤其在某些CI或Docker环境下）。更可靠的做法是显式传递：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
APP_ENV=${APP_ENV} php ...方式注入（Linux/macOS） - 避免在
scripts里直接写$APP_ENV，shell可能未展开（需用双引号+反斜杠转义或改用exec） - Windows用户应改用
%APP_ENV%语法，且最好切换到Git Bash或WSL以保持一致性
想根据环境变量控制依赖安装？别用composer.json条件判断
composer.json不支持if APP_ENV == "dev"这类逻辑。所谓“按环境加载包”，实际是靠require-dev和--no-dev参数配合CI流程完成的：
-
composer install --no-dev跳过require-dev里的包（生产环境常用） -
COMPOSER_DEV_MODE=0 composer install不会生效——这个环境变量Composer不识别 - 真正起作用的是
COMPOSER_NO_DEV（值为1），它是Composer原生支持的开关，等价于--no-dev - 自定义逻辑（如仅在
staging环境装某包）必须交由部署脚本处理，而非Composer本身
需要运行时读取环境变量？交给应用代码，不是Composer
Composer只管装包，不参与应用启动。环境变量应在PHP应用启动时读取，比如Laravel用$_ENV或env()函数，Symfony用Dotenv::createUnsafeImmutable()加载.env。常见误区是试图让autoload.php或vendor/autoload.php感知APP_ENV——它根本没机会知道。
如果你发现composer dump-autoload后类没加载，或APP_ENV在post-autoload-dump里取不到，说明你把运行时职责错压给了构建工具。
环境变量的边界很清晰：Composer负责“装什么”，应用负责“怎么用”。越界操作只会增加不可控性。
