直接在项目根目录或全局执行 composer config http-basic 命令才能生效，域名须精确匹配仓库 host，auth.json 权限应设为 600，且 json 结构必须为 {“http-basic”: {“host”: {“username”: “”, “password”: “”}}}。
composer config http-basic 怎么写才生效
直接在项目根目录或全局配置里执行 composer config 命令，才能把凭证写进 auth.json。不手动触发，Composer 不会自动生成或更新认证信息。
- 项目级配置（推荐）：运行
composer config http-basic.repo.example.com username password，会在当前项目生成auth.json，只对本项目生效 - 全局配置：加
--global参数，凭证存到用户家目录的~/.composer/auth.json，所有项目都读它 - 域名必须精确匹配仓库地址的 host 部分，比如私有源是
https://packages.myorg.com，就得填packages.myorg.com，填myorg.com或带https://都无效 - 如果仓库用了子路径（如
https://repo.example.com/api/v1），依然只认 host，和路径无关
auth.json 文件手写时的格式陷阱
手写 auth.json 最容易错在 JSON 结构和字段名——Composer 只认 http-basic 这个 key，且 value 必须是对象，不能是数组或字符串。
- 正确结构：
{"http-basic": {"repo.example.com": {"username": "u", "password": "p"}} - 常见错误：多了一层
repositories包裹、用Token当作password却没关掉 token 认证逻辑、密码含特殊字符没转义导致 JSON 解析失败 - 文件权限很重要：linux/macos 下
auth.json权限不能是 644 以上，否则 Composer 会静默忽略它，建议设为600 - windows 用户注意：换行符用 LF（unix 风格），CRLF 可能导致解析失败，尤其用记事本保存时
私有源走 HTTPS 但证书不被信任怎么办
HTTP Basic 认证本身不解决证书问题；如果私有源用了自签名证书，Composer 默认拒绝连接，这时要额外配置跳过验证或指定 CA 路径。
- 临时跳过（仅开发）：设置环境变量
COMPOSER_DISABLE_TLS=1，或运行时加--no-secure-http参数 - 生产环境应配 CA：用
composer config cafile /path/to/cacert.pem指向你的根证书文件 - 不要混用：
http-basic和cafile是独立配置项，缺一不可——有认证没证书信任，连不上；有证书信任没认证，返回 401 - 某些企业网络中间有代理 TLS 解密，此时实际需要的是代理提供的 CA，不是目标服务器的证书
为什么 composer install 还是提示 authentication required
不是配置没写，而是 Composer 在请求时根本没把凭证发出去，通常卡在几个具体环节。
- 检查仓库 URL 协议：必须是
https://或http://，如果composer.json里写的是git@或ssh://地址，HTTP Basic 完全不生效 - 确认源是否真走 HTTP：有些私有源（如 Nexus、Artifactory）默认开启匿名访问，只有特定路径（如
/api/composer/...）才需要认证，看 Composer 实际请求的 URL 日志就能定位 - 运行
composer install -v，观察输出里有没有Reading .../packages.json from cache—— 如果命中了本地缓存，就不会触发认证，清缓存再试：composer clear-cache - gitlab 私有源要注意：它用的是
composer auth命令配合 Personal access Token，不是传统用户名密码，得填 token 到password字段，并确保 token 有read_api权限
最常被忽略的是域名匹配精度和文件权限，这两个点不排查完，其他操作都是白忙。