minimum-stability是composer.json根级字段，值为小写dev/alpha/beta/rc/stable（rc须全大写），仅约束未显式标注稳定性的依赖；必须配合prefer-stable:true才能在候选版本中优先选更稳版本，且修改后需运行composer update --lock生效。
minimum-stability 必须写在 composer.json 顶层
它不是命令行参数，也不是 config 或 extra 下的子字段——放错位置就完全无效。正确位置是和 require、autoload 同级的根对象字段：
{
"minimum-stability": "beta",
"prefer-stable": true,
"require": {
"php": "^8.2",
"monolog/monolog": "^3.0"
}
}
常见错误包括：塞进 config 里、写成 minimum_stability（下划线）、或用大写 Beta。合法值只有小写的 dev、alpha、beta、RC、stable（注意 RC 必须全大写，rc 会被忽略）。
@dev 后缀比改 global minimum-stability 更安全
想装 dev-main 分支却报 No matching package found？根本原因不是包不存在，而是 dev-main 被默认过滤掉了。此时最稳妥的做法不是把整个项目的 minimum-stability 改成 dev（那会连 laravel/framework 都去拉 dev-main），而是直接加 @dev 后缀：
composer require vendor/package:dev-main@dev- 或在
require中写："vendor/package": "dev-main@dev" - 漏掉
@dev就等于没授权，dev-main本身不带任何放行语义
同理，@beta 可匹配 alpha 和 beta 版本，但不会匹配 dev-main；@RC 才能命中 1.0.0-rc.1，写成 @rc 无效。
prefer-stable: true 不是可选项，是防坑刚需
只设 "minimum-stability": "beta"，不配 "prefer-stable": true，Composer 在满足约束的前提下会优先选“最新”的版本，而不是“最稳”的。比如某包同时有 2.5.0（stable）和 2.6.0-beta2（beta），它大概率装后者——哪怕你只是想升级小版本。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
prefer-stable: true 的作用非常具体：在所有满足 minimum-stability 的候选版本中，挑稳定性更高的那个。它必须和 minimum-stability 同时存在才生效，单独写没意义。
- 生产环境推荐组合：
"minimum-stability": "stable"+"prefer-stable": true - 测试环境若需 beta，用
"minimum-stability": "beta"+"prefer-stable": true，避免意外装到 alpha - CI 环境漏配
prefer-stable，可能导致本地与构建环境行为不一致
改完 composer.json 后必须运行 composer update --lock
修改 minimum-stability 或 prefer-stable 不会自动刷新 composer.lock。不执行这一步，新配置对已锁版本完全无影响——composer install 仍按旧锁文件还原，composer show 也看不到变化。
关键点：
-
composer update --lock是轻量操作：只重算锁文件，不下载包，也不改vendor/ - 如果要立即验证效果，可跟
composer update vendor/package单独更新目标包 - 它只影响“未显式标注稳定性”的依赖。例如
"monolog/monolog": "^3.0@stable"完全绕过该设置
真正容易被忽略的是：这个配置不回滚已安装的非稳定版——它只管后续的 require 和 update 行为。想清理历史遗留的 dev- 提交，得手动删 vendor/ 并重装，或用 composer update --with-all-dependencies 精准控制范围。
