项目级配置是唯一靠谱方式，需在composer.json的repositories数组首位同级写"packagist.org": false，私有源type为composer且url以/结尾，否则仍连packagist.org。
局域网里配 Composer 自定义仓库，不是加个 repositories 数组就完事——90% 的失败都卡在 "packagist.org": false 没写对位置、私有源 URL 少了末尾 /、或根本没让 Composer 去拉你的 packages.json。
composer.json 里 repositories 怎么写才真正生效
项目级配置是唯一靠谱的方式，全局配置（composer config -g）在宝塔、Docker、CI 中基本不可见。关键不是“加了”，而是“怎么加”和“加在哪”：
-
"packagist.org": false必须写在repositories数组的最外层对象里，和每个仓库项同级，不能嵌套进某个{"type": "composer", ...}内部 - 私有 Composer 源必须是
"type": "composer"，且"url"以/结尾，例如"https://nexus.internal/repository/composer/"（少斜杠会拼成/composerpackages.json，404） - 如果已有其他仓库（比如 VCS 类型），别手动覆盖整个
repositories数组；用命令追加更安全：composer config repo.packagist composer https://nexus.internal/repository/composer/ - 若原
repositories是空数组[]，该命令会失败；需先手动改成对象{}或至少含一个合法项
为什么 composer install 还在连 packagist.org
不是网络不通，是 Composer 根本没放弃默认源——它会先查一遍 https://repo.packagist.org/packages.json，超时后才 fallback，而内网通常直接 Connection refused：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只要
repositories数组存在（哪怕为空），Composer 就自动禁用隐式 packagist 源，但这个“禁用”不等于关闭；必须显式声明{"packagist.org": false}才彻底切断 - 验证是否真禁用：运行
composer config --list | grep packagist，看到packagist false才算生效 - 如果用了 VCS 类型（
"type": "vcs"），它只对composer require vendor/name显式指定的包生效，不会影响其他包的元数据查找路径 - 执行
composer update -vvv，看日志里是否出现你私有源的 URL；如果压根没出现，说明配置未加载或被跳过
私有源服务返回 404 或 text/plain 怎么办
Satis/Nexus/Nginx 不是“配好 URL 就行”，它只是静态文件托管，路径错一格、响应头少一个，Composer 就直接拒收：
- Nginx 的
root必须精确指向 Satis 输出目录（如/var/www/satis/web），不能多一层/web或少一层，否则packages.json和dist/xxx.zip路径全错 - 必须显式配置 MIME 类型：
types { application/json json; }，否则packages.json返回text/plain，Composer 解析失败且静默跳过 - ZIP 文件必须能被直接
curl -I http://nexus.internal/repository/composer/dist/xxx.zip访问，返回200且Content-Type: application/zip - 浏览器打开
http://nexus.internal/repository/composer/packages.json能看到 JSON 内容 ≠ Composer 能读——得用curl -H "Accept: application/json" http://...模拟 Composer 请求头再测
配完为什么 vendor 还是从 GitHub 下 ZIP
因为 composer config repo.packagist 只改元数据入口（packages.json），不改已锁死的 dist.url 字段。旧 composer.lock 里的 URL 仍是原始 GitHub 地址，内网当然打不开：
- 必须删掉
vendor/和composer.lock，再跑composer install - 清缓存：
composer clear-cache，否则 Composer 可能从本地 cache 加载旧 dist 信息 - 确保私有源的
packages.json中对应包的dist.url是内网可访问地址（如"dist": {"url": "https://nexus.internal/repository/composer/dist/vendor-package-1.2.3.zip"}） - 如果用 Satis 构建，检查
satis.json中repositories是否为数组、每个元素是否含完整{"type": "vcs", "url": "http://git.internal/repo.git"}（少.git后缀或写成 HTML 页面地址都会静默失败）
最容易被忽略的是：改完配置后不删 composer.lock，以为重装就行；其实 lock 文件里的哈希和 URL 是硬编码的，不删它，Composer 就永远按老地址去抓 ZIP。
