config字段仅控制Composer自身行为，不改变项目代码逻辑；vendor-dir和bin-dir等配置只影响后续install/update命令，不会迁移已有文件，必须重装依赖才生效。
composer.json 里的 config 字段只控制 Composer 自身行为，不改项目代码逻辑；写错位置、用错键名、漏掉引号，配置就等于没写。
vendor-dir 和 bin-dir 改了但文件没动到新位置？
这两个参数只影响后续命令的行为，不会迁移已有文件。执行完 composer config vendor-dir libs 后，vendor/ 下的包仍留在原处，直到下次 composer install 或 composer update 才会清空旧目录、重装到 libs/。
-
bin-dir默认是vendor/bin，设为bin后，phpunit这类命令会被软链接到项目根目录的bin/下，适合统一管理 CLI 工具 - 路径值必须是相对路径（如
"libs"），不能带前导./或/，否则 Composer 会忽略 - 改完别忘了检查
autoload是否仍指向正确路径——比如vendor/autoload.php被移到libs/autoload.php后，项目入口文件得同步更新 require 路径
process-timeout 和 preferred-install 怎么选才不卡住？
网络慢或 CI 环境下，process-timeout 设太低会导致 composer install 中断在 Git 克隆或压缩包解压阶段；而 preferred-install 直接决定下载方式和速度。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
process-timeout单位是秒，默认 300（5 分钟），国内镜像+dist 包一般够用；但若启用了source模式又走 GitHub，建议提到600以上 -
preferred-install推荐设为"dist"：下载 zip 包比 Git clone 快得多，且不依赖 Git 客户端；"source"只应在调试包源码时临时启用 - 设成
"auto"并不可靠——Composer 会按自己规则选，实际行为难预测，线上环境别用
sort-packages 和 autoloader-suffix 这些“优化项”真有用吗？
它们不提升运行时性能，但影响可维护性与部署稳定性，尤其在团队协作或自动化流程中容易被忽略。
-
sort-packages开启后，每次composer require都会自动按字母序重排require列表，避免多人提交引发的无意义 JSON 行序冲突 -
autoloader-suffix是解决多项目共用同一 vendor 目录时的类加载冲突，比如设为"MyApp"，生成的autoload_static.php里所有类名空间都会加该后缀，防止缓存污染 -
classmap-authoritative在生产环境开启能跳过文件存在性检查，加快类加载——但前提是确保所有类都在 classmap 里，否则会报Class not found
cache-dir 和 secure-http 哪些场景必须配？
cache-dir 主要用于 CI/CD 流水线隔离缓存；secure-http 是个危险开关，只应在极少数调试场景临时关闭。
-
cache-dir设为/tmp/composer-cache可避免多个 job 共享缓存导致的版本错乱，但注意/tmp可能被系统定时清理，CI 中建议挂载持久卷 -
secure-http设为false会让 Composer 允许 HTTP 协议源（如http://repo.example.com），但 Composer 2.2+ 默认拒绝，且私有源暴露在明文传输中风险极高，仅限本地 Docker 网络等可信环境 - 这个值不能设在项目级
config里生效——它属于全局安全策略，必须用composer config --global secure-http false，且每次执行前应确认是否真的需要
最常被忽略的是：所有 config 参数改完后，必须触发一次 composer install 或 composer update 才会真正落地；光写进 composer.json 不等于生效，尤其是 vendor-dir 和 bin-dir 这类路径变更，不重装就不会动文件。
