Composer默认源在国内下载极慢，切换阿里云或华为云镜像可解决90%问题：全局执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾无斜杠），或项目级执行composer config repo.packagist composer https://mirrors.huaweicloud.com/composer/写入composer.json；验证用composer config repo.packagist看输出URL及composer show packagist.org测响应时间。
Composer 默认源在国内下载极慢，直接切中文镜像就能解决 90% 的日常依赖安装问题；私有 Packagist 则是团队级 PHP 包治理的刚需，但别一上来就堆 Satis 或 Private Packagist —— 大多数场景用 composer repo + 简单 HTTP 服务就够了。
怎么快速启用阿里云 / 华为云 Composer 镜像
国内主流镜像已支持 Packagist.org 全量同步，延迟通常在 5–15 分钟，足够日常开发。关键不是“换源”，而是确保换得干净、可回滚。
- 全局替换（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
，注意末尾不能带/，否则会报Invalid repository type: composer - 项目级覆盖更安全：在项目根目录运行
composer config repo.packagist composer https://mirrors.huaweicloud.com/composer/
，该配置写入composer.json的repositories字段，不污染全局 - 验证是否生效：运行
composer config repo.packagist，输出应为镜像 URL；再执行composer show packagist.org，看响应时间是否从秒级降到 200ms 内 - 切回官方源只需删掉对应配置：
composer config -g --unset repos.packagist（全局）或composer config --unset repos.packagist（项目）
为什么 Satis 不适合中小团队搭私有 Packagist
Satis 生成的是静态 JSON + ZIP 文件，看似轻量，但实际维护成本高：每次新增包都要重跑全量构建，satis build 耗时随包数量线性增长，且不支持按需拉取、无权限控制、无法对接 Git Webhook 自动更新。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 典型卡点：
satis.json中若包含 50+ 私有仓库，一次 build 可能超 8 分钟，CI 流程阻塞严重 - 权限只能靠 Nginx Basic Auth 拦截，无法做到 per-package 或 per-user 控制
- 不兼容 Composer 2.5+ 的
lock文件新字段（如packages-dev分离），容易导致composer install报Package not found - 替代方案：用
packagist.com（付费）、Private Packagist（自托管版需 Docker），或最简路径——用composer serve+git archive手动发布
用 Composer 本地仓库（path repo）做最小可行私有包管理
适合 3–10 人团队，无需额外服务，所有逻辑都在 composer.json 里，CI/CD 也无需改脚本。
- 在公司内网共享目录（如
/srv/php-packages）放多个包，每个包含完整composer.json，版本用dev-main或1.2.3标准格式 - 项目中声明：
"repositories": [ { "type": "path", "url": "/srv/php-packages/my-utils" } ]，然后composer require my-company/my-utils:dev-main - 关键限制：路径必须是绝对路径，且
composer进程要有读取权限；Windows 下需用file://前缀，例如"url": "file:///D:/php-packages/my-utils" - 好处是调试极快——改完包代码，
composer update立即生效，不用 push/tag/publish 三连
私有包发布到内部 Packagist 的真实流程要点
真要上 HTTP 服务型私有源，核心不是选工具，而是守住三个接口契约：包元数据 JSON、ZIP 下载、认证头校验。
- 必须提供
/packages.json（根路径），内容结构与 packagist.org 一致，含packages键和每个包的versions数组 - 每个包 ZIP 必须可通过
https://your-pkg.example.com/dist/{vendor}/{package}/{version}/{hash}.zip直接下载，且响应头含Content-Type: application/zip - 若加认证，Composer 仅支持
Authorization: Bearer xxx或Basic，不支持 Cookie 或自定义 Header；配置时用composer config http-basic.your-pkg.example.com username token
- 最容易被忽略的是：私有源的
packages.json里每个包的dist.url必须是**完整可访问 URL**，不能是相对路径，否则composer install会静默失败并 fallback 到其他源
