真正高频且安全的 Composer 命令仅约10个：install（严格按lock安装）、update（重算依赖并更新lock，需慎用）、require（自动写入+安装）、dump-autoload（刷新自动加载）、show（查版本或依赖树）；其余多为插件、别名或弃用项，盲目执行易破坏一致性。
Composer 没有“所有命令”的权威总览清单，官方刻意不提供——因为多数命令是插件、别名或已弃用的残留，盲目执行反而容易破坏依赖一致性。
哪些 composer 命令真正在项目中高频且安全？
日常开发真正需要反复敲的不到 10 个，其余要么极少用，要么有更稳妥的替代路径：
-
composer install：仅从composer.lock安装，**绝不跳过 lock 文件**；CI/CD 必用 -
composer update：重算依赖并更新composer.lock；加--dry-run先看变更再决定是否执行 -
composer require vendor/package：自动写入composer.json并安装；加--dev或--no-update控制行为 -
composer dump-autoload：仅刷新自动加载映射，比update快得多，改了类命名空间后必跑 -
composer show：查已安装包版本（composer show monolog/monolog）或依赖树（composer show -t）
composer update 的默认行为为什么危险？
它默认更新 所有 包到符合 composer.json 约束的最新版本，可能引入不兼容变更。尤其当你的 composer.json 写着 "^8.0"，而上游发布了 9.0，update 就可能直接升到 9.0 —— 即便你没改任何配置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 生产环境严禁直接运行
composer update，应限定范围：composer update vendor/package - 想锁死小版本？把
^换成~（如~8.2.0表示允许8.2.x，但不进8.3） - 检查潜在冲突：先跑
composer prohibits vendor/package:version，再决定是否升级
别信 composer global，它不是“全局工具管理器”
composer global require 把包装进 ~/.composer/vendor/bin/，看似方便，实则埋雷：
- 所有项目共享同一套全局依赖，版本冲突无法隔离
-
global下的二进制文件不会随项目composer.json变更而更新 - 推荐替代方案：
composer require --dev phpunit/phpunit+vendor/bin/phpunit，版本受控、可提交、可审计 - 真要全局工具？用
phive或shivammathur/homebrew-php（macOS），它们按哈希校验、支持多版本共存
遇到 Root package 'xxx' cannot be installed together with... 怎么办？
这是 Composer 7+ 引入的严格依赖检查报错，说明你在 composer.json 中同时声明了互斥的根依赖（比如两个包要求不同版本的 php 或同一扩展的不同版本）。
- 先运行
composer why-not vendor/package:version，看谁在阻止安装 - 检查
config.platform是否误设（例如设了"php": "8.0"却想装只支持8.2+的包） - 临时绕过？加
--ignore-platform-reqs，但仅限本地调试，**禁止提交到 CI 或生产环境** - 根本解法：删掉冲突的根依赖项，让其由子依赖自动带入，避免手动锁定不可协调的版本
Composer 的复杂性不在命令数量，而在约束求解过程本身——它每执行一条命令，都在做一次 SAT 问题求解。所以别追求“记全命令”，盯住 composer.json 和 composer.lock 的状态变化，比背命令有用十倍。
