临时禁用 Composer 镜像的正确命令是使用 --repository-url=https://packagist.org 参数，该参数优先级最高，可覆盖项目级和全局配置，进程级生效、无副作用，执行后立即直连官方源。
临时禁用 Composer 镜像的正确命令
直接运行 composer install 或 composer update 时，Composer 默认会走已配置的镜像（比如阿里云、腾讯云或华为云镜像）。想临时绕过镜像、直连 packagist.org，**不能靠改 composer.json 或删全局配置**——那太慢且影响其他项目。真正有效的做法是加一个运行时参数：-d repo.packagist.org 不行，得用 --repository-url 覆盖默认源。
- 执行
composer update --repository-url=https://packagist.org，强制本次请求走官方源 - 同理，
composer require monolog/monolog --repository-url=https://packagist.org也生效 - 注意：这个参数必须写在命令末尾，且不能和
-v、--no-cache等混排顺序无关，但建议放在最后避免解析歧义
为什么不用 composer config -g repo.packagist 临时清空？
很多人试过 composer config -g --unset repos.packagist，以为能“临时关闭”，结果发现：这操作会永久修改全局配置（~/.composer/config.json），下次所有项目都受影响；而且即使你立刻 config -g repos.packagist ... 恢复，中间出错或中断就容易留坑。更麻烦的是，某些镜像配置是通过 repos.packagist.org 别名方式注入的（比如腾讯云镜像），--unset 根本不生效。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 全局配置改一次，就得手动还原，不适合“这次临时跑一下”的场景
-
--repository-url是进程级覆盖，退出即失效，无副作用 - 如果项目里
composer.json自己写了repositories，该参数仍优先级最高，能压倒项目级配置
遇到 404 或 “package not found” 怎么确认是否真走了官方源？
加了 --repository-url=https://packagist.org 后，如果报错信息里还出现镜像域名（比如 mirrors.cloud.tencent.com），说明你可能被项目级 repositories 或插件劫持了。Composer 的源解析顺序是：命令行参数 > 项目 composer.json > 全局 config.json > 默认源。
- 加
-v参数看详细日志：composer update -v --repository-url=https://packagist.org，搜Downloading https://packagist.org/这一行 - 如果看到
https://mirrors.cloud.tencent.com/packagist/，说明项目composer.json里有"repositories"块，得临时注释掉再试 - 某些公司内网环境会装
composer-plugin-mirror类插件，这类插件可能无视--repository-url，需检查composer global list输出
Windows 下 PowerShell 里执行失败？注意 URL 中的斜杠
PowerShell 对 URL 里的反斜杠和引号敏感，直接粘贴 composer update --repository-url=https://packagist.org 可能报错 “无法识别的参数”。这不是 Composer 问题，是 shell 解析导致的。
- 最稳妥写法：把 URL 用单引号包起来 ——
composer update --repository-url='https://packagist.org' - Windows CMD 下不用引号也通常能过，但 PowerShell 必须加，否则
/被当命令分隔符处理 - 如果 URL 里带查询参数（比如测试用
https://packagist.org?foo=1），双引号或单引号都必须加上，否则=和?会被 shell 截断
--repository-url，别碰配置文件。镜像本身没坏，只是有时候你得确认是不是它缓存了旧 metadata，或者你想验证某个包在官方源是否真存在——这时候直连才是最干净的验证路径。 
