path仓库不能上生产环境，因其依赖本地路径、符号链接和未版本化代码，在CI/CD或容器中不可靠，易致部署失败或运行时类加载中断。
path仓库为什么不能上生产环境
path类型仓库本质是开发期调试机制，它依赖本地文件系统路径、符号链接和未版本化的代码——这些在CI/CD流水线或容器镜像中根本不可靠。一旦误用，会导致部署失败、类加载中断，或更隐蔽的问题：比如vendor/my-vendor/my-pkg在构建时是软链，上线后变成空目录或404，但错误直到运行时才暴露。
如何识别项目里混入了path依赖
执行composer show --locked，检查输出中是否含type: path字段；再运行composer config repositories，确认repositories配置里没有"type": "path"条目。常见漏点：
- 开发人员提交了带
repositories的composer.json，但没删掉path段 -
composer.lock里已记录了path包的哈希，即使composer.json已清理，install仍会尝试解析该路径（并静默失败） - 全局配置被污染：
composer config -g repositories.mydev在CI机器上残留，影响所有项目
CI阶段自动拦截path依赖的实操方法
在CI脚本开头加校验逻辑，避免打包含path依赖的产物：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
grep -q '"type"\s*:\s*"path"' composer.json检测配置文件 - 用
jq -e '.packages[] | select(.type == "path")' composer.lock >/dev/null 2>&1检查lock文件是否含path包 - Dockerfile中禁止
COPY . /app前不做清理：加RUN sed -i '/"type": "path"/d' composer.json || true（谨慎使用，仅作兜底） - GitHub Actions里用
actions/checkout@v4后立即跑校验脚本，失败则exit 1
真正安全的替代方案
生产环境必须用可版本化、可审计、可缓存的依赖源：
- 私有Packagist（如Satis、Private Packagist）——把本地包打
git tag后发布为稳定版本 - Git仓库直接引用：
"my-vendor/my-pkg": "dev-main#commit-hash"，配合"type": "vcs"，不依赖本地路径 - 构建阶段预编译：CI里先
composer install --no-dev生成完整vendor/，再打包镜像，彻底剥离composer命令依赖
path仓库只应在开发者本机启用，且必须确保其配置不进入composer.json提交历史或CI上下文——这点最容易被忽略，也是线上故障最常发源地。
