Composer管理项目级PHP类库，系统包管理器安装PHP解释器及扩展；需确保composer.json依赖的扩展通过apt/yum安装，统一PHP版本，避免混用管理工具，保持环境一致。
在使用 PHP 项目时，经常通过 Composer 安装依赖，而系统级的 PHP 扩展或工具可能通过操作系统的包管理器（如 Debian/Ubuntu 的 apt 或 CentOS/RHEL 的 yum）安装。两者职责不同，但容易产生冲突或混乱。以下是如何清晰区分并解决它们之间潜在问题的方法。
理解职责划分
Composer 负责管理项目级别的 PHP 类库和依赖，比如 Laravel、Symfony 组件等；而 apt/yum 管理的是系统级别的软件包，包括 PHP 解释器本身、扩展模块（如 php-mysql）、命令行工具等。
常见冲突场景：
- Composer 安装了某个组件，但运行时报错提示缺少系统扩展（如 ext-pdo）
- 系统通过 apt 安装了旧版 PHP，导致 Composer 依赖无法满足
- 多个 PHP 版本共存时，Composer 使用的 PHP 和系统默认不一致
确保系统扩展满足 Composer 依赖
Composer 会检查 composer.json 中声明的 PHP 版本和扩展依赖。如果系统缺少对应扩展，即使类库下载成功也无法运行。
解决方法：
- 查看项目所需的扩展：检查
composer.json中的require字段，例如：
"ext-pdo": "*" - 使用系统包管理器安装缺失的扩展：
对于 Ubuntu/Debian：
sudo apt install php-pdo
对于 CentOS/RHEL：
sudo yum install php-pdo - 确认当前 PHP CLI 使用的配置是否加载了扩展，可用：
php -m | grep pdo
统一 PHP 版本环境
当系统存在多个 PHP 版本（如 7.4 和 8.1），Composer 可能基于默认 PHP 执行分析，但实际运行环境使用的是另一个版本，造成兼容性问题。
建议做法：
- 确认当前 Composer 使用的 PHP 版本：
php -v - 确保该版本与项目要求一致。如果不符，可通过 update-alternatives 或直接指定 PHP 二进制路径切换。
- 某些情况下可使用带有特定 PHP 版本前缀的包名，例如：
sudo apt install php8.1-mysql - 开发环境中推荐使用 phpbrew 或 deb.sury.org 源来管理多版本 PHP。
避免混合管理同一功能
不要用 Composer 安装应由系统管理的工具，反之亦然。
典型例子：
-
phpunit：可以本地用 Composer 安装（
composer require --dev phpunit/phpunit），而不是全局安装或用 apt 安装旧版本。 - PHP-CS-Fixer、PHPStan 等开发工具也推荐以项目局部方式引入。
- 系统工具如
php-cli、php-fpm、apache2/mod_php必须由 apt/yum 管理。
这样既保证项目隔离性，又避免权限和路径冲突。
基本上就这些。关键是分清“项目依赖”和“系统依赖”，Composer 不替代操作系统包管理器，两者协同工作才能稳定运行 PHP 应用。
