答案是先验证包是否真实存在：访问https://packagist.org/packages/vendor/name确认页面可打开，再用composer search vendor/name和检查包名大小写、不可见字符；若存在则排查镜像失效、同步延迟、缓存残留或repositories配置错误。
不能“跳过”Package not found 错误——它不是可绕过的校验项，而是 Composer 明确告诉你：它根本没在任何已配置的源里找到这个包。强行压制只会让后续流程失败得更隐蔽。
先确认包名和源是否真实生效
报错时别急着加参数，先验证基础事实：
- 访问
https://packagist.org/packages/vendor/name（把vendor/name换成你实际要装的）看页面是否 404； - 运行
composer search vendor/name，如果没结果，说明 Packagist 上压根没这个包； - 检查包名大小写和拼写：
spatie/laravel-backup对，spatie/backup或Spatie/Laravel-Backup就错； - 粘贴包名时小心不可见字符（比如从网页复制带零宽空格），建议手动重打一遍。
私有包必须配对 repositories 且顺序正确
Composer 默认只查 packagist.org，私有包不会自动出现。配错一个字段，它就静默忽略整个配置，继续走官方源，结果还是 not found。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
repositories必须是composer.json顶层字段，内容为数组，每条是独立对象； - VCS 类型必须写
"type": "vcs"，不是"git"或"github"； - URL 必须是可
git clone的地址，结尾只能是.git，不能带#main或路径； - 禁用 packagist.org 必须单独加一条：
{"packagist.org": false}，且放在数组末尾，不能嵌套或写成"packagist": false。
镜像失效或同步延迟常被误判为“包不存在”
用了阿里云、腾讯云等镜像却 still 404，大概率不是网络问题，而是镜像本身没同步到这个包。
- 运行
composer config -g repo.packagist确认当前全局镜像地址，避免还在用已停用的https://packagist.phpcomposer.com； - 临时切回官方源验证：
composer config -g repo.packagist composer https://packagist.org； - 切源后必须执行
composer clear-cache，否则缓存仍指向旧镜像元数据； - 新发布的包、
dev-main分支、或未触发 Packagist webhook 的仓库，镜像通常有数小时至一天延迟。
别用 --ignore-platform-reqs 或 --force-reinstall 应对 not found
这两个参数完全不解决“找不到包”的问题：--ignore-platform-reqs 跳过的是 PHP 版本/扩展检查，--force-reinstall 强制重装的是已解析成功的包。对 not found 报错加它们，只会让错误信息变得更模糊。
- 如果你看到
Could not find package xxx/yyy，加任何平台或强制参数都无效； - 真正该做的是：删掉错配的
repositories、修正包名、换源、清缓存； - CI/CD 中反复出现此错，90% 是
composer.json里写了私有源但没关 packagist.org，或者repositories配置被 gitignore 掉了没提交。
最易被忽略的一点：Composer 查包是「命中即停」，但这个逻辑只在 {"packagist.org": false} 生效后才启用。漏掉这一行，哪怕你前面配了十个私有源，它也永远先去官方源兜底——而你的包不在那儿。
