“invalid repository url”是协议白名单拦截，composer解析repositories时发现url协议不在默认白名单（仅https、git、http），如ssh://、lfs+https://等会直接校验失败；修复需改用合法协议或删除repositories块。
Composer报“invalid repository URL”是协议被拦截
这个错误不是网络不通，而是Composer在解析repositories配置时，发现URL协议不在白名单里。默认只允许https、git、http，像ssh://、file://或自定义协议（如lfs+https://）会直接触发校验失败。
常见诱因：
- 在
composer.json里写了"url": "lfs+https://example.com/repo.git"——Composer不认识lfs+前缀 - 私有Git仓库用了
ssh://git@host:port/repo.git，但没加"type": "vcs"且协议未显式列入白名单（Composer 2.9.6仍不支持动态扩展协议） - 复制了别人CI脚本里的
git+ssh写法，却没注意该环境已通过composer config --global repo.packagist.allow-unstable true之类方式绕过限制
修复方式只有两种：composer.json中改用https或git协议；或删掉整个repositories块，让Composer走Packagist默认源。
Git LFS文件在vendor里变成指针文本？
执行composer install后，进入vendor/some/package，打开一个本该是二进制的文件（比如model.bin），内容却是：
version https://git-lfs.com/spec/v1 oid sha256:abc123... size 104857600
说明Git LFS没生效，不是Composer的问题，而是底层Git环境缺失LFS支持。
必须逐项确认：
- 运行
git lfs install是否成功（返回Updated git hooks才算） -
git config --get filter.lfs.process输出是否为git-lfs filter-process - 该包仓库根目录是否存在
.gitattributes，且含model.bin filter=lfs这一行 - CI/CD中是否漏掉了
git lfs pull——尤其GitHub Actions默认actions/checkout@v4不拉LFS，得手动加一步git lfs pull
为什么不能在composer.json里直接写git lfs命令？
Composer不解析也不执行任何LFS指令。git lfs track、git lfs install全是Git层面的操作，Composer只调用git clone和git checkout。它甚至不知道LFS存在。
这意味着：
- 你不能在
scripts里写"post-install-cmd": "git lfs pull"来自动修复——因为vendor下的包目录是独立Git仓库，git lfs pull需在各自目录下执行，而Composer不帮你cd进去 -
composer update期间不会重跑git lfs install，哪怕你本地没装LFS，它也照常clone，只留下一堆指针 - 若依赖包本身没提交
.gitattributes，哪怕你本地LFS全开，也没用——规则不在仓库里，Git就不知道该对哪些文件启用LFS
大文件到底该不该放进Composer包？
不该。这不是技术能不能做到的问题，而是协作链路会断裂。
典型后果：
- 团队成员
composer install卡住半小时，没人知道是等LFS下载还是网络故障 - CI构建失败日志里只显示
git clone timeout，实际是LFS服务器响应慢 - 某天GitHub LFS服务临时不可用，所有依赖安装中断，连带整个发布流程停摆
- 包体积超200MB后，Packagist会拒绝索引，导致
composer require找不到包
真正可持续的做法：把大文件扔到CDN或S3，代码里用file_get_contents('https://cdn.example.com/model.bin')或构建脚本下载，再由post-install-cmd触发校验与缓存。Composer只管代码，不管资源。
