运行 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 文件验证映射是否符合预期：

jm-jsjkxyjs02-zlm-405

使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。

下载

• 如果源码在 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 成功，再逐步放开其他模块。