composer环境搭建完整指南_从零开始配置composer环境【教程】-composer-PHP中文网

composer命令找不到是因二进制未加入path：windows需手动添加安装路径到环境变量，macos/linux应将composer.phar移至/usr/local/bin并赋执行权限；依赖解析失败主因是php版本与包不兼容，需用composer diagnose检查并核对platform配置；国内源失效多因项目级配置覆盖全局设置，应检查并修改项目composer.json中的repositories；vendor权限问题会导致autoload失败，须修复.php文件为644、目录为755，禁用777。

composer环境搭建完整指南_从零开始配置composer环境【教程】

composer 命令找不到：PATH 没配对

装完 Composer 却在终端输 composer --version 报 “command not found”，大概率是二进制文件没进系统 PATH。

Windows 用户如果选了 “Add to PATH” 但依然不行，先检查安装路径是否被杀毒软件拦截（尤其是 360、腾讯电脑管家）；macOS / Linux 用户常见问题是把 composer.phar 放进了 /usr/local/bin，但该目录权限不足或未被 shell 加载。

推荐做法：下载官方 composer.phar 后，用 sudo mv composer.phar /usr/local/bin/composer（macOS/Linux），再加执行权限：sudo chmod +x /usr/local/bin/composer
Windows 用户别依赖安装器自动加 PATH，手动进「系统属性 → 高级 → 环境变量」，把 Composer 安装目录（如 C:\ProgramData\ComposerSetup\bin）加到用户或系统 PATH
改完 PATH 后，新开终端窗口验证，别在旧窗口里反复 source —— 大部分 shell 不会自动重读 PATH

composer install 报错 “Your requirements could not be resolved”

这不是网络问题，也不是权限问题，而是 composer.json 里写的依赖版本和当前 PHP 版本/已装扩展不兼容。

比如你在 PHP 8.2 下写了 "monolog/monolog": "^1.0"，而 v1.x 最高只支持 PHP 7.4，Composer 就会死循环尝试降级其他包来“凑出”一个能共存的组合，最终失败。

先运行 composer diagnose，它会告诉你 PHP 版本、禁用函数（如 proc_open）、以及是否启用了 allow_url_fopen
检查 composer.json 顶部的 "config": {"platform": {"php": "8.2.10"}} —— 如果项目实际跑在 PHP 8.1，这里写成 8.2 就会导致解析错误
临时绕过平台限制可加 --ignore-platform-reqs，但仅限调试，上线前必须删掉，否则可能装上根本不能跑的扩展

国内源切不生效：镜像配置被覆盖

执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，但 composer update 还是走官网，说明项目级配置优先级更高，盖掉了全局设置。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

Composer 会按顺序合并配置：命令行参数 > 项目根目录 composer.json 里的 config > 全局 auth.json 和 config.json。

进项目目录后，运行 composer config repo.packagist 查看当前生效的源地址
如果返回的是 {"type": "composer", "url": "https://packagist.org"}，说明项目 composer.json 里硬编码了官方源，删掉 "repositories" 字段或改成阿里云地址
某些 IDE（如 PhpStorm）自带 Composer 封装，会忽略系统配置，建议关掉 IDE 内置执行器，在终端里操作

vendor 目录权限混乱导致 autoload 失败

composer install 成功但 PHP 报 Class not found，autoload 文件存在、命名空间也对，问题往往出在 vendor/autoload.php 生成时权限太严，Web 服务器用户（如 www-data、nginx）读不了某些 .php 文件。

尤其在 macOS 或 WSL 上混用 root 和普通用户执行过 install，容易出现 owner 是 root、group 是 staff、other 无读权限的情况。

进 vendor 目录后，用 find . -type f -name "*.php" ! -perm -o=r | head -5 快速扫一遍有没有不可读文件
修复命令（Linux/macOS）：find vendor/ -type f -name "*.php" -exec chmod 644 {} \;，再给目录加执行位：find vendor/ -type d -exec chmod 755 {} \;
不要用 chmod -R 777 vendor/ —— 这会让 Composer 下次 install 时拒绝写入，报 file_put_contents(): failed to open stream: Permission denied

最麻烦的不是装不上，是装上了但 autoload 层级里某一个 .php 文件权限不对，PHP 不报错也不提示，就静默失败。查这类问题得一层层 echo require 路径，而不是只盯着 composer.json。