composer require是引入第三方包唯一推荐的入口，它自动校验版本合法性、更新composer.json与composer.lock、触发scripts并生成autoload映射；手动编辑require后仅运行install会跳过校验、缺失元信息、不执行脚本且autoload不生效。
composer require 是引入第三方包唯一推荐的入口，它不是“快捷命令”，而是触发整个依赖契约生成的起点——跳过它直接改 composer.json，等于绕过合约签章直接盖章，后续所有问题都源于此。
为什么不能手动编辑 require 字段后 run install
手动改 composer.json 的 require 后只执行 composer install，会跳过关键校验环节：
-
composer require会先调用ComposerPackageVersionStabilityFilter检查版本约束是否合法（比如^2.0和~2.0.0解析逻辑不同），手动写错不报错，但composer update时可能拉错分支 - 它自动写入
composer.lock的packages-dev或packages区块，并标记source.type（如dist还是git），手动改 JSON 不生成这些元信息，CI 环境可能因缺失 source 认证失败 - 若包含
scripts（如post-install-cmd），composer require会触发执行，手动 install 不触发——你可能漏掉生成配置文件、编译前端资源等关键步骤
require 时怎么选版本号才安全
不加版本号看似省事，实则埋下线上故障种子。版本字符串不是“越新越好”，而是要匹配你的稳定性策略：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 线上项目必须显式写约束：
composer require monolog/monolog:^3.0✅，而不是composer require monolog/monolog❌（后者默认取最新 stable，可能是^4.0） - 用
^不要用~：前者允许3.0.0 → 3.9.9，后者只允许3.0.0 → 3.0.9，对语义化版本更友好 - 测试环境需临时放宽？加
--ignore-platform-reqs只能用于本地调试，CI 脚本里出现就是红线；真要兼容旧 PHP，应改config.platform.php字段
require --dev 和 require 的边界在哪
区分标准不是“我开发时用不用”，而是“PHP 运行时代码里是否 new 或 use 它”：
-
symfony/console放require-dev✅：仅在bin/console里调用，且该脚本不上生产 -
symfony/console放require❌：如果控制器里用了CommandBus::dispatch()，那它就是运行时依赖 -
phpunit/phpunit必须进require-dev，但phpunit/phpunit的扩展如phpunit/php-invoker若被业务代码反射调用，就得进require - 验证方式粗暴有效：
composer install --no-dev && php -r "require 'vendor/autoload.php'; new AppServicePaymentService();"能跑通，才算边界清晰
require 后类还是找不到？检查这三处
装完包却 Class not found，90% 不是包没装上，而是 autoload 链断在中间：
- 主项目没执行
composer dump-autoload：新增包的 PSR-4 映射不会自动合并进vendor/autoload.php，必须手动刷新 - 包本身 autoload 配错：比如本地包
composer.json写了"MyOrg\Utils": "src/"❌（缺结尾反斜杠），正确是"MyOrg\Utils\": "src/"✅ - 路径大小写不一致：Linux 下
src/Helper.php声明namespace AppHelper，但文件实际叫helper.php，类就永远加载失败——Windows 开发者最容易忽略这点
最常被跳过的动作是：改完 composer.json 后只 install，不 dump-autoload；或者以为 require 自动处理了 autoload，结果新类始终不在映射表里。autoload 不是“声明即生效”，它是静态快照，得你亲手重拍一次。
