composer init 比手动写 composer.json 更安全，因其交互式校验字段、强制版本约束、默认 stable 稳定性、自动生成合法 json；装包须用 ^7.5 等约束符而非 1.2；禁用 dev-master；install 依赖 lock 文件保证一致，update 才重解析；国内必须配镜像源。
初始化项目时，composer init 比手动写 composer.json 更安全
很多人直接新建空 composer.json 再填字段，结果格式错、字段名错（比如写成 requre）、版本约束漏掉符号，导致后续 composer install 报错或装错包。
-
composer init是交互式向导，自动校验字段合法性，强制你填--require的版本约束（如guzzlehttp/guzzle:^7.5），不会让你糊弄过去 - 它默认设
"minimum-stability": "stable"，避免开发中意外拉到dev-master导致行为不一致 - 填完可立刻用
composer validate检查 JSON 合法性——这步手动写极易出错，而init生成的几乎不会 invalid
装包别只写 1.2，版本号必须带约束符
这是最常踩的坑：写 composer require foo/bar:1.2，Composer 会把它解释为严格等于 ==1.2.0（不是 ^1.2 或 ~1.2.0），而 1.2.0 这个精确版本很可能根本不存在，直接报 Could not find package。
- 推荐用
^7.5：允许7.5.0到7.x.x（不含8.0.0），语义化版本兼容性最稳 - 慎用
dev-master：没锁 commit hash，下次composer update可能拉到破坏性变更 - 如果真要锁定某次提交，用
foo/bar:dev-main#abc1234，但仅限调试，别进生产
composer install 和 composer update 根本不是一回事
新手常混用，结果要么装不上依赖，要么把线上环境搞崩。核心区别就一条：install 读 composer.lock 装固定版本；update 重新解析 composer.json 并更新 lock 文件。
- CI/CD 部署、上线前构建，必须用
composer install——它保证所有人装的包版本完全一致 - 只有当你改了
composer.json（比如加新包、升版本号）或明确要升级依赖时，才运行composer update - 想只更新某一个包？用
composer update vendor/package-name，避免连带升级一堆间接依赖引发兼容问题
国内用 Composer，不配镜像源=等龟速
默认源 https://packagist.org 在国内直连基本超时，尤其装含二进制资源（如 laravel/sail）或大体积包（如 phpunit）时卡死是常态。
- 全局换阿里源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 临时换源（单项目）：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 换源后记得清缓存：
composer clear-cache，否则旧缓存可能继续走原地址
版本号、约束符、lock 文件、镜像源——这四点里漏掉任何一个，都可能让一条 composer require 命令从“秒装”变成“查文档查一小时”。