Composer安装失败主因是未同步composer.lock或环境不一致；必须同步lock文件、匹配PHP版本及扩展，并按场景选用install/--no-dev，推荐create-project确保环境一致。
composer install 时提示 “Package not found” 或 “Your requirements could not be resolved”
直接复制 composer.json 到另一个项目后运行 composer install，大概率失败——不是因为文件没复制对，而是 composer.lock 没同步或环境不一致。
关键点：Composer 安装行为由 composer.lock 决定，不是 composer.json。只复制 composer.json 相当于只抄了“愿望清单”，没带“已确认的版本快照”。
- 如果原项目有
composer.lock，务必一起复制过去，再运行composer install - 如果原项目没提交
composer.lock（比如被.gitignore忽略了），那你要先在原项目里执行一次composer update --lock生成它，再复制 - 目标机器 PHP 版本、已安装扩展（如
ext-gd、ext-mbstring）必须满足composer.json中config.platform.php或各包的require.php要求，否则会报依赖冲突
用 composer create-project 复制整个可运行环境
想快速拉起一个和原项目一模一样的本地副本？composer create-project 比手动复制更可靠，尤其适合私有包或带自定义仓库的项目。
前提是原项目已发布到某个 Composer 可访问的源（如 packagist.org、私有 Satis/Artifactory、甚至本地 Git 路径）。
- 若原项目已发布为包（比如 vendor/name），运行：
composer create-project vendor/name my-new-project - 若只是本地 Git 仓库，可用路径：
composer create-project --repository-url='{"type":"vcs","url":"/path/to/original/project"}' vendor/name my-new-project - 加
--no-install可跳过自动install，方便后续改composer.json再装
同步 dev-dependencies 但不想装测试工具到生产环境
很多项目把 phpunit、phpstan 放在 require-dev，复制后直接 composer install 会全装上——这在 CI 或部署时可能出问题。
区分场景选命令：
- 开发环境复刻：用
composer install（默认装require+require-dev） - 生产环境部署：必须加
--no-dev，即composer install --no-dev，否则可能引入未审计的 dev 工具链 - 如果目标项目明确不需要某些 dev 包（比如原项目用了 Laravel Dusk，新项目是 API-only），删掉
composer.json里的对应项再装，比事后composer remove更干净
vendor 目录权限、Git 忽略和平台配置差异
复制完跑不起来，常卡在 vendor 权限、Autoloader 找不到类，或 ext-xxx 报错——这些问题跟“复制 JSON”本身无关，但紧跟着发生。
-
vendor不该提交进 Git；确认新项目根目录有.gitignore含/vendor，否则下次git add .会误提交几万个小文件 - 如果原项目用了
config.platform（比如"platform": {"php": "8.1.10"}），而你的本地 PHP 是 8.2，composer install可能降级装旧版包，或干脆失败；此时要么调低本地 PHP 版本，要么删掉该配置再update - Windows 复制到 Linux 服务器时，注意
vendor/bin下脚本的换行符和执行权限；用chmod +x vendor/bin/*补一下，否则phpunit等命令会报 “Permission denied”
真正麻烦的从来不是复制 JSON 文件，而是 lock 文件是否可信、平台约束是否显式声明、以及 vendor 是否被当成“可交付物”来对待。这些细节漏一个，就卡在 “明明一模一样却跑不通”。
