根本原因是composer默认只查packagist.org，私有包未在项目级composer.json中配置repositories；必须声明type为vcs或composer的仓库url，且包名、大小写、分隔符须与私有包composer.json完全一致。
为什么 composer install 会找不到私有包或内部组件
根本原因不是 Composer 本身不支持，而是它默认只认 Packagist.org 上已注册的公开包。当你有公司内部 SDK、未开源的业务组件、或带特殊命名空间（如 corp/utils）但没提交到 Packagist 的 PHP 包时，Composer 就会报 Could not find package corp/utils 或 Package not found。这不是网络问题，是源配置缺失。
解决路径只有一条：告诉 Composer 去哪找——也就是配置自定义仓库（repository），而不是试图“绕过”或“伪造” Packagist。
- 必须在项目根目录的
composer.json中声明repositories字段，类型为vcs（Git）、package（单包描述）或composer（私有 Packagist 镜像服务） - 不能只改全局
config；项目级composer.json的repositories优先级最高，且可被团队共享 - 若用 Git 仓库，URL 必须可被 Composer 直接克隆（支持 HTTPS/SSH），且该仓库的
composer.json中需含合法name和version（如"name": "corp/logger"）
用 vcs 仓库拉取 Git 托管的非标准组件最稳妥
这是最常用也最可控的方式，尤其适合内部 GitLab、GitHub 私有库或 SVN（需额外插件）。Composer 会自动识别分支和 tag，并映射为版本号。
示例：你有个内部日志组件放在 git@gitlab.corp/logger，其 composer.json 写着 "name": "corp/logger", "version": "1.2.0"：
{
"repositories": [
{
"type": "vcs",
"url": "git@gitlab.corp/logger"
}
],
"require": {
"corp/logger": "^1.2"
}
}
- URL 支持 SSH（
git@gitlab...）和 HTTPS（https://gitlab.corp/logger），但 HTTPS 方式需确保机器已配置好凭据或使用 token（如https://token:x-oauth-basic@gitlab.corp/logger） - 如果目标仓库没有标准 Git tag，Composer 会 fallback 到
dev-master分支，此时 require 应写"corp/logger": "dev-master"，但不推荐用于生产 - 执行
composer update corp/logger会重新 fetch 远程 commit，但不会自动 pull 新 tag —— 新增 tag 后需手动composer clear-cache再 update
composer 类型仓库适合搭建私有 Packagist 镜像服务
当组件数量超过 5 个，或者需要统一权限、搜索、依赖图谱时，硬编码一堆 vcs 就难维护了。这时应部署一个兼容 Composer 协议的私有镜像服务，比如 satis 或 packagist.private。
关键点在于：这类服务对外暴露一个 packages.json 文件，而你的项目只需把整个服务地址当作一个 composer 类型仓库注册进去：
{
"repositories": [
{
"type": "composer",
"url": "https://packagist.corp"
}
]
}
- 这个
url必须能直接访问到https://packagist.corp/packages.json，否则 Composer 会静默跳过该仓库 - 私有镜像服务本身不托管代码，只索引你指定的 Git 仓库并生成元数据；所以仍需保证每个组件仓库的
composer.json是规范的 - 若镜像服务启用了 Basic Auth，必须在 URL 中带上凭证：
https://user:pass@packagist.corp，否则请求 401 且错误提示极不明确
别忽略 minimum-stability 和 prefer-stable 对私有包的影响
私有组件往往没有打正式 tag，或者只用 dev- 前缀分支开发，这时候即使仓库配置正确，composer install 仍可能失败或装错版本。
- 默认
minimum-stability是stable，意味着它拒绝安装任何带dev-、alpha、beta的版本 —— 即使你明确写了"corp/logger": "dev-main" - 解决方法是在
composer.json根级加："minimum-stability": "dev"，或更安全地只对特定包放宽："corp/logger": "dev-main as 1.0.0" -
prefer-stable: true会让 Composer 在满足约束前提下优先选 stable 版本，但如果你的私有包只有 dev 分支，它就永远装不上 —— 此时要么关掉prefer-stable，要么确保至少有一个 stable tag
真正麻烦的不是配置本身，而是团队成员各自本地的 composer.json 没同步这些设置，导致同一份代码在不同人机器上装出不同结果。建议把这些字段纳入项目模板或 CI 检查项。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
