HTML5页面部署后404错误主因是服务器路径配置、文件部署或路由不匹配；需检查静态资源是否存在、URL与实际路径是否一致、服务器根目录配置、History模式fallback规则、文件权限及CDN缓存。
HTML5 页面部署后出现 404 Not Found 错误，绝大多数情况不是 HTML5 本身的问题，而是服务器路径解析、文件部署或路由配置没对上。先确认静态资源是否真在服务器上、URL 是否和实际路径一致，再查服务端逻辑。
检查浏览器地址栏 URL 和实际文件路径是否匹配
这是最常被忽略的一步。HTML5 是纯静态文件，404 意味着服务器根本没找到对应路径的文件。
- 打开浏览器开发者工具（F12），切到
Network标签，刷新页面，看哪个请求返回了404—— 注意是 HTML 文件本身 404，还是script、css、图片等资源 404 - 如果是
index.html404，说明你访问的 URL（比如https://example.com/app/）没映射到真实文件位置（比如服务器上实际是/var/www/html/myapp/index.html） - 检查服务器根目录是否正确：Apache 默认是
DocumentRoot，Nginx 是root指令；确认你上传的index.html确实放在该目录下，且文件名大小写完全一致（Linux 区分大小写！） - URL 中带子路径（如
/myapp/）但没配base或重写规则，会导致相对路径引用的 JS/CSS 全部 404
HTML5 History 模式下刷新 404（Vue/React 路由常见）
单页应用（SPA）用 history.pushState 改变 URL 但不发请求，首次访问深层路由（如 /user/123）时，如果服务器没做 fallback 配置，就会直接 404。
- 现象：首页
/能打开，但手动刷新/about或直接访问该 URL 就 404 - 解决方法不是改前端代码，而是配服务器：让所有非资源请求（即非
.js、.css、.png等后缀）都返回index.html - Nginx 示例：
location / { try_files $uri $uri/ /index.html; } - Apache 示例（.htaccess）：
RewriteEngine On RewriteBase / RewriteRule ^index\.html$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.html [L]
检查文件权限与 Web 服务器用户读取能力
尤其在 Linux 服务器上，即使文件存在，也可能因权限问题导致 403（拒绝访问）或静默 404（部分配置下）。
立即学习“前端免费学习笔记（深入）”；
- 运行
ls -l index.html，确认文件权限至少是-rw-r--r--（644），所属用户/组能被 Web 服务进程（如www-data、nginx或apache）读取 - 检查父目录权限：Web 服务器需要对整个路径有
x（执行）权限才能进入目录，例如/var/www/html目录权限不能是600 - SELinux 启用时（如 CentOS/RHEL），可能拦截访问，临时测试可运行
setenforce 0看是否恢复；确认后用chcon或semanage修复上下文
CDN 或反向代理缓存了旧的 404 响应
某些 CDN（如 Cloudflare）或 Nginx 反向代理会缓存 404 响应，即使你已修复文件，仍持续返回 404。
- 用
curl -I https://yoursite.com/index.html查看响应头，关注X-Cache、Age、CF-Cache-Status等字段 - 如果是 Cloudflare，进仪表盘 →
Caching→Configuration→ 关闭Cache 404s（默认关闭，但可能被手动开启过） - Nginx 反向代理中，检查是否有
proxy_cache_valid 404 1m;类似配置，临时注释掉并 reload - 强制刷新 CDN 缓存：Cloudflare 的
Purge Everything，或针对具体 URL Purge
真正卡住的地方往往不在 HTML5 规范，而在路径拼写、大小写、服务器配置层级、CDN 缓存策略这些“看不见”的环节。先抓 Network 看清哪个请求 404，再顺着那个 URL 往服务器文件系统里一层层找，比猜原因快得多。
