Composer 可通过 dev-branch#commit-hash 语法安装任意 Git 提交，如 "monolog/monolog": "dev-main#abc1234"，要求使用完整 40 位 hash；需清缓存、更新 lock 文件或用 composer update 强制生效，否则仍按旧版本安装。
Composer 怎么安装某个 Git 提交的代码
直接用 composer require 或修改 composer.json 的 "version" 字段无法指定任意提交，必须改用 dev-* 分支语法 + #<hash></hash> 后缀。Composer 会把这种写法识别为“从该提交拉取源码”，不依赖远程分支是否存在。
- 写法示例：
"monolog/monolog": "dev-main#abc1234"（main 分支上 abc1234 这次提交） - 如果目标提交不在任何公开分支上，仍可生效——只要该 commit 在仓库中可访问（比如是某人 fork 后 push 过的）
-
#后面必须是完整 40 位 commit hash，短 hash（如abc123）在某些 Composer 版本中可能失败 - 执行前建议先运行
composer clear-cache，避免旧缓存导致拉取错误版本
为什么 composer install 有时不按 #hash 安装
常见原因是项目已存在 composer.lock，且其中记录了其他版本。Composer 默认优先遵守 lock 文件，不会因为 composer.json 改了就重解析。
- 确认是否真用了新 hash：检查
composer.lock里对应包的"source"→"reference"字段是否为你填的 hash - 若不是，删掉
composer.lock和vendor/，再跑composer install - 或者强制更新：用
composer update vendor/package-name --with-dependencies，避免全量更新影响其他包 - 注意：如果该 hash 所在仓库被设为私有或已删除，
composer install会报Failed to download...错误，不是语法问题
用 path 仓库类型本地调试指定提交更稳
当你要反复切不同提交、或目标提交尚未 push 到远程时，path 类型比 #hash 更可控，也绕过网络和权限限制。
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"中加一条：{"type": "path", "url": "../my-local-fork"} - 然后 require 时写
"my/package": "*"，Composer 会自动 link 到本地目录 - 进
../my-local-fork目录，用git checkout abc1234切到目标提交即可 - 每次
composer update都会读取本地当前 HEAD，无需改composer.json
CI/CD 中锁定提交要防 hash 失效
Git hash 本身不会变，但仓库地址失效、权限变更、或 repo 被 force-push 覆盖历史，都会让 hash 不可达。
- 上线前务必在构建机上验证
composer install能成功拉取，别只信本地结果 - 如果用的是 GitHub/GitLab 私有仓库，确保 CI token 有读取该 repo 的权限（尤其对 fork 或非默认分支）
- 生产环境不建议长期依赖未发布 commit；临时修复可用，但应尽快提 PR 合并到正式分支并打 tag
hash 是最细粒度的版本锚点，但也是最脆弱的——它不自带语义、不保证可重现、也不受 packagist 索引保护。用之前，先确认那个提交真的还在那儿，且能被你的部署环境看见。
