composer包类无法自动加载主因是autoload未触发或失效，需确认composer.json配置正确、用composer require安装、声明命名空间映射、运行dump-autoload、严格匹配psr-4大小写路径、确保vendor/autoload.php被及时引入、检查包是否支持自动加载、清除vendor和composer.lock重装。
Composer 安装的包类无法自动加载，90% 是因为 autoload 没触发或没生效，不是包本身有问题。
composer.json 的 autoload 配置写对了吗？
手动安装（比如用 git clone 或下载 ZIP）后直接扔进项目目录，vendor/autoload.php 根本不会管它——Composer 只认自己写进 vendor/composer/autoload_*.php 的映射。
- 确认你用的是
composer require vendor/package，而不是手动复制文件 - 如果包有自定义命名空间映射，必须在
composer.json里显式声明，例如："autoload": { "psr-4": { "MyApp\": "src/" } } - 改完
autoload后，必须运行composer dump-autoload（或composer install/composer update），否则新规则不生效 - 注意大小写：PSR-4 要求目录结构严格匹配命名空间，
MyAppFooBar必须对应src/Foo/Bar.php，不能是src/foo/bar.php（尤其在 Linux/macOS 上）
为什么 require 'vendor/autoload.php' 后还是报 Class not found？
常见于入口文件路径不对、autoload.php 没被引入，或引入时机太晚。
- 检查是否真执行了
require：加个var_dump(file_exists('vendor/autoload.php'));看路径是否存在 - 相对路径容易出错，建议用
__DIR__ . '/vendor/autoload.php'而非'vendor/autoload.php' - 确保
require在所有类使用前执行，且没被条件语句包裹（比如写在if (false) { ... }里） - 如果用了 HHVM 或某些 SAPI（如 PHP-FPM 的 opcache 预加载），可能缓存了旧的 autoload 映射，清空 opcache 或重启服务
第三方包的类明明在 vendor 里，却提示找不到？
不是所有包都默认可自动加载——有些只提供功能函数或需手动注册服务提供者（尤其是 Laravel 扩展包）。
- 先查该包的文档，看是否要求额外步骤，比如 Laravel 的
providers数组注册 - 运行
composer show vendor/package，看输出中是否有autoload字段；若为{}或空，说明它没声明任何自动加载规则 - 某些包（如纯函数库）只提供
files类型 autoload，必须靠composer dump-autoload生成包含逻辑，且这类文件会在每次请求时include_once，不能依赖命名空间自动发现 - 用
composer dump-autoload -o生成优化后的静态映射，能暴露部分路径映射错误（比如提示 “Class XXX is not in the class map”）
最常被忽略的一点：vendor/autoload.php 是 Composer 运行时生成的，它不校验实际文件是否存在，只按 composer.lock 和 autoload 配置硬编码路径。一旦文件被挪动、权限不足、或 composer install 中断导致 vendor/composer/autoload_static.php 残缺，就只会静默失败。遇到问题，先删掉 vendor 和 composer.lock，重来一遍。
