必须三者同时满足:项目composer.json正确声明repositories为path类型、本地包composer.json的name与require中完全一致、require版本写成"@dev"或"dev-main"——缺一不可,否则composer install静默跳过,只报could not find package。

必须三者同时满足:项目 composer.json 正确声明 repositories 为 path 类型、本地包 composer.json 的 name 与 require 中完全一致、require 版本写成 "@dev" 或 "dev-main"——缺一不可,否则 composer install 静默跳过,只报 Could not find package。
repositories 字段怎么写才被识别
Composer 不会自动扫描同级或子目录,它只认你项目根目录 composer.json 里 repositories 字段声明的内容。这个字段必须是顶层数组,不能嵌在 config 或 require 里。
-
url必须是相对路径(如"../my-package")或绝对路径(如/Users/me/my-package),不能带file://前缀,也不能用~ - Windows 下路径要用正斜杠
/(如C:/dev/my-package),单反斜杠\会导致解析失败 - 该路径必须已存在,且目录下有合法的
composer.json(无语法错误、双引号、无尾逗号) - 通配符支持
packages/*,但不支持多层(packages/**无效)
require 写什么版本才能命中本地包
Path 仓库不走语义化版本解析,也不查 Git 分支,它只做字符串比对或通配匹配。写错版本号,Composer 就直接放弃本地路径,转头去 Packagist 找。
工作流任务拆解与模型编排技能。使用场景:(1) 收到复杂工作任务需要拆解为可执行步骤,(2) 需要为不同步骤选择最合适的模型,(3) 需要跟踪工作流进度和模型使用情况,(4) 长时间任务卡住需要问题诊断和解决方案。
- 最稳妥是写
"myorg/utils": "@dev"——这是唯一能通配任意本地包的写法 - 写
"dev-main"会触发分支查找逻辑,而本地路径下没 Git,必然失败(除非你手动git init并提交) - 如果本地包
composer.json明确写了"version": "1.0.0",那"1.0.0"也能命中,但不如@dev灵活 - 大小写、vendor 名、分隔符
/必须和本地包name字段完全一致,MyOrg/Utils≠myorg/utils
怎么让改代码实时生效(不是复制而是软链接)
默认行为就是复制,这是 Composer 为构建稳定性做的保守设计。软链接(symlink)必须显式启用,且只对 path 类型仓库生效。
- 推荐方式:在本地包自己的
composer.json中加"options": {"symlink": true}(注意:不是主项目的配置) - 替代方式:主项目
composer.json的config里设"preferred-install": {"myorg/utils": "source"} -
composer install不创建 symlink;必须执行composer update myorg/utils或全量composer update - 验证是否成功:
ls -la vendor/myorg/utils(macOS/Linux)应显示->指向源路径;Windows 用户可用dir vendor\myorg\utils看是否为“快捷方式”类型
改了本地包代码却不生效?别只盯 require
软链接建好了,不代表类就能自动加载。常见问题其实是 autoload 没更新,或者本地包自己改了命名空间但没同步 autoload 配置。
- 你在本地包里删文件、改命名空间、加新
psr-4映射,下游项目立刻报错——因为没重新dump-autoload - 改完本地包的
composer.json(比如加了个新psr-4映射),必须在主项目运行composer dump-autoload - 如果怀疑软链损坏,可删掉
vendor/vendor/name再composer update vendor/name - CI 环境通常禁用
path源,上线前必须删掉repositories里的path条目,否则构建可能失败
最容易被忽略的是本地包 composer.json 里缺 autoload 配置,或者 name 字段格式不规范(含大写字母、下划线、空格),这会让 Composer 在静默中跳过整个仓库,连错误提示都不给。










