最可靠方式是通过composer.json的extra字段传参并在脚本中读取：$extra = $event->getComposer()->getPackage()->getExtra(); $env = $extra['app-env'] ?? 'dev'，配合分层配置（base+patch）和分离generated/local文件确保安全与可维护性。
Composer脚本里怎么读取环境变量并写入配置文件？
直接用 putenv() 或 $_ENV 不可靠——Composer执行时可能不加载 shell 环境，getenv('APP_ENV') 经常返回空。真正稳定的方式是通过 Composer 的 extra 字段传参，或在运行时显式传入环境标识。
推荐做法：在 composer.json 里定义 extra 配置项，再用 PHP 脚本读取：
"extra": {
"app-env": "prod",
"db-host": "db.example.com"
}
然后在自定义脚本中用 ComposerScriptEvent 获取：
$io = $event->getIO(); $extra = $event->getComposer()->getPackage()->getExtra(); $env = $extra['app-env'] ?? 'dev';
-
$event->getComposer()->getConfig()->get('bin-dir')可用来定位生成路径，避免硬编码 - 别依赖
$_SERVER['APP_ENV']—— CLI 模式下它通常不存在 - 如果必须用系统环境变量，改用
putenv('APP_ENV=prod') && getenv('APP_ENV')组合，并确保在脚本开头调用
生成 config.php 时如何避免覆盖已有手动修改？
直接 file_put_contents('config.php', $content) 很危险——下次 composer install 就会冲掉你加的调试开关或临时密钥。安全做法是只生成「基础骨架」，把用户可编辑部分隔离出来。
典型结构：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
// config.php return array_merge( require __DIR__ . '/config.generated.php', require __DIR__ . '/config.local.php' // 手动维护，.gitignore 掉 );
-
config.generated.php由脚本每次重写，内容不含敏感值（密码等走 env 文件） - 脚本生成前先检查
config.local.php是否存在，不存在才创建示例文件 - 用
var_export($array, true)生成 PHP 数组，比 JSON 更兼容老项目，且支持注释占位（如// DB_PASSWORD: set in .env）
为什么 vendor/bin/xxx 命令跑不通，但 php scripts/gen-config.php 可以？
因为 Composer 脚本默认在项目根目录执行，而 vendor/bin/xxx 是 symlink 到 vendor/composer/autoload_real.php 的包装器，它不继承当前 shell 的 PATH 或 .env，更不会自动加载项目 autoloader。
- 所有自定义脚本必须声明为
"scripts"下的条目，例如："gen-config": "php scripts/gen-config.php" - 不要在脚本里写
require 'vendor/autoload.php'—— Composer 已为你注入自动加载器 - 若需调用其他包的类（如 Symfony Dotenv），确保该包在
require-dev里，且脚本里用class_exists('Symfony\Component\Dotenv\Dotenv')做存在性判断再加载
多环境生成时，怎么让 dev 和 prod 的 config.php 差异最小化？
不是靠 if-else 写两套模板，而是用「配置层叠」：基础配置 + 环境补丁 + 运行时覆盖。生成脚本只负责前两层。
示例逻辑：
$base = require 'config.base.php';
$patch = require "config.{$env}.php";
$config = array_replace_recursive($base, $patch);
-
config.base.php放通用项（如 app.name、timezone） -
config.prod.php只覆盖必要项（debug → false、cache_driver → redis） - 绝对不要在生成脚本里拼接数据库密码——从
.env读，且确保.env在.gitignore中 - 生成后建议加一行校验：
if (!is_writable('config.generated.php')) { throw new RuntimeException('Config write failed'); }
生成逻辑越简单越好，复杂判断留给运行时。比如缓存前缀带环境名这种事，交给应用启动时的代码做，别塞进生成脚本里。
