入口文件必须显式引入 vendor/autoload.php；PHP 运行时不会自动加载任何类，需在 index.php 等入口首行用 require_once DIR . '/vendor/autoload.php' 绝对路径引入，否则类加载失败。
入口文件必须显式引入 vendor/autoload.php
Composer 不会自动加载任何类，哪怕你已经 composer install 完所有依赖。PHP 运行时根本不知道 vendor/ 里有什么，更不会自己去扫描和注册命名空间。唯一可靠的方式是在项目入口（比如 index.php、public/index.php 或 CLI 脚本）第一行就写：
require_once __DIR__ . '/vendor/autoload.php';
注意三点：
-
__DIR__是关键——用绝对路径避免因工作目录不同导致引入失败 - 别用
require 'vendor/autoload.php'（相对路径），在 CLI 或子目录下极易报failed to open stream - 如果项目用了框架（如 Laravel、ThinkPHP），它们的入口文件早已包含这行，你不需要重复加，但得确认它确实存在
composer install 后不能直接“运行项目”，得看项目类型
composer install 只负责下载和组织代码，不启动 Web 服务、不执行命令、不生成可执行文件。所谓“运行项目”，实际取决于你的项目结构：
- Web 项目：需用 PHP 内置服务器或 Nginx/Apache 指向
public/或web/目录（不是项目根目录），且确保该目录下有入口文件（如index.php）并已引入autoload.php - CLI 工具类项目：通常提供一个
bin/下的可执行脚本（如bin/mytool），需先chmod +x bin/mytool，再运行；该脚本内部仍要require vendor/autoload.php - 纯库项目（无入口）：它本身不能“运行”，只能被其他项目
require使用；此时composer install仅用于开发时跑测试（如vendor/bin/phpunit）
常见依赖调用失败的三个真实原因
即使 autoload.php 引入了，类仍找不到？大概率是下面之一：
- 类名拼错或命名空间没对齐，比如用了
GuzzleHttpClient却没写use GuzzleHttpClient;或直接写GuzzleHttpClient - 依赖包没真正安装成功：检查
vendor/下是否存在对应目录（如vendor/guzzlehttp/guzzle），若缺失，说明composer install中途出错或被中断 - PSR-4 自动加载没配对：如果你自己写的代码在
src/下，但composer.json里没声明"autoload": {"psr-4": {"App\": "src/"}}，那么new AppFoo()就会报错
composer install 和 composer update 的行为差异直接影响运行结果
这两个命令看似都能装依赖，但触发逻辑和结果完全不同：
-
composer install：只读composer.lock，严格按锁文件里的版本下载，保证所有人环境一致；若 lock 文件不存在或损坏，它会退化为update行为，但这是异常路径 -
composer update：忽略 lock 文件，重新解析composer.json中的版本约束（如^7.4），可能升级到不兼容的新版，导致运行时报Call to undefined method或接口变更 - 线上部署必须用
composer install --no-dev --optimize-autoloader：去掉开发依赖、生成优化后的类映射，否则可能因phpunit等未安装而报错，或 autoload 太慢
真正容易被忽略的是：很多团队在本地用 update 开发，却忘了提交更新后的 composer.lock，导致 CI 或生产环境 install 出来的版本和本地不一致，问题复现困难。
