答案是PHP CLI配置与Composer实际调用的PHP实例不一致。需用which php和composer diagnose确认真实PHP路径，再执行该路径下的php --ini定位CLI专属php.ini，检查extension=xxx是否启用且未被注释，Ubuntu还需运行phpenmod启用扩展。
php -m 显示扩展已启用，但 Composer 仍报 ext-xxx missing
这不是扩展没装，而是 Composer 正在用的 PHP CLI 实例根本没加载它。php -m 输出可信，但必须确认这个输出对应的是 Composer 调用的那个 PHP。
- 运行
which php查 Composer 实际调用的 PHP 二进制路径 - 用该路径执行
/usr/bin/php --ini（别假设和 Web 的一样），看Loaded Configuration File行指向哪个php.ini - 打开那个
php.ini，搜索extension=xxx—— Linux 是extension=pdo_mysql.so，Windows 是extension=php_pdo_mysql.dll，拼写/路径/注释状态都要核对 - 常见陷阱：Ubuntu 上只运行
sudo apt install php-mbstring，但没跑sudo phpenmod mbstring，后者才真正往 CLI 的php.ini写入启用行
Composer install 卡在 “Loading composer repositories” 或报 cURL error 60
表面是网络问题，实际是 PHP 的 curl 扩展虽启用，但证书验证失败或 CA 包过期。
- 先验证
curl是否真可用：php -r "echo curl_init() ? 'ok' : 'fail';" - 检查 CA 配置：
php -i | grep curl.cainfo，若为空或路径不存在，就得手动设 - 下载最新
cacert.pem（从curl.se），然后在 CLI 对应的php.ini中加一行：curl.cainfo = "/full/path/to/cacert.pem" - 不推荐长期用
--ignore-platform-reqs或跳过校验，它掩盖了底层证书链断裂问题，后续更新可能突然崩
require vendor/autoload.php 后报 Cannot declare class Xxx
不是类没找到，是两个 PSR-4 映射同时声明了同一命名空间前缀，PHP 加载第二次时直接终止。
- 立刻删掉
vendor/composer/autoload_*.php，再跑composer dump-autoload -v，观察输出里是否重复出现相同前缀（如两行都含App\ => src/） - 检查所有依赖包的
composer.json，尤其注意autoload字段是否用了宽泛前缀（""、"App\"） -
PSR-4映射末尾必须带反斜杠："App\": "src/"✅，"App\": "src"❌（会导致类名解析多一层） - 不要指望
composer自动去重或优先级排序——它只是把所有规则原样注册进 autoloader 链，谁先被new谁生效，行为不可控
全局安装后 composer 命令提示 command not found
不是没装上，是 composer.phar 没进系统 $PATH，或者目标目录权限不对。
立即学习“PHP免费学习笔记（深入）”；
- 确认
composer config -g bin-dir返回的路径（默认是~/.composer/vendor/bin） - 检查该路径是否已加入
$PATH：运行echo $PATH，看有没有包含它；没有就加到~/.zshrc或~/.bashrc末尾：export PATH="$HOME/.composer/vendor/bin:$PATH" - 检查该路径本身权限：
ls -ld ~/.composer/vendor/bin，若属主是root，运行sudo chown -R $USER:$USER ~/.composer - 别用
php composer.phar替代composer命令——IDE 和 CI 工具通常不识别这种写法
php.ini 不仅路径不同，连扩展启用状态都可以完全独立。改完 Web 端配置，不代表 CLI 就好了；反之亦然。每次怀疑扩展问题，第一反应不该是重装，而是先锁死当前上下文用的是哪个 PHP、哪个配置文件、哪个扩展列表。 
