最简可用结构只需require字段；require放运行时必需依赖如"monolog/monolog": "^3.0"和"php": ">=8.1"，require-dev放开发工具如"phpunit/phpunit": "^10.5"且不参与生产安装。
composer.json 文件最简可用结构只有 require 一项，其他字段全可省略；但新手常因乱加配置或路径改写导致 autoload 失效、命令找不到、CI 构建失败。
require 和 require-dev 到底怎么填才不踩坑
这两个字段是唯一真正影响依赖安装的配置项，其余字段多数只在特定场景生效。新手最容易犯的错是把开发工具（如 phpunit/phpunit）写进 require，结果生产环境也装了一堆测试代码。
-
require只放运行时必需的包，比如"monolog/monolog": "^3.0"；PHP 版本约束也该放这里："php": ">=8.1" -
require-dev放测试、静态分析、构建工具等，如"phpunit/phpunit": "^10.5"；它不会被composer install --no-dev安装 - 版本号别写死（如
"^2.0.0"比"2.0.0"更安全），也别用*或dev-main—— 后者会绕过稳定性检查，CI 极易出问题
vendor-dir 配置看似自由，实则基本不能动
很多新手看到 "config": {"vendor-dir": "libs"} 就以为能自定义依赖目录，结果 IDE 报 Class not found、phpunit 命令执行失败、CI 流水线直接中断。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Composer 硬编码识别
vendor/路径：所有生态工具（IDE、PHPStan、Psalm、Dockerfile、vendor/bin/下的命令）都默认找它 -
config.vendor-dir仅在vendor/目录不存在时生效；一旦已有vendor/，改了配置也没用 - 想换路径？必须先删掉整个
vendor/，再改配置，再跑composer install；但绝大多数 CI 环境不允许删 vendor，所以实际不可行
autoload 配置写错，类就永远加载不到
PSR-4 是当前唯一推荐的自动加载方式，新手常把命名空间和路径配反，或漏掉末尾斜杠，导致 new AppHttpControllerHome() 仍报错。
- 格式必须是
"App\": "src/"，注意双反斜杠转义、路径以/结尾、路径是相对于composer.json的相对路径 - 不要写成
"App": "src"（单反斜杠在 JSON 中非法）、"App\": "./src"（.会被忽略）、"App\": "src"（没斜杠会导致映射错位） - 改完后必须运行
composer dump-autoload，否则新配置不生效；composer install不会自动触发此操作
镜像源配置别硬塞进 composer.json
新手常把阿里云、腾讯云镜像源直接写进项目级 composer.json 的 repositories 字段，结果团队协作时别人拉代码就卡住，或者私有包无法安装。
- 镜像源应设为全局配置：
composer config --global repo.packagist composer https://mirrors.aliyun.com/composer/ - 项目级
repositories仅用于私有包或临时调试，且要小心覆盖 packagist.org 默认行为 - 如果非要用项目级配置，务必加
"packagist.org": false显式禁用官方源，否则 Composer 会并行查两个源，慢且容易冲突
真正需要新手警惕的，不是“怎么写全”，而是“哪些字段根本不用碰”——vendor-dir、bin-dir、minimum-stability 这些字段，90% 的新项目连看都不用看。先让 require + autoload 跑通，比堆一堆半懂不懂的配置更可靠。
