真正锁定版本只能写死如"vendor/package": "2.8.5"，不带任何符号；composer.lock是安装契约，生产环境必须用composer install而非update，且lock文件须提交至Git。
composer.json 里写死版本号才是真锁定
“锁定更新范围”这个说法容易误导——Composer 没有“范围锁定”这种中间态。你看到的 ^2.8、~2.8.0 或 2.8.* 全部允许自动升级，哪怕只升一个补丁号。真正阻止 composer update 动它，只有一条路："vendor/package": "2.8.5"，不带任何符号。
常见错误现象：改完 composer.json 后运行 composer update，结果包还是升了。原因通常是没删掉 vendor/ 和 composer.lock 中旧记录，或者执行的是无参数的全局 update，触发了整棵树重解析。
- 必须手动执行
composer update vendor/package（指定包名），才能让 lock 文件更新为该精确版本 - 如果包已被其他依赖间接引入，仅改 require 不够，得配合
composer why-not vendor/package:2.8.5查冲突源头 -
composer show vendor/package输出版本必须和composer.json完全一致，且composer update vendor/package返回Nothing to install or update才算锁牢
composer.lock 不是配置开关，而是安装契约
composer.lock 本身不控制行为，它只是快照。它的作用只在 composer install 时生效——此时 Composer 完全忽略 composer.json 的约束，只按 lock 文件里的 version、dist.sha256 和 source.reference 还原环境。
容易踩的坑：CI 脚本写成 composer update --no-interaction，结果上线版本和本地不一致。因为 update 会重新解析依赖树，绕过了 lock 的约束。
- 所有生产环境、CI 和新同事初始化项目，必须用
composer install，不是update -
composer install --locked是上线前最后一道校验：它会检查 lock 里每个包是否仍满足composer.json的约束，不满足直接报错 - lock 文件必须提交进 Git；漏提 = 锁定失效，哪怕
composer.json写得再死
临时跳过某包更新的实操命令
这不是长期锁定，而是调试或 CI 中压制某次变更。Composer 2.2+ 支持 --ignore，比拼包名列表更可靠：
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
composer update --ignore=laravel/framework 会跳过该包及其全部子依赖的版本检查和更新，但不影响其他包解析逻辑。
- 旧版 Composer（composer update symfony/console symfony/http-kernel，不写你想跳过的那个
-
--with参数不会跳过锁定：它只是把某个包拉进本次依赖图重计算，但若 lock 里已有满足约束的版本，它根本不动 - 慎用
--with-all-dependencies：它会让所有子依赖参与重解析，大幅拖慢速度，且可能意外升级非目标包
日志与验证不能只靠终端输出
终端里 composer update 显示 “Updating vendor/package (2.8.4 => 2.8.5)” 并不等于真的装上了。真正可信的是 composer.lock 文件内容和 vendor/ 目录下的实际代码。
验证步骤缺一不可：
- 打开
composer.lock，搜索包名，确认"version": "2.8.5"且"source": {"reference": "xxx"}是确定 commit hash - 进
vendor/vendor/package目录，看composer.json里声明的 version 是否匹配 - 运行
git status检查 lock 文件是否被修改；没变 = 本次操作未落地
最常被忽略的是 lock 文件的 Git 提交动作和 CI 中 install/update 的混用。只要 lock 存在且未被绕过，版本就不可漂移——但前提是没人手抖删了它，也没人在部署脚本里偷偷换成 update。
