企业官网建设流程全解析

torchvision 下载 MNIST 时突然抛一个unexpected status 404 not found，conda 装包时来一句http 404 not found for channel pkgs/pro，甚至办公室打印机管理页面都甩给你一个can't locate document: /notsupported.asp——这些 404 我全都遇到过。每次第一反应是"怎么又找不到资源"，但冷静下来才发现，404 是所有 HTTP 状态码里信息量最大、也最容易被误读的一个。

这篇分享想做的只有一件事：把"界面 404"这件事拆开，讲清楚 404 到底是谁返回的、什么情况下会出现、怎么一步一步定位到根因。我不只讲浏览器里那个大白页，还会把前后端开发、数据下载、包管理器、嵌入式设备管理面板这几类我踩过坑的场景都过一遍。无论你是前端、后端、算法工程师，还是被设备面板折腾的普通用户，里面都有一套能直接拿去用的排查方法。

1. 404 的真实含义：先搞懂它在哪一层返回的

1.1 状态码家族里的 404：网络是通的，服务器也是活的

HTTP 状态码分五大类：2xx 表示成功，3xx 表示重定向，4xx 表示请求方（客户端）有问题，5xx 表示服务方（服务器）有问题。404 落在 4xx 里，官方定义是 "Not Found"，也就是服务器收到了请求，但找不到对应的资源。

这里有一个特别反直觉的结论：出现 404 恰恰说明网络是通的、服务器是活的。如果你的请求压根没发出去，或者中途断网、服务器宕机，你看到的通常不是 404，而是浏览器自己的错误页、连接超时提示，或者 502/504 这类网关错误。404 意味着请求已经成功到达了某个服务器，只是这个服务器上找不到你要的东西。

打个比方：404 就像你打电话到一家公司总机，电话能打通，前台也接了，她帮你查了一圈人员名单，最后告诉你"没有这个人"。这跟"电话打不通"是两码事。

为了把 404 放在正确的位置，我列了个常用状态码对照表，方便你一眼看出它和 403、500 的区别：

很多新手会把 403 和 404 搞混。两者最大的区别在于：403 是"我知道资源存在，但不给你看"，404 是"服务器上查无此资源"。有意思的是，有些安全防护系统为了不暴露敏感资源的真实存在性，会对无权限访问也返回 404，这是在故意混淆——但这又是另一个话题了，你只要知道有这种可能就行。

1.2 404 也可能来自中间层：代理、网关、CDN 都会"假装"404

这是最容易被忽略的一点。一个正常请求走完的完整链路通常是：

浏览器/客户端 -> 本地代理（如果有） -> DNS -> 反向代理/网关 -> CDN -> 应用服务器 -> 代码

这一路上的每一层都可能返回 404，而且浏览器页面看起来一模一样。也就是说，你看到的 404 未必来自后端应用，可能来自中间的任何一层。

我自己就遇到过好几次这样的情况：本地跑着一个 HTTP 抓包调试工具，它监听的是 8888 端口，但系统代理里还填着老的 8899 端口。结果所有请求都先转发到那个不存在的代理端口上，调试工具压根没接住，请求发不出去，然后程序报了个 404 或者连接异常。这种问题在报错信息里经常长得像request failed with status code 404，但实际上根本不是目标服务器返回的。

再比如 Nginx 反向代理。你的后端接口明明活着，但因为 Nginx 的location规则没匹配上，请求根本没转发到后端，Nginx 自己就回了一个 404。源站日志里干干净净，一条请求记录都没有，这时候你排查后端代码是查不出任何东西的。

所以定位 404 的第一原则是：先确认这个 404 是链路中哪一层返回的。最简单的办法是打开浏览器的开发者工具，看响应头里的Server字段。它是 nginx、是 Apache、是某个云厂商 CDN 的标识、还是你后端框架（Express、Flask、Spring Boot 等）自动生成的默认响应头，能直接告诉你这层是谁。把这层搞清楚了，排查范围至少缩小一半。

2. 先别急着改代码：用户侧 404 的几大隐形坑

2.1 URL 本身的问题：大小写、扩展名、协议和端口

很多 404 压根不用动代码，就是 URL 本身写错了。最典型的是大小写问题。Linux 服务器上的文件系统和路由匹配是区分大小写的，/User/Profile和/user/profile在服务器看来是两个完全不同的地址。Windows 本地开发环境不区分大小写，所以本地怎么访问都正常，一部署到 Linux 上就 404——这是新手最容易踩的坑，没有之一。

