Composer私有仓库必须支持版本别名才能实现灰度发布，因灰度本质是让部分项目临时切换新版本而其余保持旧版，而composer install默认只认稳定语义化版本或分支别名；无别名机制则无法使v1.2.*依赖指向不同代码源，Satis 1.2.0+原生支持、Private Packagist需开启开关，裸Apache等不支持者只能人工改version导致update不可控。
Composer私有仓库必须支持版本别名才能做灰度
灰度发布在 Composer 场景下本质是「让部分项目临时切换到新版本，其余保持旧版」，但 composer install 默认只认稳定语义化版本（如 1.2.3）或分支别名（如 dev-main）。没有别名机制，就无法让 v1.2.* 的依赖同时指向两个不同代码源。
所以第一步不是写发布脚本，而是确认你的私有仓库（如 Satis、Private Packagist 或自建 Packagist 镜像）是否支持 alias。比如在 composer.json 中声明：
{
"require": {
"vendor/package": "1.2.3 as 1.2.0"
}
}
这行的关键是 as 后面的版本号会被 Composer 当作真实约束来解析——灰度时只需把 1.2.0 指向新包，其他项目不改 composer.lock 就仍用旧版。
- 不支持 alias 的仓库（如裸 Apache 目录服务）无法实现真灰度，只能靠人工改
version字段骗过 Composer，但会导致composer update行为不可控 - Satis 从 1.2.0 起原生支持
aliases配置；Private Packagist 需开启「Version Aliasing」开关 - 别名不能跨主版本，
2.0.0 as 1.9.9会被 Composer 拒绝
用 Composer 的 platform config 控制灰度范围
单纯改仓库别名还不够——你得让指定团队、CI 环境或机器才拉新包。Composer 自身不提供环境路由，但可通过 platform 配置伪造一个“运行时特征”，再配合仓库的条件分发逻辑（比如 Nginx 根据请求头返回不同 packages.json）。
例如在灰度机器上执行：
composer config --global platform.php "8.2.99"
然后私有仓库的后端判断：若请求头含 X-Composer-Platform: 8.2.99，就返回带新别名的 packages.json；否则返回旧版。这个技巧绕过了 Composer 客户端限制，且不影响实际 PHP 版本。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 不要用
config.platform.ext-xxx模拟扩展——扩展检测开销大，且容易被composer validate报错 - PHP 版本号选高位（如
8.2.99）可确保不会与真实版本冲突，也方便 Nginx 正则匹配 - CI 中建议用
COMPOSER_PLATFORM_CONFIG环境变量注入，避免污染全局配置
lock 文件锁定是灰度生效的唯一可靠依据
很多人以为改完 composer.json + composer update 就完成灰度，其实只要 composer.lock 里还存着旧的 dist.reference，composer install 就永远不拉新包。灰度的本质是 lock 文件差异，不是 json 声明。
所以必须强制灰度环境生成新 lock：
- 禁止直接
git commit锁文件到主干——应单独提交到灰度分支，如release/v1.2.3-beta - CI 流水线中，灰度任务需执行
composer update vendor/package --with-dependencies --no-interaction，并仅提交变更的 lock 行 - 用
composer show -s vendor/package核对当前解析出的source reference是否与预期一致，别只信composer.json里的版本字符串
PHP 8.2+ 的 readonly class 会让私有包热替换失败
如果灰度包里用了 readonly class，而团队部分服务仍在 PHP 8.1 运行，composer install 不会报错，但运行时 ParseError: Syntax error 会直接中断。这不是 Composer 问题，是 PHP 解析器层面的兼容断层。
解决办法不是降级语法，而是提前拦截：
- 在私有仓库的
composer.json中显式声明"php": "^8.2"，并确保灰度 CI 的platform.php与之匹配 - 用
composer validate --strict在 PR 检查阶段卡住不兼容提交 - 别依赖
require-dev里的 PHP 版本提示——生产环境不会装 dev 依赖，该错还是错
灰度系统最易被忽略的点，其实是 PHP 大版本和 Composer 小版本的隐式耦合。比如 Composer 2.5+ 才完整支持 platform.php 的高位模拟，而很多团队还在用 2.2。没对齐这个，上面所有操作都白搭。
