先确认 php 和 composer 可用，再检查项目根目录有 composer.json；install 依据 lock 文件装确切版本，update 重解析 json 版本约束；vendor 权限和 autoload 引入缺失是常见失败原因。
确认本地 PHP 和 Composer 是否可用
先确保终端里能直接调用 php 和 composer。很多“导入失败”其实卡在这一步——比如 Windows 上没配环境变量，或 Mac/Linux 用了 Homebrew 安装但路径没进 $PATH。
执行以下命令验证：
php -v composer --version
如果报 command not found，别急着改 composer.json，先装好或修复环境。Windows 用户推荐用 官方 PHP zip 包 + 手动配 PATH，比 XAMPP/MAMP 自带的 PHP 更可控；Mac 用户用 brew install composer 后记得检查 which composer 输出是否在 /opt/homebrew/bin/composer（Apple Silicon）或 /usr/local/bin/composer（Intel）。
项目根目录下必须有 composer.json
Composer 不会凭空下载依赖，它只认当前目录下的 composer.json 文件。这个文件要么手动创建，要么用 composer init 交互生成。
立即学习“PHP免费学习笔记（深入）”；
- 如果你已有现成项目，检查有没有漏掉
composer.json—— 有些 Git 仓库会忽略它，或误写成composer.lock单独提交 - 如果只是想试一个包（比如
monolog/monolog），运行composer require monolog/monolog，它会自动创建composer.json并写入依赖项 -
composer.json里"require"字段的版本约束别写太死，例如"^2.0"比"2.0.0"更易兼容，也避免后续composer update报冲突
执行 composer install 或 composer update？
这两个命令常被混用，但行为完全不同：
-
composer install：只按当前目录下的composer.lock文件安装**确切版本**。适合部署、协作开发——保证所有人装的是一模一样的依赖树 -
composer update：忽略composer.lock，重新解析composer.json中的版本约束，拉取满足条件的**最新匹配版本**。适合开发初期加新包，或主动升级 - 如果项目首次导入、且没有
composer.lock，composer install会退化为等价于composer update，并自动生成composer.lock
常见错误：团队协作时删了 composer.lock 还用 install，结果装出和别人不一样的子依赖，引发运行时异常。
vendor 目录权限与 autoload 失败
依赖装进 vendor/ 后，PHP 要能自动加载类，得靠 vendor/autoload.php。但本地环境容易出两类问题：
- Windows 下用 Git Bash 或 WSL 执行
composer install，结果vendor/权限混乱，导致 Apache/Nginx 访问时提示failed to open stream: Permission denied—— 解决办法是统一用 Windows 命令提示符或 PowerShell 执行，或手动chmod -R 755 vendor（Linux/macOS） - PHP 脚本里忘了引入 autoload：
require_once 'vendor/autoload.php';
尤其是写 CLI 脚本时，很容易漏掉这行，然后报Class not found - 某些 IDE（如 PhpStorm）不会自动识别
vendor/下的类，需右键项目 → “Add Framework Support” → 选 Composer，否则跳转和补全失效
真正麻烦的不是装不上，而是装上了却 autoload 失败——这时候看 vendor/autoload.php 是否存在、路径是否拼错、PHP 的 include_path 有没有干扰，比重装 Composer 有用得多。
