COMPOSER_HOME 应指向有写权限的持久化路径(如自定义目录),避免被 Docker/CI/IDE 覆盖导致插件丢失、缓存失效;默认路径为 $HOME/.composer 或 %USERPROFILE%\AppData\Roaming\Composer。

COMPOSER_HOME 指向哪里才不被覆盖
默认情况下,COMPOSER_HOME 会指向 $HOME/.composer(Linux/macOS)或 %USERPROFILE%\AppData\Roaming\Composer(Windows),但这个路径一旦被其他工具(比如 Docker 容器、CI 环境脚本、或某些 IDE 插件)提前设置过,就可能悄无声息地切到一个空目录,导致插件丢失、缓存失效、甚至 composer global require 装的东西找不到。
- 检查当前值:
echo $COMPOSER_HOME(Linux/macOS)或echo %COMPOSER_HOME%(Windows) - 临时生效:运行前加前缀,如
COMPOSER_HOME=/path/to/my-composer composer install - 永久生效:写入 shell 配置(
~/.bashrc或~/.zshrc)时,确保它在source其他可能覆盖它的脚本之后 - CI 场景下建议显式声明,避免依赖默认值 —— GitHub Actions 中常见错误是没设
COMPOSER_HOME,结果全局 bin 路径(vendor/bin)根本不在$PATH里
COMPOSER_CACHE_DIR 影响哪些操作的快慢
COMPOSER_CACHE_DIR 控制下载包、压缩包解压、安装器(installer)缓存的位置。它不只影响 composer install 的首次速度,更关键的是决定 composer update 是否能跳过重复下载和重新解包。
- 默认值通常和
COMPOSER_HOME绑定($COMPOSER_HOME/cache),但可独立设置,比如指向 SSD 分区或 CI 缓存挂载点 - 如果设为不可写路径,你会看到类似
Failed to create cache directory: Permission denied的警告,此时 Composer 会退回到内存缓存(极慢)或完全跳过缓存逻辑 - Docker 构建中常犯的错:把
COMPOSER_CACHE_DIR指向容器内临时路径(如/tmp/composer-cache),构建完即销毁,下次构建还是从零下载 - 推荐做法:在 CI 中挂载持久化缓存目录,并确保用户有写权限;本地开发可指向大容量磁盘,避免
~/.composer/cache占满系统盘
HTTP_PROXY 和 HTTPS_PROXY 怎么配才不干扰 packagist.org
设了代理后,composer install 可能卡住、报 Connection refused 或返回 403,不是因为代理本身有问题,而是 Composer 默认对所有域名走代理,包括 packagist.org 和镜像源(如 https://packagist.phpcomposer.com),而部分企业代理会拦截或重写这些请求。
- 必须同时设置
HTTP_PROXY和HTTPS_PROXY,否则 HTTPS 请求仍直连(容易出 SSL 错误或超时) - 若仅需代理私有仓库(如 GitLab 私服),用
NO_PROXY排除公共源:NO_PROXY=packagist.org,repo.packagist.org,github.com - 注意大小写:
http_proxy(小写)在某些 shell 下会被忽略,务必用全大写环境变量名 - 验证是否生效:运行
composer config -g --list | grep proxy,看有没有意外写入配置项 —— Composer 会把环境变量映射成全局 config,冲突时以 config 为准
COMPOSER_NO_INTERACTION 和 COMPOSER_DISABLE_TTY 的区别在哪
这两个变量都用于非交互式场景(CI/CD、Dockerfile),但作用层面完全不同:COMPOSER_NO_INTERACTION 让命令跳过所有提示(如“Do you trust this package?”),而 COMPOSER_DISABLE_TTY 是告诉 Composer “你当前没有终端”,从而禁用进度条、颜色输出、以及某些依赖 TTY 的交互逻辑(比如密码输入掩码)。
-
COMPOSER_NO_INTERACTION=1是 CI 必备,否则composer install在遇到需要确认的包时直接挂起 -
COMPOSER_DISABLE_TTY=1主要解决日志污染和 ANSI 字符乱码问题,尤其在 Jenkins 或旧版 GitLab Runner 中,不设它可能导致输出含^[[0m这类控制字符 - 二者可共存,但顺序无关;不过如果只设了前者没设后者,在某些容器环境下仍可能触发 TTY 相关的异常(比如
proc_open(): unable to create pipe) - 注意:它们不会影响
composer create-project对git clone的交互行为 —— 那部分由 Git 自己控制,还需额外设GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no"
COMPOSER_HOME 和 COMPOSER_CACHE_DIR 的权限与生命周期管理,尤其是当它们跨用户、跨容器、跨构建阶段复用时,一个不可写的缓存目录比没缓存还麻烦。










