401响应必须由服务端返回标准HTTP 401状态码及WWW-Authenticate头才能触发浏览器原生认证弹窗；返回HTML页面（如200+401.html）无效且导致状态错乱、SEO污染等问题。
401 响应不该由前端 HTML 页面“实现”
浏览器收到 401 Unauthorized 响应时，会自动触发 HTTP 认证流程（如弹出 Basic Auth 对话框），此时返回 HTML 页面不仅无效，还会被忽略或导致行为异常。所谓“401 认证挑战页面”，实际是服务端未正确返回标准 401 状态码和 WWW-Authenticate 头，而是返回了 200 OK + 自定义登录页——这根本不是 HTTP 认证，只是前端路由拦截或表单登录。
真正触发浏览器认证对话框的必要条件
必须同时满足以下三点，浏览器才会弹出原生认证框：
- 服务端返回 HTTP 状态码
401（不能是200或302） - 响应头中包含合法的
WWW-Authenticate，例如：WWW-Authenticate: Basic realm="Restricted" - 请求是通过浏览器原生方式发起的（如直接访问 URL、
fetch()不带credentials: 'include'时可能被 CORS 阻断）
用 curl -I https://example.com/protected 可验证是否返回了正确的状态码和头；若看到 200 或缺失 WWW-Authenticate，那所谓“401 页面”只是个假象。
为什么用 HTML 模拟 401 页面容易出问题
常见错误做法：Nginx 或后端返回 200 + 一个叫 401.html 的静态页，并配 error_page 401 /401.html。这会导致：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 浏览器收不到
401状态码，不会触发任何认证逻辑 - 前端 JS 无法区分“真未授权”和“页面加载失败”，
fetch().catch()捕获不到401 - 如果用户已登录但 token 过期，服务端本应回
401，却返回了登录页，造成状态错乱 - 搜索引擎可能将该页误判为有效内容，影响 SEO
该怎么做：按场景分清楚责任边界
如果你控制服务端：
- 需要标准 HTTP Basic/Digest 认证 → 服务端返回
401+WWW-Authenticate，不返回 HTML - 使用 JWT 或 Session 登录 → 服务端对未认证请求返回
401，前端捕获后跳转到/login（这是应用层逻辑，与 HTTP 认证无关） - 想自定义未授权提示 → 返回
401状态码 + JSON：{"error": "Unauthorized"}，前端渲染友好提示，而非塞 HTML
如果你只写前端：别试图“实现 401 页面”，重点检查 fetch 或 axios 是否能正确收到 401 响应，并处理重定向或 token 刷新逻辑。
真正的难点从来不在 HTML 写得有多漂亮，而在于状态码、响应头、CORS 配置、credentials 模式这几处是否严丝合缝——漏掉任意一环，所谓的“认证挑战”就只是个静态摆设。
