运行 composer init 前须清理三类残留：手动引入的类库、自定义 autoload 和硬编码路径；autoload 配置需严格匹配命名空间与目录结构，优先用 psr-4，老代码无命名空间则用 classmap；迁移第三方依赖时应查兼容版本并避免弃用库。
直接在现有项目根目录运行 composer init 即可初始化，但多数失败不是因为命令不会用，而是忽略了已有代码结构、依赖混杂和自动加载冲突。
运行 composer init 前必须清理的 3 类残留
非 Composer 项目常手动引入类库（如 require 'lib/xxx.php'）、用自定义 autoload 或硬编码路径。这些会与 Composer 的 autoload 机制打架：
- 删掉或注释掉所有全局
require/include第三方库的语句（尤其是vendor/外的） - 检查
php.ini或脚本中是否设置了set_include_path()，临时移除对旧lib/目录的追加 - 确认没有使用
spl_autoload_register()注册过与PSR-4冲突的规则（比如把App映射到./classes/又让 Composer 也映射到src/）
composer.json 中 autoload 怎么配才不爆红
很多项目转完发现 new AppUser() 找不到类，问题出在命名空间与路径没对齐。别猜，用 composer dump-autoload -o 后看生成的 vendor/composer/autoload_psr4.php 文件验证映射是否符合预期：
- 如果源码在
app/下且命名空间是App，写：{ "autoload": { "psr-4": { "App\": "app/" } } } - 如果老代码没命名空间，用
classmap更稳妥：{ "autoload": { "classmap": ["models/", "controllers/", "helpers/"] } }（注意：classmap不支持命名空间自动解析，仅用于无命名空间的老类） - 别在
autoload里混用psr-4和files加载同一类功能——容易因加载顺序导致重复定义
手动迁移第三方依赖时，composer require 要绕开的两个坑
别一股脑把以前 lib/ 里的 zip 解压进 vendor/，也别照着旧 README 直接 require 最新版——版本不兼容会立刻崩：
- 先查旧项目实际调用的函数/类名，再用
composer show vendor/package看哪些历史版本还支持它（例如monolog/monolog:^1.0支持MonologLogger，而^2.0已改用MonologLogRecord） - 如果旧库已弃用（如
ircmaxell/password-compat），必须替换为password_hash/password_verify原生函数，不能require它来“假装兼容” - 执行
composer require --no-update vendor/package:1.2.3先锁版本，再composer update统一装，避免中途触发意外升级
真正麻烦的从来不是 composer init 这一行命令，而是老项目里那些没写进文档的隐式依赖、条件加载逻辑，以及测试用例里硬编码的 include_path —— 建议先写个最小可运行入口，只加载一个类并 echo 成功，再逐步放开其他模块。
