根本原因是移动端常经CDN、WAF、WebView或Service Worker等中间层，导致URL被重写、截断或异常编码；需检查代理链、透传原始URI、确保404响应状态码正确且页面资源内联。
为什么手机访问HTML会404，而电脑不报错
根本原因不是设备差异，而是移动端常走代理链或中间层：CDN、WAF、APP内嵌WebView、PWA Service Worker。这些组件可能重写 request_uri、截断路径、强制添加前缀（如 /m/），或对 URL 中的 %2F、双斜杠 // 处理异常。
典型现象包括：curl -I http://yoursite.com/test.html 返回 200，但手机浏览器或微信内置浏览器打开却 404；日志里看到 REQUEST_URI 变成 /m//test.html 或 /test.html%2F。
- 用 PHP 记录真实请求路径：
error_log('UA: ' . $_SERVER['HTTP_USER_AGENT'] . ' | URI: ' . $_SERVER['REQUEST_URI'], 4);，再用手机访问，查error.log - Cloudflare 用户检查 Page Rules 是否匹配了
Mobile User-Agent并错误重定向 - Nginx 中若用了
rewrite，改用proxy_set_header X-Original-URI $request_uri;透传原始路径
HTML 404 页面本身必须返回 404 状态码
很多开发者只替换页面内容，却忘了 HTTP 状态码——这会让搜索引擎把你的“好看 404 页”当正常页面收录，长期损害 SEO。手机端尤其敏感，部分 WebView 会缓存 200 响应，导致后续真 404 也显示旧内容。
- 静态托管平台（如 GitHub Pages、Vercel）默认不支持自定义状态码，它们的“404 页面”本质是前端路由兜底，响应仍是 200 —— 别指望它能被爬虫正确识别
- PHP 脚本开头必须加：
http_response_code(404);，再输出 HTML - Nginx 配置中，
error_page 404 /404.html;是不够的，需确保/404.html所在 location 不返回 200，推荐加：location = /404.html { internal; } - 用
curl -I http://your-site.com/xxx或浏览器 Network 面板确认响应头含HTTP/1.1 404 Not Found
移动端 404 页面要克制加载外部资源
用户已经连不到目标页面了，再让 404 页去加载 CDN 上的 JS/CSS，很可能失败或超时，导致白屏、文字错位、按钮不可点。这不是设计问题，是可用性断点。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- CSS 内联进
<style>，不要<link rel="stylesheet"> - JS 尽量不用，非用不可就内联，且加
try...catch包裹，避免阻塞渲染 - 所有链接用绝对路径（如
https://yoursite.com/），别用相对路径./index.html—— 移动端 WebView 对 base URL 解析更脆弱 -
<title>必须含 “404”，例如<title>404 - 页面未找到</title>，否则用户从微信或搜索结果点进来，会误以为是首页
别依赖 window.location 跳转做“友好提示”
这是最隐蔽的坑：用 JS 检测到 404 后跳转到一个“好看页面”，但服务器仍返回 200 + 正常 HTML。用户看到的是“友好”，搜索引擎和分析工具看到的是“一切正常”，而真实问题被掩盖。
这种写法在手机上更危险——某些 Android WebView 会静默拦截 window.location，导致页面卡死或无限重定向。
- 真正的友好，是服务端直接返回 404 状态 + 语义化 HTML，而不是前端补救
- 如果必须做客户端跳转（比如单页应用 SPA），至少在跳转前手动设置状态码：
history.replaceState(null, '', '/404');，并确保后端对/404路径返回真实 404 - 主内容区用
<main>或<div role="main">，让屏幕阅读器跳过导航直读错误信息——这点在移动端语音辅助场景里很关键
实际调试时，最容易被忽略的是：你以为在修前端，其实问题在 CDN 或 Nginx 的 rewrite 规则里，而你正对着 HTML 文件改来改去。
