config.bin-dir 仅影响新安装包，已安装包不会自动迁移；需清缓存、删 vendor 后重装才生效；项目配置优先于全局，路径须为相对路径；PATH 未更新则命令仍不可用；Windows 下应避免空格/中文路径。
config.bin-dir 设置后 composer install 不把可执行文件放进去？
常见现象是改了 bin-dir，但 vendor/bin 里还是有东西，新目录空着——根本原因是：这个配置只影响「后续新安装的包」，对已安装包不生效。composer install 不会自动迁移旧 bin 文件，也不会重写已存在的 vendor/bin 符号链接或复制行为。
实操建议：
- 先运行
composer clear-cache，避免缓存干扰 - 删掉整个
vendor/目录（别只删vendor/bin） - 再执行
composer install，这时才会按新bin-dir路径生成可执行文件 - 如果用了
"bin-dir": "tools"，确保tools/目录存在且可写，否则会静默失败
全局 config 和项目 config 的 bin-dir 哪个生效？
项目级配置优先级高于全局。也就是说，composer.json 里写的 "config": {"bin-dir": "scripts"} 会覆盖 ~/.composer/config.json 或 COMPOSER_HOME/config.json 里的同名设置。
使用场景：团队想统一用 bin/ 而不是默认 vendor/bin/，就在项目根目录 composer.json 的 config 段直接写死；个人开发环境调试多个项目时，才考虑改全局配置。
注意点：
- 全局设置命令是
composer config --global bin-dir /usr/local/bin，但不推荐指向系统/usr/local/bin，权限和冲突风险高 - 项目配置必须是相对路径（如
"bin"、"./bin"），不能写绝对路径，否则composer install会报错Invalid bin-dir path - 相对路径基于项目根目录解析，不是基于
composer.json所在位置
bin-dir 改了，为什么 phpunit 还是找不到？
本质是 shell 的 PATH 查找逻辑没变。即使 composer install 把 phpunit 放进了 tools/phpunit，如果你没把 tools/ 加进 $PATH，终端依然只能找到 vendor/bin/phpunit（如果还存在）或者根本找不到。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
解决办法很直接：
- 临时用：
./tools/phpunit（注意前面的./） - 长期用：在 shell 配置里加
export PATH="./tools:$PATH"（zsh/bash profile 中），然后source一下 - CI 场景下，直接在脚本里写完整路径，比如
./tools/phpunit --testdox，更稳定
别依赖“改了 bin-dir 就能全局敲命令”，Composer 不负责改你的环境变量。
Windows 下设 bin-dir 要特别注意什么？
Windows 默认不认 Unix 风格的可执行文件（没扩展名的 phpunit），Composer 会自动生成 .bat 包装器。但如果 bin-dir 路径含空格或中文，.bat 文件里的调用路径容易出错，导致双击或命令行执行时报 'php' is not recognized 或路径不存在。
稳妥做法：
- 避开空格和中文，用
bin、tools、run这类纯英文短名 - 确认 PHP 已加入 Windows
PATH，否则.bat脚本第一行@php就会失败 - 不要用 OneDrive 或 WSL 路径做
bin-dir，文件系统兼容性问题会导致composer install卡住或跳过生成
最省事的方式其实是不改 bin-dir，直接把 vendor/bin 加进系统 PATH——毕竟 Windows 用户通常更习惯“配一次 PATH，到处能用”。
