根本原因是Composer缓存了已安装的包路径映射且vendor中残留symlink；需删除对应vendor目录、清缓存、确保require版本匹配git标签，并执行composer update包名。
为什么 composer.json 里改了 repositories 还不生效
Composer 不会自动“降级”本地 path 依赖为远程 git 依赖，哪怕你已经把 "type": "path" 的仓库删了、换成了 "type": "git"。根本原因是：Composer 缓存了已安装的包路径映射，且 vendor 里留着 symlink（符号链接）指向本地目录。
要真正切换，必须让 Composer “忘记”原来的 path 映射，并重新解析依赖图。
- 先删掉
vendor/your-vendor/your-package目录（别只删 symlink，要删整个包目录） - 运行
composer clear-cache—— 否则它可能从缓存还原旧的 path 安装逻辑 - 确认
composer.json中该包的require版本约束能匹配 git 仓库的 tag 或分支（比如"dev-main"或"^1.2"），否则 Composer 仍会跳过它 - 再执行
composer update your-vendor/your-package（不要用install，它不会重解依赖）
path 和 git 仓库配置的关键差异点
两者在 repositories 数组里的写法看似相似，但行为完全不同：
path 类型本质是“硬链接”，Composer 会直接 symlink 到本地路径，绕过版本解析；git 类型则走标准的 dist/source 下载 + composer.lock 锁定 commit hash 流程。
-
path仓库不需要composer.json里有"autoload"配置也能加载（因为是直接读文件），但git依赖必须有合法的composer.json，否则报Could not find package ... at any version -
path模式下修改本地代码会实时生效；git模式下必须git push+composer update才能更新 - 如果 git 仓库没打 tag，又用了
"^1.0"这类约束，Composer 默认只认带v前缀的 tag（如v1.0.0），否则会 fallback 到dev-main并警告
切换后 composer.lock 里哪些字段变了
这是验证是否真切换成功的最可靠方式。
打开 composer.lock，找到对应包的条目，对比前后：
-
"source"字段：path 模式下是{"type":"path","url":"../my-local-pkg","reference":""}；git 模式下变成{"type":"git","url":"https://github.com/xxx/yyy.git","reference":"a1b2c3..."} -
"dist"字段：path 没这个字段；git 模式下会有"url"（zip 包地址）和"shasum" -
"version"值：path 模式下通常是dev-main（无实际意义）；git 模式下是真实 tag（如1.2.3）或dev-main#abc123
CI 环境下切 git 依赖失败的常见原因
本地能切成功，CI 却报 Package your-vendor/your-package not found，大概率是权限或网络问题。
- 私有 git 仓库未配置 SSH key 或 token，导致 Composer 无法 clone —— 检查 CI 日志里是否有
Cloning into '/tmp/...'...失败提示 - 用了
https地址但没配auth.json，尤其 GitHub 私库在 2021 年后禁用密码认证，必须用 PAT（Personal Access Token） - CI 缓存了旧的
vendor或composer.lock，导致composer install跳过更新 —— 应该在 CI 中强制composer update --no-interaction或清空缓存
真正麻烦的不是改配置，而是 Composer 对 path 的“记忆”太强——它不提醒你删 vendor，也不告诉你 cache 里还存着旧路径。手动清理比等自动修复更可靠。
