镜像仅加速下载，不参与依赖分析；确认镜像生效需执行composer config repo.packagist（项目级）或composer config -g repo.packagist，输出含"url": "https://mirrors.aliyun.com/composer/"才有效；查反向依赖必须用composer why --tree，且目标包须已安装于vendor中。
镜像本身不参与依赖分析，只加速下载；查依赖关系必须用 Composer 原生命令，中文镜像对 composer why、composer depends、composer show --tree 等命令的输出毫无影响——它既不增强也不干扰逻辑判断。
怎么确认当前用的是哪个中文镜像
执行 composer config repo.packagist（项目级）或 composer config -g repo.packagist（全局），输出类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 才算生效。如果返回空或 "https://packagist.org"，说明没切镜像，所有依赖命令跑得慢，但结果完全一致。
查“谁把我拉进来的”必须用 composer why --tree
这个命令能还原真实依赖链，但有硬性前提：目标包必须已安装到 vendor/ 下。常见失败不是镜像问题，而是：
- 包名拼错：
monolog/monolog≠Monolog/monolog≠monolog，斜杠和大小写全敏感 - 包未安装：运行
composer show确认是否在列表里；若不在，先composer require vendor/package或composer install - 是
provide虚拟包（如psr/log）：why --tree可能静默无输出，此时改用composer show --tree | grep -B2 -A2 "psr/log"手动翻 - 末尾出现
your-project-name dev-main，才说明是你自己composer.json里写的require
composer depends 查不到包？先看它是不是被“悄悄带进来”的
composer depends vendor/package 只扫描你项目 composer.json 中显式声明的 require 和 require-dev，不查 vendor/ 里任何包的依赖文件。所以：
- 如果
ls vendor/vendor/package存在，但depends没结果，大概率是被某个已安装包（比如laravel/framework）作为子依赖拉进来的 - 此时应换用
composer why vendor/package，它会告诉你谁间接引入了它 - 加
--all参数才能看到根项目自身是否直接 require：例如composer depends --all psr/log - 旧版 Composer（depends，先
composer self-update
依赖冲突时别信报错里的模糊版本号
中文报错里常出现类似 don’t install laravel/sanctum:^3.0 的提示，但 composer why-not laravel/sanctum:^3.0 会失败——因为 ^3.0 是范围写法，why-not 只认完整版本号。
- 去
packagist.org查该包最新稳定版，填成laravel/sanctum:3.2.1这种格式再试 - 更推荐用
composer prohibits laravel/sanctum:3.2.1，它从阻断点出发，直接指出哪个已安装包锁死了依赖（例如spatie/laravel-backup v7.2.0 requires symfony/console ^5.4） - 输出里反复出现的包（如
symfony/console、monolog/monolog）往往是枢纽，优先盯住它们的版本约束 - 某行末尾标了
(locked to 5.4.32)，说明该版本已被composer.lock固定，删 lock 文件或加--with-all-dependencies才可能松动
真正容易被忽略的是：所有命令的结果都基于当前 vendor/ 和 composer.lock 的快照，不是 composer.json 的理想状态；改完配置不 composer update，树形结构就不会变。
