Composer install 报“Could not fetch”主因是HTTPS协议被拦截或认证失败，需用git ls-remote验证Git层连通性，优先改repositories为vcs+SSH URL而非全局强制SSH。
composer install 时提示 “Could not fetch https://github.com/xxx/xxx”
这是最常见的情况：Composer 默认用 HTTPS 协议拉取 Git 仓库，但公司内网、某些代理或 SSH 密钥配置下，HTTPS 访问会被拦截或拒绝。不是网络不通，而是认证失败或协议被重定向干扰。
- 先运行
git ls-remote -h https://github.com/vendor/package.git，看是否能拿到 refs —— 如果失败，说明问题出在 Git 层，Composer 只是“背锅” - 临时改用 SSH 协议：把
"vendor/package": "dev-main"对应的仓库 URL 改成git@github.com:vendor/package.git，并在composer.json的repositories里显式声明类型为vcs - 别直接改 global config 强制走 SSH（比如
git config --global url."git@github.com:".insteadOf "https://github.com/"），这会影响所有项目，且 CI 环境通常没配 SSH key
require 一个私有 Git 仓库时，composer.json 怎么写才有效
Composer 不会自动猜你想要哪个分支或 commit，也不默认信任任意 Git 地址；必须明确声明仓库来源 + 版本约束，否则报 Could not find package xxx at any version。
- 在
composer.json顶层加repositories数组，每个项包含type: "vcs"和url（支持 HTTPS / SSH / Git 协议） -
require中的版本号不能写dev-master这种模糊值（除非仓库有composer.json且含version字段），推荐用dev-main、dev-develop或具体 commit hash（如dev-abc1234） - 私有仓库若没公开 packagist.org 元数据，
minimum-stability得设为"dev"，否则dev-*分支会被跳过
为什么 composer update 拉下来的是旧 commit，不是最新 main 分支
Composer 缓存了 Git 仓库的元信息（tag、branch head），不会每次自动 git fetch --all。尤其当你本地已安装过某个 dev 分支，它就锁死在当时的 commit 上，除非你强制刷新。
- 执行
composer update vendor/package --with-dependencies，比install更可能触发更新 - 加
-v参数看日志，确认 Composer 实际 fetch 的 ref 是什么（例如Cloning abc1234 from cache） - 彻底清缓存：删掉
vendor/composer/installed.json和~/.composer/cache/vcs/下对应仓库目录，再update - 更稳的做法：用
dev-main#abc1234这种带 commit hash 的写法，避免分支指针漂移
Git 仓库没写 composer.json，还能被 require 吗
不能。Composer 安装包的本质是读取目标仓库根目录下的 composer.json，提取 name、autoload、require 等字段。没有它，Composer 根本不知道这是个包，更不会解析 autoload 规则。
- 如果只是想加载代码，用
path类型仓库（"type": "path"）+ 本地 symlink，不走 Git - 如果必须走 Git，至少得在仓库根目录放一个最简
composer.json，哪怕只有{"name": "vendor/name", "autoload": {"psr-4": {"Vendor\": "src/"}}} - 别指望靠
package类型仓库硬塞元数据——它要求你手动写全所有字段，包括dist和source，维护成本远高于补一个composer.json
composer.json 是否存在 —— 这五个点只要漏掉一个，安装就会卡住或装错。实际排障时，优先用 git ls-remote 和 composer update -v 看真实行为，而不是反复改配置。 
