Composer如何禁用默认Packagist仓库_Composer禁用默认Packagist策略-composer-PHP中文网

直接删掉 packagist.org 会导致 install 失败，因为 Composer 默认隐式启用它；必须显式设 "packagist": false 或 "packagist.org": false 才能真正禁用，且需置于 repositories 数组首位。

composer如何禁用默认packagist仓库_composer禁用默认packagist策略

为什么直接删掉 packagist.org 会导致 install 失败

Composer 默认会把 packagist.org 作为全局仓库（repository），即使你没显式声明。一旦你执行 composer config --unset repositories.packagist 或在 composer.json 里删掉它，Composer 并不会“禁用”它——而是把它还原成隐式启用状态。真正让 Composer 完全跳过 packagist.org 的唯一方式，是显式将其设为 false。

正确禁用 packagist.org 的两种写法

必须在项目根目录的 composer.json 中设置，不能只靠命令行临时配置（命令行改的是全局或当前项目 config，不覆盖仓库策略）：

方式一（推荐）：在 repositories 数组顶部加一个空对象并设 "packagist": false
方式二：用 "packagist.org": false（Composer 2.2+ 支持，更精确）

示例片段：

{
    "repositories": [
        {"packagist": false},
        {"type": "composer", "url": "https://my-private-repo.example.com/"}
    ]
}

注意：{"packagist": false} 必须是 repositories 数组里的第一个条目，否则会被后续的 packagist.org 隐式加载覆盖。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

禁用后 install/update 仍报错？检查这些点

常见失败不是因为禁用失败，而是依赖链里有包只存在于 packagist.org，又没被你私仓同步：

composer require vendor/package 会失败，除非该包已出现在你配置的其他仓库中
运行 composer update 时若 composer.lock 里还存着来自 packagist.org 的包版本，Composer 会尝试回源校验——此时需先删掉 lock 文件再重装
某些插件（如 composer/installers）可能被其他依赖间接引入，而它们未在你私仓发布，也会中断流程

私仓没镜像 packagist 全量包时怎么安全过渡

完全禁用 packagist.org 是高风险操作，尤其对已有项目。更稳妥的做法是保留它但降权：

把私仓放在 repositories 数组最前，packagist.org 放最后，并设 "packagist.org": {"type": "composer", "url": "https://packagist.org"} ——这样 Composer 优先查私仓，找不到才 fallback
用 composer config repositories.packagist.allow-plugins false 防止 packagist 相关插件干扰（仅限 Composer 2.2+）
上线前务必跑一遍 composer validate 和 composer install --no-dev 确认无网络依赖残留

真正的难点不在配置开关，而在厘清每个依赖的来源路径——composer show -t 和 composer depends vendor/package 比盲目禁用更有用。