中文镜像不影响alpha版本筛选，是否安装alpha完全取决于本地composer.json的minimum-stability和prefer-stable配置；镜像仅加速元数据分发，不修改或过滤稳定性标签。
中文镜像本身不控制Alpha版本是否被拉取
Composer 中文镜像（如阿里云、清华源）只是把 Packagist 的元数据缓存并加速分发，它不会过滤或改写包的稳定性标签。你看到的 alpha、beta 版本是否出现，完全取决于你本地 composer.json 的配置，和镜像无关。
常见误解是“换镜像就能避开 Alpha”，其实镜像只影响下载速度和可用性，不影响版本筛选逻辑。
- 镜像返回的
packages.json里包含所有已发布版本（含@alpha），Composer 拿到后仍按你设的minimum-stability做过滤 - 即使镜像返回了
monolog/monolog 3.0.0@alpha，只要你的minimum-stability是stable，它就直接被跳过，连安装步骤都不会进入 - 如果你发现装出了 Alpha 版，一定是你本地配置开了口子，不是镜像“漏放”了
真正起作用的是 minimum-stability 和 prefer-stable
Composer 默认只认 stable，想跳过 Alpha 版本，不需要动镜像，只需确保这两个字段没意外放宽：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"minimum-stability": "stable"—— 这是默认值，别删也别改成alpha、beta或dev -
"prefer-stable": true—— 写在composer.json根层级，不是config下；它不阻止 Alpha，但能防止 Composer 在多个候选中“误选” Alpha - 检查是否有某一行
require显式写了@alpha或dev-main@dev，这种写法会绕过全局规则 - 运行
composer show monolog/monolog --all看当前源（不管是不是镜像）到底暴露了哪些版本，确认 Alpha 是否真在列表里
为什么换了镜像后突然装上 Alpha 版？
这不是镜像“主动推送”，而是你之前用的镜像恰好缓存滞后，没同步到最新 Alpha tag；新镜像刷新及时，把刚发布的 @alpha 元数据同步下来了，而你的 minimum-stability 又刚好设成了 beta 或更低。
- 清华源、阿里云源更新频率不同，有的每分钟同步，有的延迟数分钟——这会影响你“看到”的版本集合
- 执行
composer clear-cache后再composer update，会强制重新拉取元数据，可能暴露出之前没见到的 Alpha 版 - 如果项目里有
"monolog/monolog": "^3.0.0"，而3.0.0@alpha是满足该约束的最高版本，且你设了"minimum-stability": "alpha"，那它就会被装上 - 别依赖镜像“不推 Alpha”来规避风险，Alpha 是否出现，100% 由你自己的配置和上游发布节奏决定
临时禁用 Alpha 的最快方式
不想改全局配置，又急需屏蔽某个包的 Alpha 版？直接锁死版本号，比调 minimum-stability 更精准：
- 用具体稳定版号替代模糊约束：
"monolog/monolog": "2.10.0"（不是"^2.0"） - 加
@stable后缀："monolog/monolog": "3.0.0@stable"，明确告诉 Composer 只接受 stable 标签 - 如果已装了 Alpha 版，运行
composer require monolog/monolog:2.10.0 --update-with-dependencies，它会降级并协调依赖链 - 避免用
composer update monolog/monolog单独升级——它可能又拉回 Alpha，除非你同时加--with-all-dependencies并确认约束足够硬
^3.0 在 Alpha 阶段基本失效；你得盯紧它的发布节奏，随时准备切回 RC 或 stable 分支。
