移动端Basic Auth兼容性良好但体验受多因素影响，需重点验证用户能否顺利完成输入并保持会话；真机测试应覆盖iOS/Android主流浏览器的弹窗触发、AJAX请求处理、后台挂起后凭证维持及弱网表现；推荐用表单登录+Token或auth_request代理替代原生弹窗以提升体验。
移动端浏览器对 HTTP 基本认证（Basic Auth）整体兼容性良好，但实际体验受系统版本、浏览器内核、网络环境及认证提示机制影响较大。测试重点不是“能不能通过”，而是“用户能否顺利完成输入并持续保持会话”。
确认基础认证是否生效（服务端验证）
先排除服务端配置问题，确保 Basic Auth 已正确启用：
- 用 curl 命令模拟移动端请求头，添加常见移动端 User-Agent，例如：
curl -u admin:123456 -H "User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.6 Mobile/15E148 Safari/604.1" http://your-domain.com/api/status - 若返回 200，说明 Nginx 认证模块已识别凭证且放行；若返回 401，检查
auth_basic_user_file路径、权限及密码文件格式（必须是 htpasswd 生成的合法格式） - 注意：Nginx 不校验 User-Agent，此步骤只为模拟真实终端行为，避免误判为“移动端不支持”
真机实测关键操作与观察点
在 iOS 和 Android 主流设备上分别测试，重点关注以下环节：
- 首次访问是否弹出系统级认证框：Safari（iOS）、Chrome（Android/iOS）、Edge（Android）通常会触发原生弹窗；部分国产浏览器（如华为、小米自带浏览器）可能静默失败或跳转到空白页，需记录具体表现
-
输入后是否能成功加载页面：特别注意含 AJAX 请求的页面——现代浏览器对跨域资源或 fetch/fetch-with-credentials 的 Basic Auth 处理不一致，建议后端接口统一返回带
WWW-Authenticate头的 401，前端捕获后引导重试 - 页面刷新或切换标签页后是否仍保持登录态：Basic Auth 凭证由浏览器自动附带在 Authorization 请求头中，只要未关闭标签页或清除缓存，多数浏览器可维持数小时；但 iOS Safari 在后台挂起较久后可能丢失凭证，需重新触发弹窗
-
弱网环境下弹窗延迟或无响应：部分低端安卓机型在 3G 或高丢包 Wi-Fi 下，认证弹窗出现滞后甚至卡死，建议搭配 Nginx
auth_request模块做前置轻量校验，减少首屏阻塞
绕过弹窗的替代方案（提升移动端体验）
如果发现多款主流移动端浏览器频繁出现认证异常，可考虑更可控的接入方式：
- 将 Basic Auth 保护路径限定为
/admin、/api等非首页路径，前端登录页走表单提交 + Cookie 或 Token 鉴权，避免依赖浏览器弹窗 - 使用 Nginx 的
auth_request指令代理到一个轻量认证服务（如 FastAPI 写的小接口），由该服务返回 200/401，既保留鉴权逻辑，又规避原生弹窗限制 - 对必须用 Basic Auth 的场景，在 HTML 页面中嵌入 base64 编码的凭证（仅限内网或调试环境）：
https://admin:123456@your-domain.com/status—— 注意：现代浏览器出于安全策略大多已屏蔽该写法，仅作兼容性兜底参考
不复杂但容易忽略：移动端没有“记住密码”选项，每次新开标签或重启浏览器都会重新触发认证。生产环境若面向内部人员，建议配合企业微信、钉钉扫码或 SSO 跳转，比纯 Basic Auth 更可靠。
