Composer命令找不到是因PATH未配置，需将安装路径（如macOS/Linux的/usr/local/bin、Windows的C:\ProgramData\ComposerSetup\bin）加入环境变量并新开终端；若仍报错“Could not open input file”，则检查composer.phar是否存在及权限。
Composer 命令找不到：PATH 没配对
系统提示 command not found: composer，根本不是 Composer 没装，而是终端压根没找到这个可执行文件。Linux/macOS 下常因 PATH 未包含安装路径；Windows 则多因环境变量没刷新或装在非标准位置。
- 检查是否真装了：
which composer（macOS/Linux）或where composer（Windows CMD），没输出就说明没进 PATH - 全局安装后默认路径：macOS/Linux 是
/usr/local/bin/composer，Windows 是C:\ProgramData\ComposerSetup\bin，确认该路径已加入PATH - 改完 PATH 后，新开终端再试——旧终端不会自动继承新环境变量
- 不想配 PATH？直接用完整路径运行：
/usr/local/bin/composer install或php composer.phar install
运行报错 “Could not open input file: composer.phar”
这是用了 php composer.phar 方式但当前目录下根本没有 composer.phar 文件，或者文件被删/移动/权限不足。常见于手动下载后忘记放对位置，或误删了项目根目录下的临时 phar。
- 先确认文件是否存在：
ls -l composer.phar（Linux/macOS）或dir composer.phar（Windows） - 如果不存在，别硬跑，去 官网下载最新版，用
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"+php composer-setup.php重装 - 权限问题：Linux/macOS 下可能因下载后没执行权限，加一句
chmod +x composer.phar - 注意：不要把
composer.phar放进vendor/目录——它不属于项目依赖，是工具本身
“Your requirements could not be resolved” 类依赖冲突
这不是命令找不到或文件缺失，而是 composer install 或 composer update 过程中 PHP 版本、扩展、包版本互相卡死。错误信息里一定带具体包名和约束条件，不能只看“无法解析”四个字。
- 先看报错第一行末尾的包名，比如
laravel/framework v10.0.0 requires php ^8.1，再对照你本地php -v输出 - 检查是否启用了必需扩展：
php -m | grep mbstring（Laravel 等常用扩展缺一不可） -
composer why-not vendor/package:version能定位哪个包在阻止安装，比盲猜快得多 - 别急着加
--ignore-platform-reqs，它绕过检查但不解决根本问题，上线环境大概率崩
维护时 composer.lock 被意外修改或损坏
composer.lock 不是生成物，是部署一致性保障。有人手动编辑、Git 合并出错、换行符混乱，都会导致 install 行为异常，甚至装出和 CI 不同的依赖树。
- 不要手动改
composer.lock—— 所有变更必须通过composer require或composer update触发重写 - Git 提交前检查：用
composer validate快速验证 lock 文件语法与哈希完整性 - 如果 lock 已损坏且无备份，删掉它再跑
composer install（前提是composer.json正确）——但生产环境务必先确认 JSON 是否权威 - CI 流水线里建议加一步：
composer install --dry-run，提前暴露 lock/json 不匹配问题
最麻烦的往往不是命令找不到，而是错误信息看起来像环境问题，实际卡在 lock 文件校验或平台要求上。盯住报错里第一个冒号后的具体包名和版本约束，比反复重装 Composer 有用得多。
