Composer不编译二进制依赖，仅管理PHP包；通过ext-扩展声明、脚本触发编译、预编译分发或外部工具协同解决二进制需求。
Composer 本身不负责编译二进制依赖，它是一个 PHP 的依赖管理工具，主要用于下载和管理 PHP 包。当项目依赖的扩展或库需要编译的二进制文件（如 C 扩展、PHP 扩展、系统库等），这些工作通常不在 Composer 的职责范围内。但 Composer 可以通过一些机制间接处理这类需求。
1. 使用 php-ext 类型包声明扩展依赖
如果一个 PHP 包依赖某个需要编译的扩展（例如 Redis、Swoole、imagick），可以在 composer.json 中声明对 PHP 扩展的依赖：
{
"require": {
"ext-redis": "*",
"ext-swoole": "^4.8"
}
}
Composer 在安装时会检查这些扩展是否已加载。如果未安装，会提示错误。但 Composer 不会自动编译或安装它们——这需要用户手动或通过其他工具完成。
2. 利用构建脚本触发编译流程
某些 PHP 包在安装后需要执行编译步骤（比如生成兼容的二进制文件）。可以通过 Composer 的 scripts 功能，在安装后运行自定义命令：
{
"scripts": {
"post-install-cmd": [
"MyPackage\Installer::compileBinary"
]
}
}
在 post-install-cmd 或 post-update-cmd 阶段调用 PHP 类方法，执行 shell 命令来编译二进制文件（如调用 make、gcc 或 phpize）。
3. 使用预编译二进制分发（推荐方式）
更常见的做法是：避免让用户本地编译，而是提供跨平台的预编译二进制文件。例如：
- 使用 PHAR 包打包包含二进制工具（如 Laravel Sail、Symfony CLI）
- 通过 Composer 下载适配当前系统的二进制可执行文件（如 spatie/browsershot 使用 Puppeteer 的 Node 服务，但通过 npm 安装而非编译）
- 利用 PECL 提供预编译的 .so/.dll 扩展，再由用户手动启用
4. 结合外部工具链管理编译
真正涉及源码编译的场景，通常依赖外部系统：
-
PECL：用于发布和安装 PHP C 扩展，支持从源码编译（
pecl install redis） - Docker：在镜像中完成编译，确保运行环境包含所需二进制
- CI/CD 脚本：在部署流程中自动编译并复制到目标环境
- phive：专门管理 PHAR 工具，可配合 Composer 使用
基本上就这些。Composer 不直接编译代码，但它能很好地与其他工具协作，确保运行环境满足依赖要求。关键是在设计包时明确区分“PHP 依赖”和“系统/二进制依赖”，并通过文档指导用户正确安装底层组件。