然后是扩展名。同一个页面可能同时存在.html和.htm版本，或者老的.asp、.php版本，链接里写的是旧扩展名，服务器自然找不到。还有 URL 结尾的斜杠，/about和/about/在某些服务器配置下不是同一个路由。

协议和端口也是重灾区。公司内部有些老系统只支持 HTTP，你用 HTTPS 去访问，页面打不开或者被重定向到一个不存在的路径，最后变成 404。还有非标准端口：比如服务跑在 8080，你直接输http://example.com不带端口，默认走 80，服务根本不在那里。

中文路径和特殊字符也不能忽视。URL 里的中文如果没有做 URL 编码（变成%E4%BD%A0%E5%A5%BD这种），服务器可能解析失败。Windows 和 Mac 的复制行为也不一样，从聊天工具复制链接时，如果链接被截断成两段，粘贴过来就不完整，这种"残缺 URL"访问过去当然 404。

2.2 缓存与 DNS：看起来是 404，其实是"旧东西"在捣乱

还有一类 404 特别迷惑人：资源其实是存在的，但你看的是旧页面、旧缓存。比如页面更新了，但浏览器把旧的 HTML 缓存住了，旧 HTML 里引用的 CSS/JS 文件已经在新版本里改名了（前端构建产物经常带 hash），于是刷新页面时，浏览器去请求一个服务器上已经不存在的旧文件，返回 404。表现就是页面结构还在，但样式全没了，控制台一堆 404。

本地 DNS 缓存也可能导致类似问题。域名解析记录变了（比如 CDN 节点切换、换服务器 IP），但你的电脑还记着旧 IP，请求打到一台已经不再提供服务的旧机器上，自然 404。

遇到这种情况，最快的验证方法是：开一个无痕窗口试试。无痕模式不会加载大部分缓存，如果无痕窗口正常而普通窗口 404，基本可以断定是缓存问题。再进一步，可以按Ctrl+F5（Windows）或Cmd+Shift+R（Mac）强制刷新，清掉当前页面的缓存重新加载。

如果换浏览器也不行，可以再换个网络试试——比如把 WiFi 换成手机热点。如果在另一个网络下访问正常，说明你当前网络上某个环节（内网代理、DNS、路由器缓存）把请求引导到了错误的地方。

2.3 用户侧快速排查清单

我把这些经验整理成一份可以"抄作业"的排查清单，遇到 404 先按顺序过一遍：

1. 核对 URL 拼写，特别注意大小写和扩展名。
2. 确认协议是 HTTP 还是 HTTPS，端口有没有写对。
3. 用无痕窗口重新打开，排除浏览器缓存。
4. 换个浏览器或换台设备访问，排除单机问题。
5. 换个网络（手机热点）访问，排除当前网络路径问题。
6. 用搜索或网站导航重新进入，而不是直接输入记忆中的 URL。
7. 如果页面之前能打开、现在 404，可能是资源被删了或整站改版，可以去公告栏或联系管理员确认。

这七步做完，80% 的用户侧 404 都能清理掉。剩下还没解决的，就得往开发侧查了。

3. 开发者视角的高发地带：前端路由、网关和静态资源

3.1 前端 SPA 刷新 404：history 路由的经典翻车

这是前端开发里最经典、最频繁的 404 场景。Vue Router 和 React Router 都有两种路由模式：hash模式和history模式。hash模式 URL 里带#，比如example.com/#/user/123，这个#后面的内容不会被发送到服务器，所以刷新永远没问题。而history模式是纯路径，比如example.com/user/123，看起来很好。

问题就出在这儿：history模式下，如果我在/user/123页面按 F5 刷新，或者直接把这个 URL 发给别人让别人打开，浏览器会向服务器真实发起一个GET /user/123的请求。服务器上根本没有user/123这个文件，Nginx 找不到，返回 404。

很多人第一次遇到会怀疑后端接口问题，其实不是。这个 404 的根因是：前端路由是"假的"，真正的入口只有一个index.html，所有 URL 都应该由前端 JS 来决定渲染什么页面。服务器要做的事情很简单：当收到的请求路径不是真实存在的静态文件时，统统返回index.html，让前端路由接管。

Nginx 里一行配置就能解决：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }

关键在try_files $uri $uri/ /index.html。它的意思是：先找对应文件，找到就返回；再找对应目录，找到就返回；都找不到，退回index.html。

