漏掉--no-update会导致依赖重解，验证需三步：1. composer show确认version=1.2.3且stability=stable；2. 检查composer.lock中version、source.type=dist、dist.url含1.2.3；3. 查vendor下文件时间戳是否匹配该版本发布日期。
composer require 时漏掉 --no-update 怎么验证
执行 composer require vendor/package:1.2.3 后，如果没加 --no-update，Composer 默认会触发完整依赖重解，可能连带升级其他包——这和“钉死单个版本”的初衷完全相悖。验证是否真按你预期锁定了版本，不能只看 composer.json 写对了没有。
关键检查点：
- 运行
composer show vendor/package，输出的 version 字段必须是1.2.3（不是1.2.3.0或v1.2.3），且 stability 显示stable - 检查
composer.lock中对应条目：version字段值、source.type是否为dist、dist.url是否指向含1.2.3的 ZIP 路径 - 若项目已上线，再跑一次
composer install（不带--no-dev等参数），确认 vendor 目录下该包实际解压的文件时间戳与 1.2.3 版本发布日期吻合
自定义仓库（如 path）软链接是否真生效
配完 "type": "path" 并执行 composer update 后，终端可能显示 Symlinking vendor/name/package，但这只是缓存提示，不代表真实链接成功。很多问题出在 name、url、symlink 三者没同时满足硬性条件。
验证方式必须落地到文件系统：
- Linux/macOS：运行
ls -la vendor/vendor-name/package-name，输出中必须含->符号，且指向你本地目录的绝对路径（如/Users/me/my-package） - Windows：运行
dir vendor\vendor-name\package-name，看到<symlinkd></symlinkd>标识才算成功；若显示普通目录，说明 fallback 成了拷贝 - 再补一招：修改本地包源码，然后在项目里调用该包任意公开方法，看是否立即生效——符号链接下改即见，拷贝则必须重新
composer update
镜像源配置后怎么确认请求真走新地址
只运行 composer config -g repo.packagist 看到 URL 是不够的。Composer 会缓存元数据，旧包信息仍可能从老地址拉取，导致“配置写了，但速度没变、404 还在”。
真正有效的验证步骤：
- 先清缓存：
composer clear-cache（这步跳过，90% 的“不生效”就卡在这） - 用
-vvv观察真实请求：composer -vvv update --dry-run，日志里找GET https://xxx/composer/packages.json，URL 必须匹配你配置的镜像地址（注意末尾斜杠不能少） - 如果还失败，顺手删掉
composer.lock，再composer update --dry-run——lock 文件里存着旧 dist URL，不删它，install/update 都会绕过新配置直接复用
全局配置（如 GitHub token）是否被正确加载
运行 composer config -g github-oauth.github.com xxx 后，你以为认证就通了，但实际 composer update 仍报 Could not fetch。根本原因是 Composer 加载配置有优先级，且敏感字段默认不显示。
验证要点：
- 查真实生效路径：
composer config -g --list --verbose，第一行Loaded config file:必须是你预期的路径（比如/Users/me/.composer/config.json），而不是/root/.composer/config.json - 确认 token 没被隐藏：
composer config -g --show-passwords | grep github-oauth，输出应为明文 token，而非*** - 测试连通性：
composer diagnose，重点看GitHub API: OK行；若报Failed to get data，大概率是 token 权限不足或域名拼错（必须是github.com，不是api.github.com）
config -l 只给你结果，不告诉你哪一层覆盖了哪一层。想准确定位，得靠 --verbose + diagnose 组合观察，而不是盯着一个 JSON 文件反复改。 
