私有包更新后composer update无反应，主因是未在repositories中显式声明私有源或其packages.json未包含新版本元数据；需验证源地址可访问、satis已重建并推送、客户端强制刷新元数据。
私有包发布新版本后 composer update 没反应，不是缓存没清，也不是网络不通，大概率是客户端根本没去你的私有源查数据，或者查了但源里压根没有那个版本的元数据。
为什么 composer update 完全跳过私有包
Composer 默认只查 packagist.org，除非你在项目 composer.json 的 repositories 里显式声明了私有源，且该源的 packages.json 文件已包含新版本的完整元数据（包括 version、dist、source 等字段）。
- 项目
composer.json中漏写repositories，或拼错类型（比如写成"type": "git"而非"type": "composer"） - 私有仓库服务（如 Satis）没重建，
packages.json还停留在旧 commit，新 tag 或分支未被扫描到 - 本地
composer.lock锁定了旧版本，而你执行的是composer update vendor/package，没加--with-dependencies，导致依赖链卡在上游 - 私有包的
version字段写死为dev-main，但 Satis 配置里没启用"require": {"vendor/package": "dev-main"}，默认只收录带 tag 的稳定版
如何确认新版本是否真进了私有源
别靠猜，直接验证 packages.json 内容是否更新。用浏览器或 curl 打开你的私有源地址（例如 https://packages.example.org/packages.json），搜索目标包名和新版本号。
- 如果搜不到新 version 字段，说明 Satis 构建失败或配置没覆盖该分支/tag
- 检查 Satis 配置文件中
"require-all": true—— 它只收已打 tag 的版本，不收dev-分支 - 想同时收
v2.1.0和dev-main，得写成"require": {"vendor/package": "dev-main || ^2.1"} - 构建时加
-v参数：php bin/satis build satis.json web/ -v，看日志里是否列出新 commit 或 tag
客户端怎么强制重载私有源元数据
Composer 缓存的是 packages.json 内容，不是包本身。即使你重建了 Satis，客户端仍可能复用旧缓存。
- 临时绕过缓存验证：运行
composer update --no-cache，适合 CI 环境快速确认是否源端问题 - 只清私有源缓存（不碰 packagist）：
composer config --unset repos.private，再重新添加：composer config repositories.private composer https://packages.example.org - 检查是否真从私有源加载：
composer show -p vendor/package，输出里的source行必须显示你的私有域名，而不是https://api.github.com/ - 删掉
composer.lock再跑composer update——大版本或分支变更时，这是最干净的做法
最容易被忽略的点：Satis 构建后没推送到可访问路径
很多人 rebuild 了 Satis，却忘了把生成的 web/ 目录同步到 Web 服务器根目录，或 Nginx/Apache 没配好静态文件访问权限。结果 packages.json 返回 404 或 403，Composer 就当这个源不存在，自动 fallback 到 packagist.org。
务必用 curl -I https://packages.example.org/packages.json 看 HTTP 状态码；若不是 200，所有后续操作都白搭。
