子模块中运行composer install失败主因是路径污染或未初始化子模块；应进入子模块目录确认路径、清理残留vendor/和composer.lock后执行；ci中需显式运行git submodule update --init --recursive。
Git 子模块不是 Composer 包，直接在子模块里运行 composer install 很容易失败——根本原因不是命令不对，而是路径、autoload 和 vendor 目录被父项目污染了。
子模块里运行 composer install 为什么总报错？
常见错误现象包括：Class not found、vendor/autoload.php not found、或安装后类加载指向父项目而非子模块。这不是 Composer 本身的问题，而是因为：
- 你在父项目根目录下误执行了
composer install --working-dir=modules/foo—— Composer 不保证跨目录 autoload 正确加载子模块的依赖 - 子模块目录里残留了从别人 clone 来的
vendor/或composer.lock，内容和当前composer.json不匹配 - 父项目的 autoloader 已提前加载，导致子模块的
autoload.php被跳过或覆盖
实操建议：进入子模块目录后，先用 pwd 确认路径；删掉 vendor/ 和 composer.lock；再运行 composer install。CI 中必须加 git submodule update --init --recursive，否则子模块目录为空。
子模块的命名空间和 autoload 怎么不跟父项目打架？
如果父项目和子模块都用了 "psr-4": {"App\": "src/"}，那自动加载器只会注册最后一个，且无法预测顺序。结果就是调用时实际执行的是错的类。
必须做到：
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
- 子模块
composer.json的name字段要唯一，比如"myorg/user-module"，不能和父项目重名 -
autoload必须声明独立前缀，如"MyOrg\UserModule\"，且不能与父项目任何命名空间重叠 - 父项目
composer.json的autoload段里，绝对不要包含子模块源码路径（例如"./modules/user-module/src"）
子模块应通过它自己的 vendor/autoload.php 加载，而不是被父项目“捎带”进来。
想让父项目真正依赖子模块？别用 git submodule
Git 子模块只是代码快照，没有版本约束、不参与依赖解析、无法 composer require。你改了子模块的 composer.json，父项目根本感知不到。
正确做法是把子模块变成本地可安装包：
- 在父项目
composer.json的repositories里加 path 类型源：{"type":"path","url":"./modules/user-module"} - 确保子模块
composer.json里有匹配的name（如"myorg/user-module"）和合法autoload - 运行
composer require myorg/user-module:dev-main—— 这会软链接子模块到vendor/myorg/user-module，并写入composer.lock
这样子模块的依赖才真正纳入整个项目的依赖图，composer update 才能协调版本冲突。
最易被忽略的一点：子模块一旦被 require 进父项目，它就不再是“子模块”了，而是一个本地包。此时应删掉 .gitmodules 和 git submodule add 的痕迹，否则 Git 和 Composer 两套机制会互相干扰。
