“could not fetch packages.json”或“401 unauthorized”主因是auth.json未正确配置：位置须为$composer_home/auth.json（linux/macos）、权限600、utf-8无bom、json格式合法且域名完全匹配；优先用composer config --global --auth命令生成，避免手写错误。
composer install 报错说“Could not fetch packages.json”或“401 Unauthorized”
这基本是凭证（auth.json）没配对，或者配了但路径/格式/权限不对。Composer 访问私有源（比如 GitLab、GitHub Packages、Satis、Private Packagist）时，auth.json必须存在且可读，且内容结构正确。
常见错误现象：
-
auth.json放在项目根目录，但 Composer 默认只认$COMPOSER_HOME/auth.json（全局）或项目根目录下的auth.json—— 但后者仅在repositories类型为vcs或package时才被读取；私有composer类型源（如https://gitlab.example.com/api/v4/groups/my-group/-/packages/composer/）必须走全局auth.json - 文件权限太松：Linux/macOS 下
auth.json若权限是644或更宽，Composer 会直接拒绝加载（报错含Auth config file is not secure） - JSON 格式非法：多了一个逗号、用了中文引号、BOM 头残留，都会让 Composer 解析失败，但错误提示极不明确（常表现为静默跳过或 fallback 到官方源）
实操建议：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
composer config --global --auth http-basic.gitlab.example.com token your_personal_access_token自动生成合规的auth.json，比手写安全 - 确认
auth.json权限：Linux/macOS 执行chmod 600 $COMPOSER_HOME/auth.json；Windows 可忽略权限，但需确保文件未被记事本加 BOM - 验证是否生效：运行
composer config --global --auth http-basic.gitlab.example.com，应输出 token 值（不是空）
自定义源启用 HTTPS 但报 “SSL certificate problem” 或 “unable to get local issuer certificate”
这不是源本身问题，而是 PHP 的 cURL 证书链没配好。Composer 依赖 PHP 的 curl 扩展发起 HTTPS 请求，若 curl.cainfo 指向的 CA 包过期或缺失，所有 HTTPS 自定义源都会失败。
使用场景：
- 企业内网私有源用了自签名证书
- 阿里云/腾讯云镜像在某些旧系统上因 CA 包陈旧触发校验失败
- Docker 容器里 PHP 镜像没预装完整 CA 包（如
php:alpine）
实操建议：
- 先查真实配置：运行
php --ini确认加载的php.ini路径，再 grepcurl.cainfo看是否已设 - 没设就补：下载最新 cacert.pem（如 https://www.php.cn/link/5fe4dadcdb001d8566cd20e6d8a20251），在
php.ini加一行curl.cainfo = "/path/to/cacert.pem" - 临时绕过（仅限开发机）：
composer config -g secure-http false，但切记不能上生产——它会让 HTTP 源也变可用，彻底废掉传输层保护
私有源返回 403 却提示 “Could not resolve packages”
这个错误名极具误导性。它不是解析失败，而是 Composer 成功连上了你的源，但源返回了 403 Forbidden（比如权限不足、Token 过期、IP 白名单未覆盖 CI 机器），而 Composer 把这个响应误判为“元数据不存在”，进而 fallback 到其他源或报错。
为什么容易踩坑：
-
composer install -vvv日志里第一行Downloading https://...的 URL 才是真实请求地址，不是composer config输出的配置项 - CI/CD 环境（如 GitHub Actions、GitLab CI）中，
auth.json往往靠 secrets 注入，但若注入方式是 echo 到文件，可能带换行或空格，导致 token 实际无效 - 某些私有源（如早期 Satis）要求
packages.json必须放在根路径，但你配的 URL 是https://repo.example.com/composer/，少了个/就会拼成/composerpackages.json—— 返回 404，但 Composer 仍归类为“无法解析”
实操建议：
- 手动 curl 验证源可用性：
curl -H "Authorization: Bearer $TOKEN" -I https://gitlab.example.com/api/v4/groups/my-group/-/packages/composer/packages.json，看是否真返回 200 - 检查
composer.json中repositories字段：如果写了"type": "composer"，URL 必须以/结尾；若写成"type": "package"，则完全不走 auth 流程，也无需auth.json - CI 中避免用
echo "$TOKEN" > auth.json，改用printf "%s" "$TOKEN" > auth.json防止尾部换行污染
安全声明：自定义源 ≠ 自动可信，签名验证仍需手动开启
即使你把所有包都挪到私有源，Composer 默认也不校验签名。只要 security.signature-verification 没显式设为 true，它就只比对 composer.lock 里的 shasum —— 而这个 hash 是你在本地生成的，一旦 lock 文件被篡改，校验就形同虚设。
关键点：
-
composer show --security输出必须含Signature verification: enabled，否则签名链没接上 - 私有源要支持签名，得自己部署支持
signature字段的仓库（如 Private Packagist、Satis + custom signing hook），普通 Nginx 静态托管做不到 - 阿里云/腾讯云等公开镜像不转发
packages.json中的signature字段，所以切镜像后，signature verification: OK几乎不可能出现
真正卡住人的地方，往往不是配不配得通，而是配通了却误以为“已安全”。composer.lock 提交进 Git、vendor/ 禁止 Web 访问、composer audit 定期跑，这些动作比换源本身更影响实际风险水位。
