Composer 报“The requested package xxx is not available”通常因误将系统库（如 libpng-dev）写入 require；Composer 仅管理 PHP 包，系统依赖需手动安装并启用对应扩展。
composer install 时提示 “The requested package xxx is not available”
这是最常见的误操作：把系统级包（比如 libpng-dev、curl、openssl）当成 PHP 包，直接写进 composer.json 的 require 里。Composer 管不了操作系统层面的依赖，它只处理 PHP 生态的包（Packagist 上的或私有仓库的）。
正确做法是分清责任边界：
- PHP 扩展（如
ext-gd、ext-opcache）属于运行时依赖，由 PHP 自身加载，需在系统中安装对应开发包 + 启用扩展 - 底层库（如
zlib、icu）是编译 PHP 或某些扩展时需要的，不是 Composer 能解决的 - 如果某个 PHP 包声明了
ext-gd为require，那你要做的是确保系统已装libgd-dev（Debian/Ubuntu）或gd-devel（RHEL/CentOS），再重新编译或启用gd扩展
Linux 下安装 PHP 扩展对应的操作系统包名怎么查
不同发行版包名不统一，硬记容易错。最稳的方式是按 PHP 扩展名反查系统包：
- Ubuntu/Debian：
apt search php[version]-+ 按 Tab 补全，例如apt search php8.2-gd会列出php8.2-gd包；若要编译扩展，搜libgd-dev - CentOS/RHEL 8+：
dnf search gd，关注带php-前缀或devel后缀的条目，如php-gd（运行时）、gd-devel（编译用） - Alpine（Docker 常用）：
apk search gd，对应包通常是php82-gd或gd-dev
注意：PHP 版本号必须匹配。装了 php8.1-gd，但 CLI 用的是 php8.2，php -m | grep gd 依然看不到。
composer create-project 报错 “proc_open(): fork failed”
这通常不是 Composer 本身的问题，而是宿主机资源限制触发的系统级报错，尤其在 Docker 容器、CI 环境或低内存 VPS 上高频出现。本质是 proc_open() 调用 fork() 失败，内核拒绝分配新进程。
临时绕过办法（非根治）：
- 加
--no-scripts参数跳过 post-install-cmd 脚本，它们常触发额外子进程 - 设环境变量
COMPOSER_MEMORY_LIMIT=-1防止 Composer 自己限制内存（但治标不治本） - 根本解法是调大容器或系统的
pid_max和vm.max_map_count，或给 Docker 加--ulimit nofile=65536:65536 --ulimit nproc=65536:65536
别指望改 composer.json 或换镜像源能解决这个错误——它压根不在 Composer 的控制域内。
想让 Composer 自动装系统包？别试了
没有安全、通用、跨平台的方式让 Composer 直接执行 apt install 或 yum install。有人写过自定义 installer script，但会带来严重问题：
- 需要 root 权限，CI/共享主机上直接失败
- 发行版差异导致脚本不可移植（
aptvsdnfvsapk） - 破坏 Composer 的纯 PHP 语义，协作时别人
composer install就卡住或报错
真正该做的，是把系统依赖写进文档（README.md）、Dockerfile 或部署脚本里，和 PHP 依赖明确分开。混在一起，迟早要花三倍时间 debug。