不过这只是解决了"页面刷新"的 404。还有一类更隐蔽的：页面框架能打开，但 JS、CSS 资源 404，整个页面白屏。这种通常是publicPath配置不对。比如前端资源部署在服务器的/app/子目录下，但构建时base（Vite）或publicPath（webpack）配成了/，所有资源都会从根目录去加载，自然找不到。检查方式就是看页面源码里<script src>和<link href>的路径，和实际文件路径对一下就知道问题在哪。

3.2 后端接口 404：路由没对上，请求压根没进来

后端接口出现 404，常见原因有这么几类：

第一，HTTP 方法不匹配。前端发的是POST /api/user，后端路由只定义了GET /api/user，框架会回 404（有些框架回 405 Method Not Allowed，但很多默认是 404）。这点在前后端联调时特别容易出问题，因为前后端对"这个接口该用什么方法"的理解经常不一致。

第二，路径参数不匹配。后端定义的是/user/{id}，前端拼成了/user?id=123，这俩在严格路由下不是同一个接口。或者定义的是/user/123，前端请求的是/user/123/，多了一个斜杠也匹配不上。

第三，网关转发路径错了。微服务架构下，前端请求/api/order，但 API 网关要求转发到order-service/order，如果 Nginx 的proxy_pass路径拼接规则不对，请求到不了真正的服务。这种问题最坑的是：你直接访问后端服务（比如localhost:8080/order）是正常的，但从前端路径进来就是 404。

判断这类问题的核心方法就一个：看后端日志里有没有收到这个请求。打开后端应用的访问日志，搜索这个接口路径。如果日志里什么都没有，说明请求压根没到达后端，问题出在 Nginx、网关或前端请求本身；如果日志里有记录，再看框架返回的具体错误。这是分层定位最有效的手段。

用curl复现是最直接的。比如前端报错request failed with status code 404，你可以在命令行手动发一个同样请求：

curl -v http://localhost:8080/api/user/123

-v会打印完整请求和响应过程，你可以看到请求发到了哪、返回了什么。如果本地直接访问后端接口是通的，那 404 一定出在中间链路。

3.3 静态资源 404：发布与回滚的版本问题

这类 404 发生在发版和回滚时，表现很典型：用户反馈"页面打不开"，或者"样式全丢了"，但开发环境一切正常。

原因往往在资源版本不一致。现代前端构建会生成带 hash 的文件名，比如app.8a2f9c.js。JS 文件内容变了，hash 就会变。发版时如果只更新了一部分文件，或者 CDN 缓存还没刷新，就会出现：HTML 是新版本，引用的却是app.a1b2c3.js，而服务器/CDN 上已经把这个旧文件清掉了，404 随之而来。

还有一种常见于回滚的场景：发布新版本后发现问题要快速回滚，代码回滚到旧版本了，但静态资源目录被新版本覆盖，导致旧 HTML 引用的旧 hash 文件不存在。这也是 404。

这类问题的排查思路：

1. 打开页面，F12 看 Network，找到返回 404 的资源 URL。
2. 对比 HTML 源码里script标签引用的文件名和服务器实际文件列表。
3. 看响应头里的Server字段和X-Cache之类的字段，判断 404 是源站返回的还是 CDN 返回的。
4. 如果请求 URL 指向 CDN，但源站上其实有该文件，可能是 CDN 缓存配置或回源配置有问题。

解决方向也很明确：发版时静态资源先全量上传，再更新 HTML；回滚时保留上一版本资源目录，不要直接删除；CDN 上对静态资源设置合理的缓存时间，并在发版后做一次预缓存预热。

3.4 一套从浏览器到代码的定位顺序

把上面这些串起来，我总结了一套固定的定位顺序，遇到开发侧 404 就按这个走：

1. 打开开发者工具 Network 面板，找到失败的请求，看三样东西：请求 URL、状态码、响应头里的 Server 字段。
2. 判断请求是否发到了正确的主机：看 Network 里的 Remote Address，和预期服务器 IP 对不对得上。
3. 用 curl 复现这个请求，加上-v看完整链路。
4. 去服务器上看访问日志，确认请求是否到达了目标应用。
5. 按日志里应用的返回结果，逐层向上或向下排查。

标准的 Nginx 访问日志格式里，一行就是一个请求，包含时间、客户端 IP、请求方法、路径、状态码。用tail -f实时盯着日志，然后手动触发一次访问，马上就能看到请求到底有没有进来。

4. 数据下载和包管理器的 404：MNIST 与 conda channel 实战

4.1 torchvision 下载 MNIST 报 unexpected status 404 not found 的完整处理

