Composer本身无交互界面，所谓“交互式安装”需外部脚本封装实现；因默认非交互模式下STDIN非TTY时自动跳过询问，--no-interaction是CI/CD等场景的默认行为，scripts能否读取输入取决于运行环境是否支持TTY，而非Composer自身提供UI组件。
Composer 本身没有交互式安装界面，也不支持运行时交互式配置；所谓“交互式安装”必须靠外部脚本封装实现。
为什么直接运行 composer install 不会出现交互提示
Composer 在非交互模式（如 CI 环境、Docker 构建）下默认禁用所有用户输入。即使 composer.json 中定义了 scripts 或启用了 prompt 类型的插件，只要 STDIN 不是 TTY（比如管道、重定向、--no-interaction 显式启用），它就会跳过所有询问并使用默认值或报错。
-
composer install --no-interaction是默认行为，多数部署场景实际都在用这个模式 - 即使你写了
"scripts": {"post-install-cmd": "php script/ask-for-config.php"}，该脚本能否读取用户输入，取决于它是否运行在交互终端中 - Composer 自身不提供
dialog、inquirer风格的内置 UI 组件
如何用 Bash/PHP 封装出“交互式安装流程”
核心思路：把 composer install 当作一个原子步骤，前置或后置加入你自己控制的交互逻辑。不要试图“改 Composer”，而是“绕过它再补上”。
- 用
read -p（Bash）或stream_get_line(STDIN, 1024)（PHP）主动读取用户输入，生成配置文件（如.env、config/local.php） - 检查
composer.lock是否存在：不存在则先composer update --no-interaction，避免因 lock 文件缺失导致依赖解析失败 - 若需根据用户选择动态 require 包（例如选“开发工具”就加
phpunit/phpunit），应在composer.json中预留占位字段，再用composer require --no-interaction增量安装 - 注意信号处理：用户按
Ctrl+C时，Bash 脚本应清理临时文件、退出前调用composer install --no-interaction回滚到已知状态（可选）
常见翻车点：TTY 检测失效 & 容器环境陷阱
很多开发者以为 if [ -t 0 ]; then ... 就能安全判断是否可交互，但在 Docker 中这常为 false —— 即使你用了 docker run -it，某些基础镜像（如 alpine:latest）的 shell 可能不分配 TTY，或 ENTRYPOINT 启动方式绕过了 TTY 分配。
- 测试方法：运行
docker run -it --rm php:8.2-cli bash -c 'ls -l /proc/self/fd/0; echo $?'，看 fd 0 是否指向dev/pts/N - 更稳妥的做法是显式传参控制，比如脚本接受
--interactive标志，而不是自动探测 - 在 GitHub Actions 等 CI 中，永远假设无交互能力；把“交互逻辑”拆成两步：第一步生成
config.yaml模板供人工填写，第二步用--config-file=config.yaml参数驱动安装 -
composer create-project的--repository-url和--stability参数容易被忽略，但它们直接影响首次安装的包来源和版本策略，交互脚本里应提前确认而非硬编码
真正麻烦的不是“怎么问”，而是“问完之后怎么让后续所有环节（autoload 生成、env 加载、migration 执行）都尊重这次选择”。每多一层抽象，就要多一份状态同步机制 —— 这才是定制化脚本最难绷住的地方。
