本地包必须用 path 类型仓库配合 "*" 约束，因 Composer 不识别本地路径版本号；写死版本如 1.2.3 会被当作远程包查找而失败，path 仓库仅读取本地 composer.json 的 version 字段。
本地包的版本约束不能靠 ^、~ 或具体数字写死，必须走 path 类型仓库 + "*" 约束，否则 Composer 会直接报错或静默忽略。
为什么 composer require my-vendor/pkg:1.2.3 会失败
Composer 默认只从 Packagist 或 VCS（如 Git）拉包，不识别文件路径。你写的 1.2.3 会被它当成远程包去查，结果找不到，抛出 Could not find package。
-
repositories没配或类型不是path→ 直接失败 - 写了
"my-vendor/pkg": "^1.2.0"→ 不报错但无效，仍按本地composer.json的version字段装，还可能带 warning -
url写成https://...或git@...→ 被当 VCS 处理，跳过本地读取逻辑
repositories 中 path 类型的写法要点
这是唯一能启用本地包的入口，配置错一个字就白搭。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
type必须是"path"，不是"package"或"vcs" -
url是相对于项目根目录的路径，支持./packages/foo或/absolute/path/to/foo，不能带尾部斜杠 - 该路径下必须存在合法的
composer.json，且其中name字段要和require中完全一致（包括大小写） - 如果路径含空格或特殊字符，不用转义，但确保 shell 能正常访问该路径（比如 CI 环境里路径权限问题常被忽略）
require 里只能用 "*" 的真实原因
path 类型仓库不参与语义化版本解析——它本质是“符号链接式挂载”，Composer 只做一次读取：拿到本地包 composer.json 里的 version，然后照单全收。
- 写
"*"是唯一明确告诉 Composer “请信任本地 version 字段” 的方式 - 写
"dev-main"或"1.2.3@dev"→ 报错Invalid version string，因为path不支持稳定性标记 - 想“锁定”内容？靠的是文件系统快照（Git commit hash / 文件修改时间），不是版本号字符串
- 本地
composer.json里version改了，下次composer update就会立刻生效，无需改主项目require
常见误操作与调试建议
遇到安装失败，别急着删 lock 文件重装，先确认这几件事：
- 运行
composer config repositories，看输出里有没有你配的path条目，以及url是否拼错 - 进本地包目录，执行
composer validate，确保它的composer.json语法合法、name字段存在且匹配 - 执行
composer show my-vendor/pkg，如果返回Package not found，说明仓库没注册成功；如果返回版本信息但和本地composer.json不一致，说明version字段被覆盖或缓存未刷新（可加-vvv看详细日志） - CI 环境中注意：某些 Docker 镜像或部署脚本会自动清理
vendor但忽略repositories配置，导致本地包消失
真正起作用的永远是本地包目录下的 composer.json 中的 version 字段，而不是你在主项目里写的任何字符串——这个细节在协作开发和 CI 流水线中特别容易被绕过去。
