composer self-update –preview 仅升级当前主版本内的预发布版（如v2.5.12→v2.6.0-RC1），不会跨主版本（如不升至v3.0.0-alpha）；需确认安装方式、php环境限制及网络连通性；–preview拉取有版本号的RC/Beta版，–snapshot拉取无版本号的每日开发快照。
为什么 composer self-update --preview 不等于“自动升到最新版”
很多人执行 composer self-update --preview 后发现没变化，或版本号纹丝不动——这不是命令失效，而是 Composer 默认只升级「当前主版本通道内」的预发布版。比如你当前是 v2.5.12，--preview 只会找 2.x 分支下的最新 RC/Beta（如 2.6.0-RC1），绝不会跳到 v3.0.0-alpha（除非明确加 --3，但截至 2026 年 1 月，v3 尚未开放稳定预览通道，强行指定会报错）。
执行 composer self-update --preview 前必须确认的三件事
- 当前安装方式：若用
apt、brew或宝塔面板安装，--preview通常被禁用或无效，应改用包管理器更新，或先卸载再手动安装 Phar - PHP 环境限制：某些面板（如宝塔）默认禁用
putenv()，会导致更新中途失败；可临时绕过：/www/server/php/74/bin/php -d "disable_functions=" /usr/bin/composer self-update --preview - 网络连通性：国内用户常因直连
getcomposer.org超时失败；可先设置镜像源（仅对 self-update 下载阶段生效）：export COMPOSER_HOME=~/.composer && composer self-update --preview -vvv，再配合curl -L https://mirrors.aliyun.com/composer/手动下载替换
--preview 和 --snapshot 的真实区别在哪
别被名字误导：--preview 实际拉取的是已打标签的预发布版（如 2.7.0-RC2），有版本号、有 changelog、相对可控；而 --snapshot 拉的是每日构建的开发快照（无固定版本号，类似 2.7-dev+20260124），可能含未合入主干的实验性改动，CI 流水线中一旦使用，极大概率导致依赖解析行为突变。
- 适合尝鲜但不压测：用
--preview验证新 CLI 参数（如composer require --interactive）或修复你正遇到的 bug - 慎用于自动化流程：CI 脚本里写
composer self-update --snapshot等于主动引入不可控变量，某天构建突然失败，排查点会卡在 Composer 自身而非你的代码 - 降级更简单：出问题直接
composer self-update --stable即可切回最新稳定版，无需重装
更新后必须验证的两个关键点
预览版不是“多按一次回车就完事”，尤其当你项目依赖较老的插件（如 fxp/composer-asset-plugin）或自定义 installer 时，行为兼容性可能已悄然改变。
- 运行
composer --version确认输出含-RC或-beta字样，而非仍显示stable - 在空目录下快速测试基础流程：
composer init -n && composer require monolog/monolog:^3，观察是否报Package operations: 1 install, 0 updates, 0 removals—— 若卡住、报dependency resolution错误或提示lock file is not up to date，说明底层 resolver 逻辑已有调整，不宜立即投入生产项目
预览版的价值在于提前暴露问题，而不是“抢先用上”。真正要跨主版本升级（比如从 v2 到 v3），官方文档和迁移指南比任何 --preview 都重要——别跳过那一步。