直接fork后composer install报错是因为Composer默认只拉Packagist正式版，不识别本地修改；需配置path类型仓库、用"dev-main"版本、执行composer update而非install，并运行composer dump-autoload -o更新自动加载映射。

直接 fork 后 composer install 报错，不是你代码写错了，而是 Composer 根本没加载你本地改的包——默认它只认 Packagist 上发布的版本。

fork 后 composer install 失败？先检查 repositories 类型是否为 path

很多人 clone 自己 fork 的仓库、改完就跑 composer install，结果提示 Package not found 或依然拉的是旧版。这是因为 Composer 默认把所有 require 当作远程包处理，哪怕你本地有源码，它也不会自动识别。

• 必须在主项目的 composer.json 里显式声明 path 类型仓库：

  {
    "repositories": [
      {
        "type": "path",
        "url": "../my-forked-package"
      }
    ],
    "require": {
      "vendor/package": "dev-main as 1.2.3"
    }
  }

• url 必须是文件系统路径（相对或绝对），不能是 git@ 或 https:// 地址
• require 中的版本号必须是 dev-xxx（对应分支名），并用 as 伪版本对齐主项目依赖约束，否则 Composer 会跳过解析
• 改完后运行 composer update vendor/package，不是 install——只有 update 会重新读取 repositories 并建立链接

中文镜像配错导致 composer update 卡死？重点看三个字段

换源后仍卡在 Resolving dependencies，大概率和镜像无关——镜像只加速下载，不参与依赖解析。但配错会导致根本连不上，或者 fallback 到默认源失败。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 全局配置命令必须是：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意：repo.packagist 不是 repos.packagist，composer 是 type 值不能省，URL 必须 HTTPS 且末尾带 /）
• 项目级配置优先级更高，适合 PR 测试：进项目根目录执行 composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/，它会自动写入 composer.json 的 repositories 字段，key 必须是 packagist
• 换源后首次 composer install 报 hash 校验失败，删掉 vendor/ 和 composer.lock 再重装即可

软链接生效了，但断点不命中？别忘了 dump-autoload

即使 vendor/package 已是符号链接，PHP 自动加载器仍可能找不到新类——因为 Composer 的 autoload 映射表没更新。

• 必须手动触发：composer dump-autoload -o，否则 new SomeClass() 仍报 Class not found
• 这个步骤常被跳过，尤其在 CI 或 Docker 环境中没显式调用时，导致“改了但没生效”的假象
• IDE（如 PHPStorm、VS Code）默认把 vendor/ 当真实路径，软链接实际指向外部目录，需手动配置路径映射或清 IDE 缓存
• 要还原为正常安装，不要硬删 vendor/；应先删 repositories 配置、改回稳定版 require，再 composer update vendor/package

真正卡住贡献流程的，往往不是 git 操作或代码逻辑，而是 autoload 映射没刷新、path 仓库的版本约束和主项目冲突、或者镜像配置里多了一个 s —— 这些点不逐个验证，PR 就永远停在“本地能跑，CI 过不了”。