Composer Artifact仓库是静态包分发机制，解决离线/私有环境无法直连Packagist、需审计来源或CI网络受限等问题；它通过固定目录结构存放含composer.json的.zip/.tar包，支持file/HTTP访问，但要求type为artifact、目录可遍历、压缩包平铺且不缓存元数据。
什么是Composer Artifact仓库，它解决什么问题
Artifact仓库是Composer的一种离线/私有包分发机制，适用于无法直连Packagist、需要审计包来源、或CI环境网络受限的场景。它不运行Composer服务端，而是把composer.json和压缩包（.zip/.tar）按固定结构放在文件系统或HTTP服务器上，让composer install能从本地路径或内网地址拉取——本质是“静态包仓库”。
配置repositories时必须用artifact类型，且路径要可遍历
在composer.json中添加仓库，关键点不在URL格式，而在type字段和目录结构匹配：
-
type必须为artifact，不能写成package或composer -
url指向的是包含多个.zip或.tar文件的**父目录**，不是单个包文件路径 - 该目录下所有压缩包必须包含有效的
composer.json（顶层或composer/子目录下），否则会被跳过 - 支持本地路径（
file:///path/to/artifacts）和HTTP（https://intra.example.com/artifacts/），但HTTP需启用index.html或Web服务器支持目录列表（如Nginx的autoindex on）
示例配置：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
{
"repositories": [
{
"type": "artifact",
"url": "file:///opt/composer-artifacts/"
}
]
}
生成符合Artifact要求的压缩包，composer archive不是必需的
Artifact不要求包由Composer打包；只要压缩包解压后根目录含composer.json，且内容合法即可。常见错误是压缩了整个项目目录（如mylib/mylib/composer.json），导致路径偏移：
- 正确结构：打开
mylib-1.2.0.zip→ 直接看到composer.json、src/、vendor/ - 错误结构：打开后是
mylib/文件夹，里面才有composer.json→ Composer找不到元数据 - 可用
tar -C /path/to/pkg -czf mylib-1.2.0.tar.gz .（注意末尾的.）保证平铺 - 如果用
composer archive，需加--format=zip并确认输出路径无嵌套
安装时行为差异：只读、不解析依赖图、不触发scripts
Artifact仓库完全绕过Packagist协议，因此有明显限制：
-
composer require无法从Artifact仓库搜索或添加新包，只能install或update已声明的依赖 - 不会下载
composer.lock中未记录的间接依赖（即transitive deps），那些仍需其他仓库提供 - 包内的
scripts（如post-install-cmd）照常执行，但composer.json里的autoload、require等字段必须完整，否则安装会失败 - 若多个Artifact仓库含同名同版本包，Composer取第一个匹配项，不合并或校验一致性
最易忽略的一点：Artifact不缓存元数据，每次install都会重新扫描整个url目录下的所有压缩包——目录里放几百个旧版本包，会显著拖慢安装速度。
