Composer 的 path 仓库在生产环境直接报错且不 fallback 到远程源，因它严格检查本地路径是否存在；解决方式包括使用 Studio 插件实现环境隔离，或在 CI 中动态移除 path 配置并确保 composer.lock 由无 path 环境生成。
path仓库在生产环境直接报错，不会自动 fallback 到远程源
Composer 遇到 type: "path" 仓库时，会严格尝试访问配置的本地路径。如果路径不存在（比如生产服务器上没有 ../my-pkg），它会立即中止并抛出 Source path does not exist 或 Could not find package 错误——**不会退回到 Packagist 或其他仓库重试**。这是设计行为，不是 bug。
常见错误现象：
- CI 流水线里
composer install在 build 阶段失败，日志显示找不到本地路径 - 手动删掉
repositories段再部署能过，但开发又得反复改composer.json -
composer show --all在本地能看到包，在服务器上完全不出现
用 Studio 工具替代原生 path 仓库，开发/生产自动隔离
Studio 是专为解决该问题设计的 Composer 插件，它把本地包管理逻辑从 composer.json 移出，改为通过独立配置文件控制，天然支持环境隔离。
实操步骤：
- 全局安装：
composer global require franzl/studio - 在项目根目录建
studio.json（不进版本控制）：{ "paths": ["../my-pkg"] } - 本地开发时，
composer require vendor/my-pkg会自动链接到../my-pkg，且生成 symlink - 生产部署时，只要不运行
studio命令，Composer 就完全无视studio.json，只走composer.lock和远程源
关键优势：无需修改 composer.json、不污染版本库、composer install 在任意环境都行为一致。
CI/CD 中动态清理 repositories 配置更轻量，但需谨慎处理 lock 文件
若不想引入新工具，可在构建脚本中临时移除 path 仓库。但注意：lock 文件若含 path 包的 dist 信息，仍可能触发校验失败。
安全做法：
- CI 脚本开头执行：
composer config --unset repositories.my-path-repo - 紧接着运行：
composer install --no-dev --ignore-platform-reqs - 确保
composer.lock是由不含 path 配置的环境生成的（推荐在 CI 中首次生成 lock） - 禁止将开发机生成的、含 path 仓库记录的 lock 文件直接提交——Composer 2.5+ 会拒绝 install
风险点：如果 lock 文件里保留了 path 包的 dist.type: "path" 字段，即使 config 清空，install 仍可能报错。此时必须重新生成 lock。
本地包必须有对应远程源，否则线上无法兜底
所有被 path 引用的包，必须在 Packagist 或私有仓库中存在可访问的发布版本，并在 composer.json 的 require 中使用语义化版本约束（如 "vendor/my-pkg": "^2.1"），而非 "*"。
原因：
-
"*"会让 Composer 在无 path 时尝试解析最新版，但若该包尚未发布，就会失败 - 线上 install 依赖的是 lock 文件里的
dist.url和dist.shasum，这些必须指向真实可用的 ZIP 包 - 本地开发用 path，线上靠 lock + 远程源，二者才能真正解耦
最容易被忽略的一点：路径仓库只是开发加速手段，不是部署方案。它不改变依赖本身的可部署性要求——所有包仍需具备远程可达性。
