composer不能安装c/rust库，因其仅管理php代码依赖；ffi调用需手动确保共享库存在、路径正确及abi兼容，composer仅能自动加载封装ffi的php类。
Composer 不支持管理非 PHP 语言的扩展包，它只管 PHP 代码的依赖、自动加载和生命周期钩子；FFI 调用 C 库不需要 Composer 安装，但需要你手动确保共享库存在、路径正确、ABI 兼容。
Composer 为什么不能“安装”C 或 Rust 库
Composer 的 require 只下载并解压 PHP 包（含 PHP 源码、配置、脚本），它不执行编译、不调用 gcc、不写入系统 /usr/lib。所谓“C 扩展包”，比如 ext-redis 或 igbinary，实际是 PHP 扩展（.so/.dll），必须通过 pecl install 或系统包管理器（apt install php-redis）安装，Composer 对它们只有声明式提示（ext-redis: *），不做任何实质操作。
常见误解包括：
- 在
composer.json中写"require": {"libpng": "^1.6"}→ 报错，因为libpng不是 Packagist 上的 PHP 包 - 以为
composer require hirak/prestissimo是在装“加速插件”，其实它只是个 Composer 插件，仍不触碰系统级 C 库 - 把 FFI 封装类（如
php-memcached-ffi）当成“替代 ext-memcached”，但忘了它仍需本地libmemcached.so存在
FFI 调用 C 库时，Composer 能帮什么忙
Composer 唯一能做的，是帮你组织和加载封装 FFI 的 PHP 类——比如你写了 src/FFI/LibCurl.php，用 FFI::cdef() 和 FFI::load() 加载 libcurl.so，那么 Composer 可以通过 PSR-4 自动加载这个类，仅此而已。
实操要点：
- 确保
composer.json中"autoload": {"psr-4": {"App\FFI\": "src/FFI/"}}，且文件路径与命名空间严格对应 -
FFI::load()的路径必须是运行时可访问的绝对路径，推荐用__DIR__ . '/../../vendor/libcurl/libcurl.so'或环境变量控制 - 不要把
.so文件直接塞进vendor/：它不属于 PHP 包，Git 不该跟踪，CI 构建机可能无权写入 - 若用 Docker，应在
Dockerfile中用apt install libcurl4-openssl-dev安装系统库，而非靠 Composer 下载
容易被忽略的 ABI 和平台兼容性问题
FFI 加载失败，90% 不是 Composer 配置问题，而是底层库不匹配：
-
FFI::load()报Unable to load shared library→ 检查ldd your.so是否缺依赖，或是否是 musl（Alpine）vs glibc（Ubuntu）二进制混用 - PHP 进程是 64 位，但
libxyz.so是 32 位 → 直接段错误，无明确报错 - C 函数签名写错（比如把
int*当成int）→ 运行时内存越界，PHP 进程崩溃，日志里只有segfault - 不同 Linux 发行版的库路径不同：
/usr/lib/x86_64-linux-gnu/libcurl.so（Debian） vs/usr/lib64/libcurl.so（CentOS）→ 硬编码路径必挂
真正关键的不是“怎么让 Composer 装上”，而是“怎么让 PHP 进程在目标环境找到并安全调用那个 .so”。这一步，Composer 一个字都帮不上。
