浏览器收到401响应时不会渲染html，而是弹出系统认证框或静默失败；所谓“401页面”实为服务端返回200状态码的自定义登录页，因rfc 7235强制拦截401响应体。
浏览器收到 401 Unauthorized 响应时，不会自动渲染你写的 HTML 页面——它会直接弹出系统级的认证对话框（Basic Auth 或 Digest Auth），或者静默失败。所以，纯前端 HTML 无法“实现”一个可交互的 401 认证挑战页；你看到的所谓“401 页面”，几乎全是服务端主动返回的 200 OK 响应，内容是自定义登录表单，和 HTTP 401 状态码无关。
为什么直接返回 401 + 自定义 HTML 不生效
当服务端返回 401 Unauthorized 并带上 WWW-Authenticate 响应头（如 WWW-Authenticate: Basic realm="api"）时，浏览器会拦截响应，不把 body 交给前端 JS 或 DOM 渲染。你写的 <h1>请登录</h1> 永远不会显示。
- Chrome/Firefox/Safari 都强制遵循 RFC 7235，不渲染 401 响应体
- 即使你用
fetch()请求并捕获response.status === 401，response.text()可能为空或被截断（尤其在 CORS 场景下） - 开发时用
curl -v能看到完整响应头+body，但浏览器不给你机会展示它
真正可行的替代方案：服务端返回 200 + 登录页
想让用户看到美观、可控的认证页面，必须让服务端避开 401 状态码，改用 200 OK 返回 HTML，并由前端控制跳转或弹窗逻辑。
- API 网关或后端路由判断用户未认证时，不返回
401，而是重定向到/login?from=/api/xxx（状态码302） - 或直接渲染登录页 HTML，HTTP 状态为
200，并在页面中通过fetch('/api/protected')触发真实鉴权请求 - 前端拿到
401后，不刷新页面，而是动态插入登录表单（此时是 JS 控制的 UI，非 HTTP 认证挑战） - 避免在
index.html里硬写<meta http-equiv="refresh" content="0;url=/login">，这破坏 SPA 路由体验
如果坚持要用 HTTP Basic Auth（极少数内网场景）
只能接受浏览器原生弹窗，HTML 页面仅作 fallback 或说明用途——但它不会在 401 响应中被加载。
- 服务端需同时返回
401和WWW-Authenticate: Basic realm="Intranet" - 可在 Nginx/Apache 的 error_page 中配置：
error_page 401 /401.html，但这只是静态文件服务，不带认证逻辑 - 注意：现代浏览器对
Basic Auth弹窗已限制自动填充、禁止 JS 拦截、且不支持自定义样式 - 移动端 Safari 完全禁用 Basic Auth 弹窗，直接报错
真正的难点不在 HTML 写得多漂亮，而在于厘清「HTTP 认证挑战」和「应用层登录流程」的区别。只要混淆这两者，所有前端代码都会失效。服务端是否暴露 WWW-Authenticate 头，决定了你有没有自由度——没暴露，你才能用 HTML；暴露了，你就得交出控制权。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
