Composer“版本锁死”源于composer.lock固定commit hash，update无反应是因复用本地元数据缓存；强制更新需先composer update --refresh清元数据，再composer update vendor/package --no-cache走网络下载。
Composer 提示“版本锁死”，不是命令失效，而是 composer.lock 文件已固定了 exact commit hash 或 dist shasum —— 它不看远程有没有新版本，只认 lock 里写的那一行。
为什么 composer update vendor/package 没反应？
常见现象：终端只输出 Nothing to install or update，甚至没出现 Downloading 行。这不是包没更新，而是 Composer 复用了本地缓存的元数据（cache/repo/ 下的 packages.json），根本没去镜像站查新版本。
- 镜像同步有延迟（阿里云、腾讯云通常 15–30 分钟），但 Composer 默认复用本地元数据，不会主动刷新
-
composer update vendor/package仅在当前元数据“可见版本池”里找匹配项，旧元数据=看不见新版本 - 即使删了
vendor/或加了--no-cache，只要元数据没刷新，它依然认为“没有可更新版本”
强制拉取镜像最新版的正确两步法
必须同时切断元数据缓存复用 + 强制走网络下载 ZIP，缺一不可：
- 先运行
composer update --refresh（Composer ≥ 2.5）：清掉cache/repo/下所有元数据，从当前镜像源重载packages.json - 紧接着执行
composer update vendor/package --no-cache：跳过 ZIP 缓存查找，强制发起https://请求下载
验证是否真拉了新包：终端必须出现 Downloading https://，且时间戳是当前秒级；否则仍是缓存兜底。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
只想重装某个包，不升级子依赖？
默认 composer update vendor/package 会连带升级它的子依赖（如 psr/log），容易引发隐式变更。安全做法是：
- 在
composer.json中把目标包写成精确版本号，例如"monolog/monolog": "3.6.0" - 执行
composer update monolog/monolog --no-update-with-dependencies（Composer 2.5+） - 加
--force-reinstall确保即使版本号不变，也强制重新下载 dist 包（修复损坏 zip 场景）
漏掉 --no-update-with-dependencies，就等于放任依赖树悄悄变动。
删 composer.lock 不等于“强制更新”
删 lock 后直接跑 composer install 会报错：Lock file does not exist. Run composer update to create it. 因为 install 的设计前提就是 lock 存在。
真正触发重算依赖的是 composer update —— 它读 composer.json 约束，调用 SAT 求解器，生成新 lock。所谓“强制”，本质是让求解器面对一个全新的、未被 lock 锁定的约束空间。这个过程无法跳过，也很难预测结果。
