composer-bin-plugin 并非替代主项目依赖管理，而是专为多命名空间子项目各自独立依赖的场景设计；需正确安装插件、配置 target-directory、确保子项目 composer.json 合法且路径规范，才能正常运行 bin 命令。
直接说结论：composer-bin-plugin 不是用来“替代”主项目依赖管理的，而是为了解决「多命名空间子项目共存 + 各自独立依赖」这个特定场景。它不是所有项目都该用，但一旦你有 vendor-bin/namespace1、vendor-bin/namespace2 这类结构，它就是目前最干净的方案。
为什么 composer bin xxx install 没反应或报错
常见现象是命令执行后无输出、没生成 vendor-bin/xxx/vendor，甚至提示 Command "bin" is not defined。
-
composer-bin-plugin必须已安装在主项目的require（不是require-dev）里，且版本兼容当前 Composer：v2.x 插件需"bamarni/composer-bin-plugin": "^2.0"；v1.x 已停止维护，不支持 Composer 2.5+ - 主项目
composer.json的extra.bamarni-bin.target-directory必须存在且路径可写，比如"target-directory": "vendor-bin"—— 如果写成"target-dir"或漏掉，插件会静默忽略配置 - 子项目目录（如
vendor-bin/mytool）下必须已有合法的composer.json，且不能是空文件或语法错误（多逗号、单引号、UTF-8 BOM 都会导致跳过） - Windows 用户注意：路径分隔符不影响，但若子项目路径含空格或中文，建议改用纯英文路径，避免某些 Composer 版本解析异常
composer bin xxx update 为什么没更新子项目里的 vendor
这不是 bug，是设计行为：默认情况下，composer bin xxx update 只更新子项目 composer.json 中声明的依赖，不会递归更新其依赖的依赖（即不加 --with-dependencies）。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 想完整更新子项目及其全部依赖，得显式加上
--with-dependencies：composer bin mytool update --with-dependencies - 如果子项目本身用了
path类型仓库（比如本地调试包），update不会自动拉取新代码——因为path是符号链接，改源码即生效，无需更新 - 子项目中若设了
"minimum-stability": "dev"，但主项目没配对应prefer-stable，可能导致版本解析失败，表现为 “no matching package found”
如何让 composer install 自动触发所有子项目安装
靠 extra.bamarni-bin.forward-command 控制，但它只转发 install 和 update，不转发 require 或 dump-autoload。
- 启用自动转发：在主项目
composer.json的extra.bamarni-bin下设"forward-command": true，这样运行composer install就会依次执行composer bin namespace1 install、composer bin namespace2 install等 - 注意顺序：子项目按目录名字母序执行，无法手动指定顺序；如有强依赖（比如
namespace2依赖namespace1构建产物），得拆成两步手动跑 -
forward-command对composer update同样生效，但如果你只想更新主项目，得加--no-plugins避免触发转发
真正容易被忽略的是权限和路径隔离：子项目 vendor-bin/xxx/vendor 下的二进制文件（如 phpstan、php-cs-fixer）默认不会被主项目 vendor/bin 软链，得手动加 "bin-links": true 并确保目标目录可写；另外 CI 环境中 vendor-bin 目录常被 .gitignore 掉，要记得在构建脚本里补上 mkdir -p vendor-bin/xxx，否则 bin 命令直接失败。
