Composer不管理C/C++共享库，仅通过ext-*检查PHP扩展是否启用；系统库需手动安装，PHP扩展才是连接底层库的接口层，生产环境须显式锁定系统依赖。
Composer 本身不管理 C/C++ 共享库的版本，它只处理 PHP 包。任何试图让 composer install 自动下载、链接或加载 .so / .dll 文件的行为，都是对 Composer 职责边界的误用。
composer.json 无法声明系统级依赖
Composer 的 require 字段只解析 PHP 包名（如 monolog/monolog），不识别操作系统层面的库（如 libcurl4、libpq5 或 openblas）。
你写 "ext-curl": "*" 是在声明 PHP 扩展依赖，不是 C 库；而 "php": ">=8.2" 是语言运行时约束，不是编译器或 ABI 版本控制。
常见错误现象：
- 在 Dockerfile 中只跑
composer install，却忘了apt-get install libssl-dev，导致 cgo 或 ext-openssl 编译失败 -
composer.lock里锁定了ext-gmp，但宿主机没装libgmp-dev，PHP 启动时报PHP Warning: Module 'gmp' already loaded或直接 segfault - 本地开发用 macOS Homebrew 装的
sqlite3是 3.45，CI 用 Ubuntu 22.04 自带的是 3.37，C 扩展行为不一致，但composer install完全无感
PHP 扩展才是 Composer 的“接口层”
真正连接 C/C++ 共享库的，是 PHP 扩展（如 pdo_pgsql、redis、grpc），它们封装了底层 ABI 调用。Composer 只能：
- 通过
ext-xxx检查扩展是否已启用（运行时） - 通过
config.platform.ext-xxx声明“假装存在”，用于跨环境 lock（构建时）
但这些都不等于版本管理。例如：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
"ext-pdo_pgsql": ">=8.0"不代表 PostgreSQL 客户端库版本，只表示 PHP 的 pdo_pgsql 扩展已加载且 API 版本 ≥ 8.0 -
grpc/grpc这个 PHP 包，其ext-grpc依赖的libgrpc版本由系统包管理器或源码编译决定，Composer 不参与构建、不校验 ABI 兼容性
混合编程中真正的版本锚点在三处
你需要手动对齐以下三个层级，Composer 只能辅助其中一环：
-
系统库层：用
apt list --installed | grep libpq（Debian）或brew info openssl（macOS）确认实际安装的共享库版本 -
PHP 扩展层：用
php -m | grep pgsql和php --ri pdo_pgsql查看扩展编译时链接的库路径与版本 -
PHP 包层：用
composer show grpc/grpc看 PHP 封装层语义化版本，它仅承诺对某范围的libgrpcABI 兼容（见其ext-grpc依赖说明）
典型断裂点：
-
grpc/grpc:^1.60要求ext-grpc >=1.60.0，而该扩展若用系统libgrpc1.55编译，运行时可能崩溃（ABI mismatch） -
ext-sqlite3在 PHP 8.2 下默认链接系统libsqlite3.so.0，但如果你用pecl install sqlite3时指定了--with-sqlite3=/opt/my-sqlite，Composer 完全不知道这个路径变更
生产环境必须显式锁定系统依赖
不要指望 Composer 自动生成跨平台兼容性。正确做法是：
- Docker 构建中，用
FROM php:8.2-cli后立即apt-get install -y libpq-dev=15.5-1.pgdg120+1（固定 deb 版本） - CI 配置里，用
before_script显式检查：ldd $(php -r "echo extension_dir;")/pgsql.so | grep libpq - 在
composer.json的scripts中加验证钩子："post-install-cmd": ["bash -c 'php --ri pgsql 2>/dev/null | grep \"libpq version\" || (echo 'libpq mismatch!' >&2; exit 1)'"]
最常被忽略的一点：PHP 扩展的 .so 文件一旦编译完成，就和构建时的系统库 ABI 绑定。换机器、换 OS 小版本、甚至换 glibc minor 版本，都可能导致 dlopen() 失败——而 Composer 对此毫无感知，也不会报错。
