composer全局配置composer config -g repo.packagist在局域网不生效,是因为该命令仅写入当前用户(如root)的~/.composer/config.json,而宝塔、docker或ci常以www/runner等非root用户运行,导致配置不可见;同时键名错为repos.packagist、漏composertype值、url缺末尾斜杠任一错误均会静默回退官方源,验证需输出完整json对象如{"type": "composer", "url": "https://your-mirror.internal/"}。

composer config -g repo.packagist 为什么在局域网里不生效
因为这条命令只改当前用户的全局配置,而局域网部署常由 www、runner 或 docker 内非 root 用户执行,composer config -g 写进的是 /root/.composer/config.json,进程根本读不到。更隐蔽的是:键名写成 repos.packagist(多一个 s)、漏掉中间的 composer type 参数、URL 少末尾斜杠——三者任一出错,Composer 都静默 fallback 到 https://packagist.org,且不报错。
验证是否真生效:
运行 composer config -g repo.packagist,输出必须是完整 JSON 对象,形如 {"type": "composer", "url": "https://your-mirror.internal/"};空、null 或仍显示官方地址,说明没写进去。
- 别信“配过就完事”,先确认执行命令的用户和实际运行部署脚本的用户是否一致
- 宝塔面板默认用
www用户,得切过去配:sudo -u www composer config -g repo.packagist composer https://your-mirror.internal/ - Docker 构建时,
composer config -g必须在对应用户上下文里执行(比如USER www后再 run)
项目级 composer.json 怎么写才真正走局域网镜像
项目级配置优先级高于全局,且能随代码交付,是私有化部署唯一靠谱的方式。但直接手写容易漏关键项,导致 Composer 仍 fallback 到外网。
正确做法是用命令追加,不是覆盖:composer config repo.packagist composer https://your-mirror.internal/
这条命令会自动 merge 到 composer.json 的 repositories 字段里,保留原有私有源或 Git 仓库配置。
-
"packagist.org": false必须写在composer.json根节点(和require同级),不是嵌套在某个repositories项内部 - 私有镜像 URL 必须以
/结尾,否则 Composer 会拼成https://your-mirror.internalpackages.json,404 - 如果原
repositories是数组[],命令会失败;需先手动改成对象{}再执行 - 改完立刻删掉
vendor/和composer.lock,否则旧 lock 文件里的哈希仍指向原始源,校验失败
局域网镜像源返回 404 或空响应,怎么快速定位
常见误区:以为卡在 Loading composer repositories 是网络不通,其实大概率是镜像服务本身没暴露对路,或者 MIME 类型不对。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论(Discussion)”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性,以及撰写结论。当用户输入以下任一指令时也会自动触发该功能: - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
先绕过 Composer,直接测镜像 URL:curl -I https://your-mirror.internal/packages.json
看响应头里有没有 Content-Type: application/json。没有?Nginx/Apache 没配 JSON MIME 类型,Composer 直接拒收。
- Web 服务 root 必须精确指向 Satis 或 Toran 输出目录,例如
root /var/www/satis/web; - dist ZIP 包路径也得能直连 GET,比如
https://your-mirror.internal/dist/monolog/monolog/2.10.0/xxx.zip;SELinux 或文件权限常锁死该路径 - 别忽略证书:内网自签名证书需关掉校验:
composer config -g secure-http false(仅限可信内网) - 用
composer install -vvv看真实请求 URL,确认是否含你的镜像域名,而不是packagist.org
部署包里已有 vendor/,说明镜像根本没生效过
这是私有化交付中最隐蔽的坑:客户收到的部署包里 vendor/ 是本地开发机上用官方源拉出来的,镜像配置只存在于你机器的 ~/.composer/config.json,压根没打包进去。一旦客户内网断外网,composer install 直接失败。
真正的“打包”意味着:所有依赖必须在目标环境可重现拉取,配置必须和代码同路径、同用户、同生命周期。
- 构建流程里不能依赖本地
vendor/,每次构建前必须清掉vendor/和composer.lock - CI 流水线要用目标环境用户执行
composer install,而不是开发者本地机器 - 若客户环境完全离线,ZIP 包必须包含全部 dist 文件,并确保
dist.url指向内网 HTTP 可达路径(GitHub 地址肯定不行)
镜像 URL 后面那个斜杠、secure-http 开关、packagist.org 的开关位置——这些细节看着小,但任何一个出错,整个部署链就断在 composer install 第一步,而且不报错,只卡住。