算法工程师应该都见过这个报错：unexpected status 404 not found，场景几乎都是torchvision.datasets.MNIST设置download=True去拉数据的时候。我第一次遇到也很懵，因为前一天还好好的，第二天就怎么都下载不下来。

先说根因。torchvision的 MNIST 数据集默认从 Yann LeCun 维护的官方地址下载。这类学术网站的服务器放在校园网里，稳定性本来就不高，URL 变更、目录调整、服务器维护都可能导致下载链接失效。一旦某个文件在服务器上不存在，下载过程就会抛出 404。而torchvision的错误处理比较直接，会把 HTTP 状态码原样抛出来，于是你就看到了unexpected status 404 not found。

处理的完整流程是这样的：

第一步，确认到底哪个 URL 返回了 404。你可以在 Python 里先拿到下载地址自己访问一下：

import torchvision dataset = torchvision.datasets.MNIST(root="./data", train=True, download=False) for url in dataset.urls: print(url)

老版本 torchvision 的 MNIST 类里有一个urls属性，打印出来就是你实际要去下载的文件地址。拿到 URL 后用浏览器或 curl 访问，如果能复现 404，基本确认是源站问题；如果浏览器能访问，那可能是你当前 Python 进程的网络环境有问题。

第二步，用镜像源。新版 torchvision 的MNIST类支持mirror参数，可以指定镜像地址。我自己常用的镜像地址是 OpenMMLab 提供的：

torchvision.datasets.MNIST( root="./data", train=True, download=True, mirror="https://oss.openmmlab.com/datasets/mnist/" )

这个镜像的目录结构兼容 torchvision 的下载逻辑，文件放到位后它会自动识别已下载的数据，不用你手动改任何东西。

第三步，手动下载文件放目录。如果你的 torchvision 版本太老，不支持mirror参数，那就手动下载。MNIST 一共四个 gz 压缩包，按表放置：

放好之后再运行同样的代码，但把download设为False，torchvision检测到 raw 目录下的文件完整，就会跳过下载直接进入数据处理。

torchvision.datasets.MNIST(root="./data", train=True, download=False)

这里有个坑要提醒一下：一定要四个文件全放齐，缺一个它都会尝试重新下载，而且可能覆盖你已经放好的文件。另外注意别把 gz 文件解压了再放进去，torchvision 要的是压缩包本身。

4.2 conda 安装报 http 404 not found for channel pkgs/pro

conda 用户应该见过这个经典报错：

UnavailableInvalidChannel: HTTP 404 NOT FOUND for channel pkgs/pro <https://repo.anaconda.com/pkgs/pro>

报错信息里的pkgs/pro是 Anaconda 商业订阅仓库对应的 channel。如果你用的是社区版 Anaconda 或 Miniconda，但 conda 配置里的 channels 列表包含了pkgs/pro，conda 就会去repo.anaconda.com/pkgs/pro拉取元数据，这个目录对非订阅用户不可用，服务器返回 404，于是整个安装过程就被这个 channel 卡住了。

排查和解决步骤：

第一，查看当前的 channel 配置：

conda config --show channels

如果看到输出里含pkgs/pro或其它看起来不像常规源的地址，基本就是问题所在。有时候是网上教程让加的，有时候是某次配置污染了.condarc文件。

第二，移除错误的 channel：

conda config --remove channels pkgs/pro

或者直接编辑用户目录下的.condarc文件，把 channels 列表清理干净。

第三，验证可用的 channel。最稳妥的做法是只保留defaults或者加入conda-forge：

conda config --append channels conda-forge conda config --set channel_priority flexible

这里补充一点：channel_priority也会引发"看似 404 的问题"。设置成strict时，conda 只从优先级最高的 channel 里找包，找不到直接报错，不会去低优先级 channel 找。这时候报错信息里经常带一个 404 或者 "not found" 的字样，但本质不是 URL 写错，而是包确实不在你指定的这个 channel 里。把优先级改成flexible，或者显式指定 channel 安装就好了。

另外，如果你在内网环境，可能需要配置 HTTP 代理才能让 conda 访问外网源。当代理配置写错、指向了一个不存在的转发地址时，conda 也可能会报出各种异常，你要区分清楚：连接不上通常是超时或者ProxyError，而 404 一定是请求到达了服务器、但目标 channel 不存在。这个区别能帮你少走弯路。

4.3 接口调用里的 404：第三方 API 和批量任务的处理方式

