必须用纯字符串如"monolog/monolog": "2.9.1"锁死版本，^~*dev-等修饰符会导致漂移；改composer.json后需运行composer update vendor/package更新lock文件，或直接composer require vendor/package:1.2.3。
composer.json 里怎么写死一个包的精确版本
必须用不带任何修饰符的纯字符串，比如 "monolog/monolog": "2.9.1"。加 ^、~、* 或 dev- 前缀都不算“固定”，它们都会在 composer update 时漂移。
常见错误写法："guzzlehttp/guzzle": "^7.5" 允许升级到 7.9.0；"laravel/framework": "10.*" 实际等价于 ~10.0，仍可能升到 10.42.0。
-
"vendor/package": "1.2.3"—— 真正锁死，install 和 update 都不会动它（除非其他依赖强制要求更高版） - 如果包名含破折号或版本含 RC/beta，务必用双引号包裹整个值，防止 shell 解析失败
- 大小写敏感：
"Monolog/Monolog"会报错，正确是"monolog/monolog"
为什么改完 composer.json 还是装不上指定版本
因为 composer install 只读 composer.lock，根本不看 composer.json 里新写的版本——除非 lock 文件不存在或被删了。
你手动改了 composer.json 后直接跑 composer install，它大概率继续装旧版，因为 lock 里还记着上一次的结果。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 正确流程：改完
composer.json→ 运行composer update vendor/package（只更新该包）→ lock 文件重写 → 再composer install才生效 - 更省事的做法：跳过手动改 json，直接
composer require vendor/package:1.2.3，它自动完成写入 + 更新 lock - 如果
composer.lock被删了，install会退化为update行为，这时才真正按 json 解析——但结果不可控，可能拉到意外版本
装不上指定版本时，先查这三件事
报 No matching package found 不是命令写错了，而是版本根本没发布、被弃用，或稳定性不匹配。
- 去 Packagist 搜
vendor/package，确认你要的1.2.3是否存在、状态是否为stable - 运行
composer show -a vendor/package查所有可用版本，包括RC、beta、dev-main - 如果版本是
9.0.0-RC1但项目minimum-stability是stable，得加参数：composer require vendor/package:9.0.0-RC1 --stability=RC
composer.lock 不能替代 composer.json 的版本声明
lock 文件只保障“当前项目这次能还原”，但它不防人手误删、不防 CI 流水线没提交 lock、也不防团队里有人跑了一次 composer update 就提交了新 lock。
真正需要长期稳定的场景（比如生产镜像、SaaS 多租户部署），关键包必须在 composer.json 里钉死。否则某天 CI 构建突然拉到新版，runtime 报错才发现晚了。
- lock 是快照，json 是契约；契约没写清楚，快照就不可信
- 某些托管平台（如 Laravel Vapor、Platform.sh）默认不传 lock，只靠 json 声明来决定装什么
- 写了精确版本后，
composer update仍可能提示冲突，比如其他包要求guzzlehttp/guzzle ^8.0—— 这时候不是工具问题，是依赖关系本身需要调整
