Composer核心在于依赖协同而非安装，关键靠composer.json结构、composer.lock锁定及命令精准选用：require管运行时依赖，require-dev管开发工具；install按lock精确还原，update重解析版本；冲突排查用show/depends命令，autoload须严格分离并dump生效。
Composer 管理多个依赖包，核心不是“怎么装一堆”，而是“如何让它们不打架、不覆盖、不漏锁”。关键在 composer.json 的结构设计、composer.lock 的存在状态，以及命令选择是否匹配当前目标。
如何用 require 和 require-dev 分开管理运行时与开发期依赖
混写在同一个 require 里会导致生产环境多装一堆测试/构建工具，既增大部署体积，又可能引入安全风险。
-
require只放项目运行必需的库，比如guzzlehttp/guzzle、doctrine/dbal；PHP 版本约束也应放在这里（如"php": "^8.2"） -
require-dev放 PHPUnit、Mockery、PHPStan 这类只在本地开发或 CI 中用的工具；它们不会被composer install --no-dev安装，也不会进生产镜像 - 执行
composer require phpunit/phpunit:^10.0 --dev是唯一推荐的添加方式——它自动写进require-dev并更新composer.lock，避免手动编辑 JSON 出现逗号遗漏或引号错位
为什么 composer install 和 composer update 行为完全不同
这两个命令根本不是“装”和“升级”的简单对应，而是两种完全不同的依赖解析策略。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer install：只读composer.lock，安装其中记录的**精确版本**。哪怕composer.json里写的是"^3.0"，只要 lock 文件里锁的是3.2.1，就一定装3.2.1。这是团队协作和 CI 部署的基石 -
composer update：忽略 lock 文件，重新解析composer.json所有约束，下载满足条件的最新兼容版本。全量update极易引发意外兼容问题，尤其当某个间接依赖（如psr/log）被多个包以不同约束拉取时 - 安全做法是：新增依赖用
composer require，局部升级用composer update vendor/package-name，全量更新仅在明确需要且已跑通全部测试后执行
如何排查和解决多个包间接依赖同一库的版本冲突
冲突往往不发生在你写的 require 里，而藏在 monolog 依赖 psr/log、symfony/console 也依赖 psr/log 的嵌套关系中。
- 先看树：
composer show --tree | grep psr/log（把psr/log换成你要查的包名），确认哪些包在拉它、各自要求什么版本 - 再查来源：
composer depends psr/log，列出所有直接或间接依赖它的顶层包 - 若必须统一版本，优先用 Composer 2.4+ 的
--with参数临时验证：composer update --with=psr/log:^3.0；验证通过后，再考虑是否要调整上游包的版本约束 - 切忌手动改
vendor/下的文件，或单独composer require psr/log:3.0.0——这会破坏依赖树完整性，下次install可能失效
autoload 配置不当会让多个包的类加载相互干扰
PSR-4 映射写错，轻则类找不到，重则两个包里同名命名空间（如 App\）互相覆盖，导致运行时行为错乱。
-
autoload和autoload-dev必须分开：业务代码走autoload，测试类走autoload-dev - 路径必须是相对于
composer.json的真实目录，不能写错斜杠方向或拼错文件夹名；Windows 下路径分隔符不影响，但大小写敏感（Linux/macOS 环境下） - 改完
autoload后必须运行composer dump-autoload，否则新映射不会生效；加--optimize可生成静态映射提升性能，但调试阶段建议先不用 - 如果多个包都声明了
psr-4映射到同一命名空间（比如都映射App\），Composer 不会报错，但加载顺序取决于vendor/autoload.php里注册的先后——这种设计本身就是危险信号，应重构命名空间或使用更细粒度的前缀
真正难的不是装上多个包，而是让它们共存时不抢资源、不踩版本、不绕过 autoload 规则。每次执行 composer update 前，先 git status 看一眼 composer.lock 是否有未提交变更；每次改 autoload，都要用 composer dump-autoload -v 看输出里有没有 warning。
