根本原因是未显式禁用默认源且配置位置错误：必须在项目根级composer.json的repositories数组首项写{"packagist.org": false}，并确保path类型仓库使用相对路径、name/version/路径三者严格匹配，否则Composer仍优先查packagist.org且静默跳过本地源。
直接配 repositories 不生效，是因为 Composer 默认只认 packagist.org，你加的仓库只是“摆设”，除非明确告诉它“哪个包该走哪条路”。核心不是加源，而是控制路由。
为什么 composer.json 里写了 repositories 却找不到本地包
常见现象是执行 composer require myorg/utils 报 Could not find package，但目录明明存在、composer.json 也写了路径。根本原因有三个：
-
repositories配置没写在项目根级composer.json的根数组里，比如错塞进require或config字段下 - 没禁用默认源：
"packagist.org": false这一行漏了，Composer 仍优先查官方源，你的本地包永远轮不到 -
url值用了绝对路径（如/home/user/packages/my-utils）或带file://前缀——Composer 会静默跳过，必须用相对路径（如"./packages/my-utils"）
path 类型仓库的三要素必须对齐
本地包能被识别，靠的是 name、路径、version 三者严格匹配。缺一不可：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 本地包根目录下必须有合法
composer.json，且含name字段（如"myorg/utils"），大小写敏感 -
repositories中的url必须精确指向该目录（不能多一级或少一级），且相对于项目composer.json - 本地包的
composer.json中必须声明version（如"dev-main"），或项目级配置设"minimum-stability": "dev"，否则dev-main这类分支名会被稳定性策略过滤掉
Class not found 和 autoload 配置强相关
装上了不代表能用。90% 的自动加载失败，问题不在 Composer 安装过程，而在命名空间注册环节：
- 确认本地包自己的
composer.json里写了正确的autoload，例如："psr-4": {"MyOrg\Utils\": "src/"} - 改完本地包或新增命名空间后，必须运行
composer dump-autoload（开发阶段不用加-o） - 如果包提供 Laravel Service Provider，
config/app.php中的providers数组必须手动添加，Composer 不处理这个 - 别在
require 'vendor/autoload.php'之前就 new 类——autoload 文件还没加载，自然找不到
CI 环境下容易忽略的硬性要求
本地跑通不等于 CI 能过。以下三点不满足，缓存和镜像都白配：
-
cache-dir必须挂载到高速本地盘（如 SSD），不能指向 NFS 或 Docker volume；推荐显式设为/tmp/composer-cache并在 CI 中挂载 -
composer install必须带--no-dev --prefer-dist --optimize-autoloader，漏一个，构建时间就翻倍 - 所有仓库配置必须写在项目级
composer.json，不要依赖开发者本地~/.composer/config.json，否则 CI 构建结果不可复现
最常被跳过的其实是 "packagist.org": false 和 autoload 后的手动刷新——这两步不执行，前面所有配置等于没写。
