会。composer config store-auths prompt 报错，因 store-auths 仅接受 true/false，不支持 "prompt"；composer 无内置“每次询问是否保存”模式，需手动或脚本干预。
composer config store-auths prompt 会失败吗？
会。直接运行 composer config store-auths prompt 报错 Invalid value for store-auths: "prompt"，因为 store-auths 只接受布尔值（true/false）或字符串 "false"，不支持 "prompt" —— 这个值根本不存在于 Composer 的配置校验逻辑中。
为什么没有 prompt 模式？
Composer 本身没有“每次询问是否保存凭证”的内置模式。它的凭证存储行为由两个独立机制控制：store-auths（是否自动存入 auth.json）和交互式提示逻辑（是否在首次访问私库时弹出密码输入框）。所谓“prompt”其实是默认行为：当 store-auths 为 false 且凭证未缓存时，Composer 就会停住、等你输密码，但**不会问“要不要存”**——它只管读，不管存的决策。
-
store-auths = true：输完密码后自动写进auth.json -
store-auths = false：输完密码仅本次生效，不写文件；下次还问 - 没有
prompt值，设了就报错
如何实现“每次询问是否保存”？
得靠外部工具或手动干预。Composer 不提供钩子或插件接口来拦截认证流程并插入确认逻辑。可行路径只有两种：
- 保持
store-auths = false（推荐），靠人工判断：每次看到密码提示，自己决定是临时输入，还是手动执行composer config --auth http-basic.example.com user pass补存 - 用 shell 封装命令，例如写个
comprompt脚本，在调用composer install前检查auth.json是否含目标域名，不含则先read -p "Save creds? [y/N]"再决定是否config --auth - 注意：全局
auth.json（~/.composer/auth.json）和项目级（./auth.json）权限不同，后者可能被 Git 提交，务必避免误存
容易被忽略的隐私细节
很多人以为关掉 store-auths 就绝对安全，其实不是：
- 终端历史记录里可能留下
composer config --auth ...命令，含明文密码 - 某些 IDE（如 PHPStorm）会缓存 HTTP 认证凭据，独立于 Composer 管理
-
auth.json文件权限若为644，同服务器其他用户可能读取——应设为600 - 使用
git clone直接拉私库时，URL 若含密码（https://user:pass@repo.com），一样泄露
真要兼顾便利与隐私，最稳的做法是：设 store-auths = false，用 ssh-agent 或 git-credential-libsecret 管理 Git 凭据，对 Composer 私库统一走 OAuth token + http-basic 配置，并确保 token 权限最小化。