日常工作中，用requests或其它 HTTP 库调第三方接口时遇到request failed with status code 404，那含义就简单很多了：你请求的 URL 在对方服务器上不存在。

但"不存在"的原因有两种，需要分开看。一种是自己的问题：URL 拼错了、API 版本号写错了、路径里混入了动态参数但没有做编码、接口已经从/v1/user升级到了/v2/user但代码没更新。另一种是对方的问题：某个资源确实被删除了，比如按 ID 查询一条已经删掉的数据。

正确的处理姿势是：不要只捕获异常，要把响应的 body 打出来看。很多第三方 API 的 404 响应体里带了详细的错误码和说明，比如{"code": "RESOURCE_NOT_FOUND", "message": "item with id xxx not found"}。这些信息比状态码有用得多。

import requests url = "https://api.example.com/v1/items/rs_7122ac406e064a50_0" try: resp = requests.get(url, timeout=10) if resp.status_code == 404: print("资源不存在:", resp.text) # 在这里决定是重试、跳过还是报警 resp.raise_for_status() except requests.exceptions.HTTPError as e: print("HTTP 错误:", e)

在批量下载、爬虫这类任务里，404 更不应该被当成致命错误。它往往只是代表"这一条数据不存在"，程序应该跳过它继续处理下一条。我曾经见过一段爬虫代码，遇到任何异常就sys.exit(1)，结果一个 404 导致整个任务中断，运维三更半夜被叫起来处理。正确做法是：把 404 归类为"可跳过"错误，记录日志后继续，只有连续大量 404 才触发告警。

5. 设备管理页面的 404：旧固件、精简 Web 服务器和 notsupported.asp

5.1 嵌入式管理界面为何这么容易 404

家用路由器、打印机、网络摄像头、NAS，这类设备的后台管理界面也会出现 404。比如浏览器访问路由器管理页，跳出一个：

Access error: 404 -- Not Found Can't locate document: /notsupported.asp

我第一次看到notsupported.asp这种路径时愣了一下，后来才明白，这不是什么深奥的问题。嵌入式设备的 Web 管理界面通常跑在一个精简的 HTTP 服务器上，资源有限，能处理的页面路径都是写死的，比如/、/index.asp、/login.asp这几个。当你在浏览器地址栏输入了一个它没定义的路径，或者固件版本变更导致某些页面被移除，它就会返回这个 404 页面。

/notsupported.asp本身是设备固件里自带的一个"页面不存在"提示页，相当于我们常见的404.html。看到这个路径，一般说明两种可能：一是你访问的路径不在设备的页面清单里，二是设备的固件版本太老或太新，和它默认的页面清单不匹配。

还有一个非常隐蔽的原因：访问方式不对。很多老设备的管理界面只支持纯 HTTP 访问，你如果用了 HTTPS，设备内部没有对应的 HTTPS 虚拟主机配置，请求匹配不到任何页面，就会返回 404。或者你带了非标准端口，比如http://192.168.1.1:8080，设备的 Web 服务根本没监听这个端口，连接会失败或返回 404。

5.2 实际排查一个设备管理界面 404 的流程

排查这类设备 404，我有一套固定的流程，分享出来供你参考：

1. 确认设备 IP 和端口。路由器管理地址通常是192.168.1.1或192.168.0.1，但不同品牌可能不一样。查看设备背面标签，或连接设备后用ipconfig（Windows）查网关地址。打印机则在面板上找网络设置里的 IPv4 地址。

2. 先用 curl 验证基础连通性，不要急着开浏览器：

curl -v http://192.168.1.1/

如果返回了一堆 HTML，说明设备的 Web 服务是活的。如果 curl 返回 404，再用https://试试；如果 curl 正常但浏览器 404，问题大概率出在浏览器配置。

3. 检查浏览器是否走了代理。浏览器设置里如果配置了代理服务器（公司内网代理或本地抓包工具代理），访问设备管理地址时，请求会被转发到代理服务器而不是直接发给路由器。代理服务器上自然没有192.168.1.1这个资源，返回一个 404。这种情况在排查时特别容易漏，因为看起来"浏览器打不开设备后台"，实际上请求根本没到设备。

4. 尝试不同的默认路径。有些设备虽然主路径 404，但特定文件名可以访问，比如/index.asp、/login.asp、/home.asp。这能帮你判断是设备页面整体被移除，还是你访问的路径不对。

这里要特别提醒一句：设备管理页面 404 时，不要第一反应就去升级固件。固件升级有风险，而且如果旧固件的管理路径被新固件改了，升级后反而可能彻底进不去后台。先确认是路径问题还是访问方式问题，再考虑固件动作。

