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上下文——这点最容易被忽略，也是线上故障最常发源地。