composer脚本中读不到$_env或getenv()，因其默认以“干净环境”运行，仅保留path、home等白名单变量；需通过composer_script_前缀显式注入环境变量，并用getenv()读取。
Composer 脚本里读不到 $_ENV 或 getenv()？
因为 Composer 默认以“干净环境”运行脚本，系统级环境变量（包括 .env 文件加载的）默认不透传。不是 PHP 本身问题，是 Composer 的安全策略——它会清空大部分 $_SERVER['env'] 类变量，只保留极少数白名单（如 PATH, HOME）。
实操建议：
- 用
composer config --global scripts.env这类方式无效，config不影响脚本执行时的环境 - 必须显式通过
COMPOSER_SCRIPT_*前缀注入，或改用symfony/process手动控制环境 - 别在脚本里依赖
$_ENV['APP_ENV']，它大概率为空；优先检查getenv('COMPOSER_SCRIPT_APP_ENV')
composer.json 中怎么安全传入环境变量？
唯一被 Composer 原生支持的传参方式，是把变量名加 COMPOSER_SCRIPT_ 前缀后，通过 shell 启动时带入。比如你希望脚本拿到 APP_ENV=prod，就得这样调：
APP_ENV=prod COMPOSER_SCRIPT_APP_ENV=prod composer run-script build
注意两个关键点：
- 左边的
APP_ENV=prod是给当前 shell 进程用的，不影响 Composer 子进程 - 右边的
COMPOSER_SCRIPT_APP_ENV=prod才会被 Composer 捕获并注入到脚本环境里 - 变量名大小写敏感，
COMPOSER_SCRIPT_app_env≠COMPOSER_SCRIPT_APP_ENV
PHP 脚本里怎么可靠读取这些变量？
别用 $_ENV，它默认不自动填充；也别依赖 putenv() 的副作用——Composer 脚本启动时已固化环境。最稳的方式是直接调 getenv() 并检查返回值：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
$appEnv = getenv('COMPOSER_SCRIPT_APP_ENV') ?: 'dev';
常见错误现象：
- 写了
$_ENV['COMPOSER_SCRIPT_APP_ENV']却返回null—— 因为variables_order里没开E - 在
exec('php -r "echo getenv(...)")里读不到 —— 子进程不继承父进程的getenv()结果，得显式传参 - 用了
Dotenv::createUnsafeImmutable()加载.env—— Composer 脚本执行路径和项目根可能不一致，.env路径容易错
想动态判断 CI/本地环境？别硬编码 if (getenv('CI'))
CI 环境变量（如 CI=true）通常不会被 Composer 自动转发，除非你在 CI 配置里显式加上 COMPOSER_SCRIPT_CI=$CI。否则脚本里 getenv('CI') 永远是 false。
更健壮的做法：
- 统一约定用
COMPOSER_SCRIPT_CI，CI 流水线里写COMPOSER_SCRIPT_CI=true composer install - 如果脚本需区分 Laravel / Symfony 项目逻辑，别靠
getenv('APP_NAME')，改用file_exists('artisan')或file_exists('bin/console')判断存在性 - 避免在
post-install-cmd里做 heavy I/O 操作——此时 autoloader 可能还没生成，class_exists()会失败
真正麻烦的是跨平台兼容：Windows 下 set 命令不支持 VAR=val composer run 这种写法，必须用 set VAR=val && composer run，而 GitHub Actions 的 run: 默认走 sh，不是 cmd。这点很容易漏测。