6. 把 404 测出来、防出去：日志统计、监控与回归验证

6.1 从访问日志里识别"被动 404"还是"产品事故"

线上系统里，404 不全是坏事。爬虫乱扫产生的 404、用户手输错 URL 产生的 404、死链产生的 404，这些属于"被动 404"，防不胜防；但如果是发版后某个页面突然大量 404，那就是产品事故，需要立即处理。

区分方法是看访问日志里 404 的分布。我通常的做法是先聚合统计，看哪些路径 404 最多。Nginx 默认的 access log 一行类似：

127.0.0.1 - - [18/Jul/2025:10:15:23 +0800] "GET /api/order/123 HTTP/1.1" 404 153 "-" "curl/8.0"

用 awk 快速统计 404 的 URL 排行：

awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

如果你的 Nginx log_format 不是默认格式，$9可能不是状态码，需要按你自己的字段顺序调整。想更精确的话，用正则匹配 Python 脚本：

import re from collections import Counter url_counter = Counter() pattern = re.compile(r'"(?:GET|POST|PUT|DELETE) (\S+) HTTP/[\d.]+" 404') with open("/var/log/nginx/access.log", "r", encoding="utf-8", errors="ignore") as f: for line in f: m = pattern.search(line) if m: url_counter[m.group(1)] += 1 for url, count in url_counter.most_common(20): print(f"{count}\t{url}")

聚合出来之后分三类看：第一类是明显不存在的路径，比如各种.php、.env、/wp-admin，多半是扫描攻击，忽略或封禁；第二类是已知的旧链接，说明需要做 301 跳转把老用户导到新地址；第三类是发版相关的路径，比如刚才说的带 hash 的静态资源 404，这类要立即处理，因为它意味着有真实用户在访问一个残缺页面。

6.2 把 404 监控起来：比例告警比绝对值告警可靠

404 的数量本身没有太大意义，因为爬虫随时可能制造大量 404。真正值得关注的是404 占比的突然变化。比如平时 404 占总请求的 0.5%，发版后突然涨到 5%，那基本可以确定是发布导致的问题。

监控上，我建议做两层：

第一层，日志里统计 404 比例，做阈值告警。常见工具是 ELK、Loki，或者简单的定时脚本。告警阈值不要设成固定数字，按"过去 15 分钟 404 数量超过前 7 天同时间段的 3 倍"这种动态方式，误报会少很多。

第二层，在上线流程里加 URL 回归检查。发布脚本里跑一遍关键 URL 列表，用 curl 校验状态码，200 才通过。这个列表要包含首页、核心页面、核心接口、几个静态资源。不要嫌麻烦，我曾经因为漏掉一个静态资源目录的检查，上线后样式全丢，几百个用户看到了裸奔页面，血的教训。

6.3 设计一个真正有用的 404 页面

技术层排查完了，最后说说产品层的 404 页面。一个真正有用的自定义 404 页面，应该做到这几件事：

• 明确告诉用户"页面不存在"，而不是让用户以为网站挂了；
• 提供返回首页的链接和相关热门入口；
• 给一个错误反馈入口，让用户把"他访问的 URL"提交给你，这等于免费给你收集信息；
• 不要把这个页面做成另一个会触发 404 的重定向，有些站点自定义 404 页面里的资源路径写错，导致页面加载了一堆 404 资源，那就尴尬了。

在产品上线前，把 404 页面纳入测试范围，也是质量保障的一部分。至少确保GET /此页面不存在返回的是 200 状态码的自定义 404 页面，而不是服务器默认的纯文本 404——这个状态码差别会影响搜索引擎对抓取的判断，也会影响用户的信任感。

最后分享一点个人经验。我踩过这么多 404 的坑之后，最大的体会是：接到"界面 404"的反馈，第一件事绝对不是去改代码，而是先去复现、去确认 URL。大部分 404 不是程序逻辑问题，而是路径问题——拼错了、写错了、配错了、放错了位置。把这个思路养成本能，能帮你省下大量的排查时间。

我还保持着一个很小的习惯：遇到任何 404，先curl -I一下再打开浏览器。一行命令，几秒钟，能确认请求到底发到了哪里、哪一层返回的 404。这个习惯帮我避开了无数"瞎猜半天最后发现是缓存"的弯路。希望这篇分享，也能让你在下次撞见 404 时，比之前更快地找到答案。