要安装 dev-master 或其他分支，需在 composer.json 中写为 "vendor/package": "dev-master"（斜杠替换为短横线），并确保仓库存在、可访问；若仍装错，应删 composer.lock 后运行 composer install 或用 composer update 更新锁文件。

composer.json 里怎么写才能装 dev-master 或其他分支

Composer 默认只认 dist（打包好的 zip/tar）和 stable 版本，要装分支（比如 dev-main、dev-develop），必须显式告诉它：这不是一个版本号，而是一个开发分支。核心是把分支名转成 Composer 能识别的“伪版本”格式。

常见错误是直接写 "vendor/package": "main" 或 "vendor/package": "git@github.com:..." —— 这两种都不行，前者被当作文本匹配失败，后者根本不是合法的 version 字段值。

• 正确写法是用 dev- 前缀 + 分支名，例如："vendor/package": "dev-main"、"vendor/package": "dev-develop"
• 如果分支名含斜杠（如 feature/login），需将 / 替换为 -，即写成 "dev-feature-login"
• 必须确保该分支在远程 Git 仓库中真实存在，且 Composer 能访问（私有库需配 auth.json 或 SSH key）
• 运行 composer update vendor/package，而不是 install，否则可能命中本地 lock 文件缓存

为什么装了 dev-xxx 却还是拉 master？

最常见原因是 composer.lock 锁定了旧版本。Composer 在 install 时完全按 lock 文件还原，哪怕 composer.json 已改成 dev-main，只要 lock 没更新，就还是旧的 commit。

另一个隐蔽问题是 Packagist 上该包已发布过同名 tag（比如有人打了 1.0.0 标签），而 dev-main 的稳定性低于 1.0.0，Composer 默认优先选 stable，除非你明确禁止降级或提高最低稳定要求。

• 先删掉 composer.lock 和 vendor/，再执行 composer install
• 或者更稳妥：运行 composer update vendor/package --with-all-dependencies
• 检查是否意外设置了 "minimum-stability": "stable"（默认值），可临时改为 "minimum-stability": "dev"，但上线前务必改回
• 用 composer show vendor/package 确认当前安装的 commit hash，并比对 Git 仓库对应分支最新 commit

用 repository 自定义 Git 地址时要注意什么

当包不在 Packagist，或你想从 fork、私有仓库安装时，得手动加 repositories。这里容易漏掉关键字段，导致 Composer 找不到分支或报错 Could not find package...。

Discussion Composer

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

下载

重点不是 URL 写对了就行，而是 Composer 需要能“解析出版本信息”。Git 仓库本身不带 composer.json 的版本声明，所以必须靠 type: "vcs" + 正确的目录结构来触发自动发现。

• repositories 必须是数组，每个项包含 "type": "vcs" 和 "url"（支持 https、git@、file://）
• URL 必须指向 Git 仓库根目录，不能是子路径或 GitHub 页面链接（如 https://github.com/user/repo/tree/main 是错的）
• 仓库根目录下必须有有效的 composer.json，且其 name 字段要和 require 中的一致
• 如果想强制走某一分支，仍需在 require 中写 dev-xxx，仅靠 repository 不会改变版本解析逻辑

dev 分支安装后如何验证实际加载的是哪个 commit

光看 composer show 输出不够，因为它的 versions 字段可能只显示 dev-main，不反映真实 commit。真正影响运行时行为的是 vendor/ 下代码的实际快照。

尤其在 CI/CD 或多人协作中，不同人本地 composer install 可能拉到不同 commit（因分支持续更新），这会导致行为不一致却难以察觉。

• 进 vendor/vendor-name/package-name/ 目录，执行 git log -n 1 --oneline，看 HEAD 是哪个 commit
• 对比该 commit 是否与目标分支最新推送一致（可用 git ls-remote origin main | head -c 7 查远端）
• 在 composer.lock 中搜索该包，找到 "source" 字段下的 "reference" 值，它就是锁定的 commit hash
• CI 中建议加一步校验脚本：用 composer show -s vendor/package | grep reference 确保和预期一致

分支名只是指针，真正落地的是 commit。别只盯着 dev-main 四个字，它背后可能隔了几十次提交。