不能直接用公共镜像源（如阿里云、腾讯云）配置内网环境，因其仅代理 packages.json 元数据，不提供 dist/ ZIP 包下载服务；内网安装失败主因是 composer.lock 中 dist.url 仍指向 GitHub/GitLab 等外网地址，而私有镜像需显式暴露 /dist/ 路径并返回 application/zip MIME 类型，且必须通过项目级 composer.json 配置（含 "packagist.org": false、首位 type: composer 私有源、末尾斜杠），并清除 vendor 与 lock 后重装验证。
不能直接用公共镜像源（如阿里云、腾讯云）的 URL 配置到内网环境——它们只提供 HTTP 服务，不代理 dist ZIP 文件下载，也不暴露 dist/ 路径，内网机器根本拿不到包内容。必须用私有镜像服务（如 Nexus、Satis 或 Artifactory）中转，且关键配置项一个都不能少。
为什么 composer config -g repo.packagist 在内网静默失效
这条命令只改 packages.json 的获取地址，不修改任何包的 dist.url 字段。而 Composer 安装时，先读元数据，再按 composer.lock 里记录的原始 dist.url（通常是 GitHub/GitLab 的 ZIP 地址）去下载 ZIP 包。内网根本打不开这些地址，但 Composer 不报错，只会卡在 Downloading 或返回 cURL error 7。
-
packages.json可以被镜像，但 ZIP 包必须也能被内网 HTTP GET 到，否则安装必败 - 即使你用了
https://mirrors.aliyun.com/composer/，它也不会返回dist/monolog-1.2.3.zip，只返回元数据 - Nginx 挂 Satis 目录时，若没配置
location /dist/透传或 MIME 类型不对（不是application/zip），也会 404 或被拒绝
私有镜像服务必须暴露 dist/ 路径并返回正确 MIME
内网镜像不是“配个 URL 就完事”，核心是让所有依赖的 ZIP 包能通过 HTTP 直接下载。Nexus、Satis、Artifactory 等都支持，但默认不开启 dist 服务，需手动确认：
- Nexus：确保 Composer group 仓库已启用
dist存储路径，并在反代层（如 Nginx）开放/dist/下所有请求，返回Content-Type: application/zip - Satis：生成时加
"archive": {"directory": "dist", "format": "zip", "skip-dev": true}，且 Web 服务器必须能直接访问dist/目录 - 验证方式：用
curl -I http://your-mirror.internal/dist/monolog-monolog-zip-c8a3b6.zip，响应头必须含HTTP/2 200和Content-Type: application/zip
项目级 composer.json 必须显式禁用 packagist.org
全局配置在 CI、Docker、宝塔等场景下基本不可靠（用户权限不一致），唯一可交付、可复现的方式是写进项目 composer.json。但手写极易出错，必须满足三项硬约束：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"packagist.org": false必须写在根节点（与require同级），不是嵌套在某个repositories对象里 - 私有源必须是
"type": "composer"，URL 末尾带/（例如"url": "http://nexus:8081/repository/composer-group/"） - 私有源必须放在
repositories数组第一位；若原repositories是数组，需先手动改成对象结构再执行composer config repo.packagist composer http://...
改完后立刻删掉 vendor/ 和 composer.lock，再运行 composer install -vvv，日志里出现的 Reading packages.json from ... 和 Downloading ... 的域名必须全是内网地址。
CI/CD 和 Docker 中最容易忽略的权限与上下文问题
很多团队在 GitLab Runner 或 Docker 构建时失败，不是镜像没搭好，而是配置没落到实际运行用户身上：
- GitLab Runner 默认用
gitlab-runner用户，composer config -g却写进了root的~/.composer/config.json，进程根本读不到 - Dockerfile 中若没指定
USER，composer config -g在root下执行，但后续composer install可能在非 root 用户下运行 - 宝塔面板用
www用户执行部署脚本，应显式切过去配：sudo -u www composer config -g repo.packagist composer http://nexus.internal/
最稳妥的做法：放弃全局配置，全部走项目级 composer.json + composer install -vvv 日志验证。内网镜像成败的关键不在“能不能连上”，而在“ZIP 包能不能被 GET 到”和“谁在哪个用户上下文里执行命令”。
