composer install 报“package not found”主因是包不在 packagist，需手动添加 vcs 仓库；workflow 工具应优先 dev 局部安装并用 vendor/bin 调用，区分 project/library type，scripts 中注意路径、扩展和锁文件。
composer install 时提示 “Package not found” 或 “Could not find package xxx”
工作流包不是 Composer 官方仓库（packagist.org）里的常规依赖，很多是私有工具、CLI 脚本或非标准 type 的包，直接 composer require 会失败。
实操建议：
- 确认包是否真在 Packagist 上：访问
https://packagist.org/packages/{vendor}/{package}，搜不到就别硬试composer require - 如果是 GitHub/GitLab 仓库，手动加
repositories到composer.json："repositories": [ { "type": "vcs", "url": "https://github.com/xxx/workflow-tool" } ] - 部分工作流包（如
phpstan/phpstan、infection/infection）应作为require-dev安装，避免进生产环境
用 composer 全局安装 workflow CLI 工具（比如 laravel-zero、symfony/console 应用）
全局安装看似方便，但容易引发版本冲突——不同项目依赖的 phpunit 或 phpstan 版本不一致，全局装一个就卡死协作流程。
实操建议：
- 优先用
composer require --dev {package}局部安装，再通过vendor/bin/{command}调用（例如vendor/bin/phpunit） - 非得全局？用
composer global require {package}，但必须确保~/.composer/vendor/bin在$PATH中，且注意 PHP 版本兼容性 - 检查是否已装：运行
composer global list，不是composer list—— 后者只显示当前项目的命令
composer.json 里 type=project 和 type=library 的区别影响 workflow 包管理
你用的是 create-project 拉下来的模板（如 laravel/laravel），还是自己从头建的空项目？这决定了 workflow 包该放哪、怎么加载。
实操建议：
-
"type": "project"（默认）：适合完整应用，workflow 工具（如部署脚本、数据迁移器）可放require-dev，用scripts键绑定命令 -
"type": "library"：纯类库项目，不应带任何 workflow CLI，否则会污染下游使用者的vendor/bin；如有必要，改用bin字段声明入口，但需文档明确说明“仅开发时使用” - 看
autoload配置：workflow 脚本若要被自动加载，得进psr-4或files，否则vendor/bin下的二进制文件可能找不到类
自定义 workflow 命令在 composer scripts 中执行失败
composer run-script 看似能跑任意命令，但环境变量、工作路径、PHP 扩展可用性常被忽略，导致本地 OK、CI 报错。
实操建议：
- 所有脚本命令前加
php -d extension=mbstring.so类似的显式扩展启用（尤其 CI 环境默认关扩展） - 路径别写相对：
"post-install-cmd": "php ./scripts/deploy.php"改成"php %DIR%/scripts/deploy.php"（%DIR%是 Composer 内置变量） - 避免在
scripts里嵌套composer install—— 可能触发递归锁，改用composer update --lock或直接删composer.lock再重装
复杂点在于：workflow 不只是“装个包”，它串起了环境、权限、扩展、路径、锁文件多个维度。漏掉任意一环，composer install 就可能静默跳过、或在 CI 里凌晨三点爆红。
