composer.lock冲突不应手动修改，应先判断是否需合并：若仅增删包或微调PHP版本，可弃当前lock用主干重装；若升级关键依赖则需谨慎，且须确保composer.json无冲突。
composer.lock 冲突时别手动改，先确认是否真要合并
绝大多数 composer.lock 合并冲突其实不该手动解决——因为这个文件本该由 composer install 或 composer update 生成，不是人写的。Git 报冲突，往往只是两个分支各自运行过 composer update 或增删了包，导致哈希、版本、依赖树不一致。
判断是否真要合并：
- 如果两边改动都只是新增/删除同一类包（比如都加了 monolog/monolog），或只是 PHP 版本约束微调，那大概率可以直接放弃当前分支的 composer.lock，用主干的重装；
- 但如果某边升级了关键依赖（如 laravel/framework 从 v10 到 v11），就得小心了；
- 检查前先运行 git status，确认只有 composer.lock 冲突，composer.json 没冲突——否则得先理清 composer.json 的差异。
autoload 冲突根源在 PSR-4 映射错位，不是文件没加载
类找不到、重复定义、Class not found 这些报错，90% 不是 vendor/autoload.php 没被 require，而是 PSR-4 命名空间与实际文件结构不匹配，或多个项目/分支共用 vendor 导致映射路径硬编码失效。
常见错位点：
- composer.json 中 "psr-4": {"App\": "src/"} 要求所有 App 开头的类必须声明 namespace App...，且文件必须在 src/ 下对应子目录；
- 路径值（如 "src/"）必须是相对于 composer.json 所在目录的真实相对路径，漏掉末尾斜杠（写成 "src"）在某些系统下会行为异常；
- 若用了 classmap，又同时配了同名空间的 psr-4，Composer 优先走 PSR-4，classmap 可能被完全忽略，导致“两头不靠”。
解决流程：弃 lock → 重装 → 重建 autoload 映射
已冲突时最稳做法：
- 暂存当前分支的 composer.lock：git stash save "lock before reset"；
- 切回主干，确保 composer.json 正确，执行 composer install --no-dev --optimize-autoloader；
- 然后按需恢复本分支的依赖变更：composer require xxx 或 composer remove yyy；
- 最后强制重建 autoload：composer dump-autoload -o；
- 验证：检查 vendor/composer/autoload_psr4.php 中对应命名空间的路径是否指向当前项目目录，而非其他分支的 src 或 vendor 子路径。
多分支开发时 autoload 冲突最容易被忽略的点
真正难排查的不是报错本身，而是环境残留：
- vendor/composer/autoload_*.php 文件可能缓存旧映射，即使你改了 composer.json 并跑了 dump-autoload，它也可能没更新；
- 更隐蔽的是 COMPOSER_VENDOR_DIR 环境变量被设为全局路径，导致所有分支往同一个 vendor/ 写，autoload.php 里 __DIR__ 指向错误根目录；
- ThinkPHP 或 CodeIgniter 项目若启用了 $config['composer_autoload'] = TRUE，但 APPPATH.'vendor/autoload.php' 实际加载的是另一个项目的 autoload，就会彻底错乱；
- 不要依赖 include_once 'vendor/autoload.php' 就万事大吉——ClassLoader 是全局单例，两个项目先后 require，后注册的会覆盖前者的路径规则。
