Composer怎么实现包的AB版本测试_Composer如何用dev依赖测试包的新版本兼容性再正式升级【方法】-composer-PHP中文网

要让 composer 接受 dev 分支，默认需在 require 或 require-dev 中显式指定分支别名，如 "monolog/monolog": "dev-main as 2.10.0"，并避免全局设 "minimum-stability": "dev"；本地测试可用 path repository 挂载未发布包，配合 @dev 安装；切回正式版应先 composer remove 再 composer require，并验证 composer.lock 的 source 类型是否变为 "zip"。

composer怎么实现包的ab版本测试_composer如何用dev依赖测试包的新版本兼容性再正式升级【方法】

直接用 composer require 加 dev- 分支或 dev-main 别名就能测，但必须配合 "minimum-stability": "dev" 或更细粒度的 require-dev 约束，否则 Composer 会拒绝安装开发版依赖。

怎么让 Composer 接受 dev 分支作为依赖

默认情况下 Composer 只装 stable 版本（stable、RC、beta），dev- 开头的分支会被跳过。关键不是改全局 stability，而是精准控制单个包：

在 composer.json 的 require 或 require-dev 中写明具体分支别名，例如："monolog/monolog": "dev-main as 2.10.0" —— 这表示“用 main 分支代码，但对外声称是 2.10.0 版本”
如果只在开发环境测试，优先放 require-dev，避免污染生产依赖
不推荐全局设 "minimum-stability": "dev"，它会让所有未显式指定稳定性的包都降级去拉 dev 分支，极易引发意外升级

用 path repository 本地挂载未发布的包代码

当你自己在开发一个待测包（比如 myvendor/my-package），还没 push 到 GitHub 或 packagist，又想立刻在项目里验证兼容性，path 类型仓库最直接：

Discussion Composer

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

下载

在项目根目录 composer.json 的 repositories 字段加一段：

{
  "repositories": [
    {
      "type": "path",
      "url": "../my-package"
    }
  ]
}

然后运行 composer require myvendor/my-package:@dev（注意必须带 @dev，否则 Composer 不认 path repo 里的 dev 分支）
../my-package 必须包含合法的 composer.json，且 name 字段要和 require 中一致
修改本地 my-package 代码后，不用重新 require，直接 composer dump-autoload 即可生效

测试完怎么安全切回正式版本

别直接删 require-dev 或手动改版本号 —— 容易漏掉 lock 文件残留，导致下次 composer install 仍拉错版本：

先执行 composer remove vendor/package-name（哪怕它在 require-dev 里）
再 composer require vendor/package-name:^3.0 指定目标稳定版
检查 composer.lock 中该包的 source 字段是否已从 "type": "git" 或 "type": "path" 变回 "type": "zip"，这是真正切回 packagist 发布版的标志
CI 流水线中建议加一步校验：用 composer show vendor/package-name 确认输出里没有 dev- 或 branch 字样