私有仓库是PHP模块化开发的基础设施；Composer默认优先查packagist.org，需在repositories中设"packagist.org": false并正确配置type为composer、URL末尾带/且含/api/composer/或指向packages.json。
私有仓库不是“可选配件”，而是企业PHP模块化开发的基础设施——没它，模块就只是散落的Git仓库，不是可复用、可审计、可管控的组件。
为什么composer.json加了私有仓库URL还是找不到包
根本原因不是URL写错，是Composer默认仍会先查packagist.org，私有源只是fallback。哪怕你写了Satis或Artifactory地址，只要没关掉默认源，composer require vendor/package就会静默跳过你的私有包。
- 必须在项目级
composer.json中显式禁用："packagist.org": false（这一行不能省，漏掉就报Could not find package vendor/name） -
repositories数组里，私有源类型必须是"type": "composer"，不是vcs——vcs只适用于单个Git仓库，不支持packages.json元数据发现 - URL末尾的斜杠
/不可省略，少一个就404；路径中必须含/api/composer/（Artifactory）或直接指向packages.json（Satis）
Satis静态仓库构建后composer update仍走外网
Satis不提供API服务，只生成静态文件。如果composer update还在连packagist.org，说明客户端根本没读到你的镜像源。
- 用
curl -I https://satis.example.com/packages.json确认能返回200 OK；Nginx返回403/404时，Composer会静默降级 - 项目
composer.json里的url值必须以/结尾，否则Composer解析失败后自动 fallback - 检查
composer config --list | grep repositories，确认没有全局配置覆盖了项目级设置
Artifactory上创建Composer仓库最容易配错的三项
不是所有仓库类型都能被Composer识别。Artifactory必须创建原生composer类型仓库，Generic、Remote（非composer）、Virtual（未启用composer协议）都会导致composer install直接失败。
- 仓库类型选
Local/Remote/Virtual都可以，但“Package Type”下拉框必须手动选composer（不是默认值） - Remote仓库的
URL字段填的是上游源（如https://packagist.org），不是你自己的Git地址；若想代理Packagist，这里必须填官方地址 - Virtual仓库的
Repositories列表里，必须把已启用的composer本地/远程仓库拖进去，且勾选Enable Default Deployment Repository，否则composer publish会拒绝上传
真正卡住团队的，往往不是搭建步骤，而是权限链路上某个没声明的false、少写的/、或错选的Package Type——这些地方没日志、不报错、只静默失效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
