微服务多仓库下需用path repository实现本地联调，生产环境必须切换至私有仓库（如Satis）并提交composer.lock确保一致性，禁用dump-autoload -o避免类加载冲突。
微服务项目里直接用 composer install 会失败，因为 autoload 无法跨仓库解析
微服务天然拆分成多个独立仓库（如 user-service、order-service），每个都有自己的 composer.json。如果在某个服务中通过 "myorg/user-sdk": "dev-main" 引用另一个仓库的包，Composer 默认找不到——它只认 Packagist 或你显式配置的仓库源。
- 本地开发时，不能靠
git clone后手动cp文件，那会绕过依赖约束和自动加载 - 生产构建也不能把其他服务代码直接塞进
vendor/，这破坏隔离性且无法版本对齐 - 核心问题是：Composer 的
autoload只扫描vendor/下已安装的包，不支持“软链接整个外部 Git 仓库”
用 path repository + repositories 配置实现本地多仓联调
这是最轻量、无需私有 Packagist 的方案，适合开发阶段快速验证跨服务调用。关键在于告诉 Composer：“这个包不在远程，就在本机某路径下”。
{
"repositories": [
{
"type": "path",
"url": "../user-sdk"
}
],
"require": {
"myorg/user-sdk": "dev-main"
}
}
-
url必须是相对路径（从当前composer.json所在目录起算），且目标目录必须含合法composer.json - 引用的版本号（如
dev-main）需与目标仓库的分支名或标签完全一致，否则报Could not find package - 执行
composer update myorg/user-sdk后，Composer 会在vendor/myorg/user-sdk创建符号链接，而非复制文件 - 注意：该链接在 CI 构建时失效，仅限本地开发；上线前必须切回真实版本源（如私有 Satis）
生产环境必须用私有仓库（Satis / Private Packagist），否则无法保证一致性
CI 流水线每次拉取代码都得重新 composer install，而 path 源只存在于你本地磁盘。一旦构建机上没有 ../user-sdk 目录，整个流程就中断。
- Satis 是最简选择：用静态 JSON +
index.html模拟 Packagist，配合git archive打包发布 - 所有微服务的
composer.json统一加"repositories"指向内网 Satis 地址，不再写path - 发版流程变成：提交 SDK → 触发 Satis 构建 → 更新服务中
"myorg/user-sdk": "1.2.0"→composer update→ 提交 lock - 漏掉
composer.lock提交？CI 会因 hash 不一致拒绝部署——这是防止“本地能跑线上炸”的关键防线
composer dump-autoload -o 在微服务里不是优化，而是陷阱
很多团队为“提速”在部署脚本里加 composer dump-autoload -o，但在多仓结构下，这会导致 vendor/composer/autoload_classmap.php 错误地包含其他服务的类路径（尤其当用 path 源时）。
- 类名冲突：两个服务都定义了
App\\User\\Repository，但-o生成的 classmap 只保留最后一个扫描到的 - 自动加载失效：SDK 里新添的类没被重扫，而
-o又跳过 PSR-4 动态查找，直接返回 false - 正确做法：开发期用默认 autoload（PSR-4），上线用
composer install --no-dev --optimize-autoloader，让 Composer 自己决定是否生成 classmap
跨仓库依赖管理真正的复杂点不在命令怎么敲，而在于“什么时候该断开链接”。本地用 path 图方便，但只要进入测试环境，就必须切断所有本地路径依赖，用带签名的私有包强制收敛版本边界。
