企业官网建设流程全解析

团队协作里经常出现这样的场景：前端说“接口报 500 了，后端看一下”，后端打开本地服务试了试说“我这儿跑得好好的，你清下缓存”，测试插一句“昨天还是好的，今天就不行了”，三个人来回拉扯半小时，最后发现谁都没写错代码，是测试环境的网关配置被覆盖了。

这样的场景几乎每天都在无数团队里重复上演。问题从来不是大家不会修 BUG，而是拿到一个 BUG 报告时，第一反应是打开 IDE 看代码，而不是先回答一个更关键的问题：这个 BUG 到底属于前端、后端，还是环境？

定位错层级，是排查效率最大的杀手。一个 500 错误，可能是后端接口真的崩了，也可能是网关把请求转发错了，还可能是前端把参数格式传成了后端无法解析的结构。如果一开始就朝着错误的方向去查，再熟练的工程师也可能在无效路径上消耗半天。

这篇文章会从三个层面展开：先讲清楚前端、后端、环境各自的职责边界，再给出一套可以逐层执行的 BUG 归属定位方法，最后用案例复盘和快速对照表说明那些最容易引发扯皮的“归属模糊型 BUG”到底该怎么处理。读完你会得到一套在前后端分离项目里通用的排查方法论——不依赖某一种具体框架，拿到任何诡异问题都能按步骤拆解。

1. 为什么“定位归属”比“动手修复”更重要

很多开发者在拿到 BUG 时的第一反应是“赶紧改”。这个直觉需要纠正一下：在前后端分离的项目里，一个用户可见的异常，往往是整条调用链上某个环节出问题的最终表现，而不是问题本身。

举个最典型的例子：前端页面上点击“保存”按钮没有反应。这个现象可能的原因包括：

• 前端点击事件没绑定成功，请求压根没发出去；
• 前端把数据序列化成了 JSON，后端却期望 form-data，接口直接解析失败；
• 后端接口正常，但数据库连接池满了，请求排队超时；
• 后端代码没问题，但 Nginx 把请求转发到了已经下线的旧服务节点；
• 浏览器缓存了旧的 JS 文件，页面跑的还是上一次发布的代码。

同一个现象，五个完全不同的原因，分布在三条完全不同的技术链路上。如果归属判断错了，比如明明问题在 Nginx 转发配置，前端却花了两个小时检查按钮交互代码，那排查效率几乎是零。

从成本角度看，修复和定位的成本也严重倒挂。一个 BUG 的修复往往只需要一两行代码，甚至只是改一个配置项；但定位它可能需要几十分钟甚至数小时。定位效率决定整体排障效率，而定位效率的核心，就是先做层级归属判断。

从团队协作角度看，归属判断也是减少无效沟通的关键。没有定位依据就抛出“前端有问题”“后端有问题”的结论，本质上是在甩锅。真正专业的做法是带着证据说话：“Network 面板显示请求在 3 秒后超时，后端日志里没有这条请求记录，我怀疑是网关或网络层的问题，麻烦帮忙看下 Nginx 日志。”——这才是有效的跨端协作。

所以这篇文章的第一个核心判断就是：排障的第一性原理不是修，而是定界。把问题准确定位到某一层，排查工作就已经完成了八成；剩下的修复动作，通常只是顺水推舟。

2. 前端 BUG、后端 BUG、环境 BUG 的职责边界

要做好归属判断，第一步是把三条链路的职责边界画清楚。前后端分离架构看似简单——前端发请求、后端回响应，但中间还夹着一层经常被忽略的运行环境。很多说不清归属的 BUG，其实都发生在“环境”这个灰色地带。

2.1 前端 BUG 的边界

前端负责从用户点击到请求发出、从响应接收到界面渲染的整个过程。前端 BUG 通常表现为以下几类：

• 交互逻辑错误，比如按钮点击后事件没触发、表单校验误判；
• 数据渲染错误，比如接口数据拿到了但页面显示空白、字段映射错位；
• 兼容性问题，比如某个功能在 Chrome 上正常，在 Safari 或旧版浏览器上异常；
• 状态管理问题，比如跨页面数据不同步、缓存数据未更新。

前端 BUG 有一个显著特征：它在浏览器里就能看到直接线索。开发者工具中的 Console 面板、Network 面板、Sources 断点，基本都是为定位前端问题准备的。

2.2 后端 BUG 的边界

后端负责接收请求、执行业务逻辑、读写数据库、调用第三方服务，最后返回响应。后端 BUG 通常表现为：

• 接口逻辑错误，比如参数校验不严、业务状态判断失误；
• 数据处理错误，比如 SQL 写错、事务未回滚、并发处理不当；
• 系统集成问题，比如调用第三方接口超时、消息队列消费异常；
• 性能问题，比如接口响应慢、数据库慢查询、内存溢出。

后端 BUG 的判断依据主要是接口返回值、日志和监控数据。一个训练有素的后端工程师，看到异常栈和日志就该能判断问题出在业务代码、数据库还是外部依赖。

2.3 环境 BUG 的边界

环境 BUG 是容易被忽略但实际上非常高发的一类。它不属于某个具体业务代码，而是运行环境不一致引发的异常。典型包括：

• 配置差异：不同环境的数据库地址、Redis 地址、第三方服务密钥不同；
• 依赖版本差异：Node 依赖、Maven 依赖、Python 包的版本不一致；
• 网络环境差异：代理、DNS 解析、防火墙规则不同；
• 缓存问题：浏览器缓存、Redis 缓存、CDN 缓存没有及时失效；
• 资源限制：磁盘空间不足、内存不足、文件描述符耗尽；
• 系统时间不同步：证书校验失败、签名过期、Token 无效。

环境 BUG 最大的迷惑性在于：代码看起来完全一样，但换个环境结果就不同。这类问题如果不用“环境对比”的思路去查，很容易陷入“这代码明明没问题啊”的死循环。

以下表格可以快速帮你判断一个 BUG 通常落在哪一层：

边界画清楚了，下一步就是具体的方法论。

3. 前端 BUG 的识别与定位方法

前端 BUG 的定位，最核心的工具就是浏览器开发者工具。无论你用的是 Vue、React 还是原生 JavaScript，排查路径基本一致。

3.1 先开 Network 面板，看请求是否发出

拿到一个前端异常报告，我建议第一件事是打开 Network 面板，刷新页面并复现操作，然后观察：

• 有没有请求发出？如果点击按钮后 Network 面板没有任何新增请求，说明问题出在前端逻辑：事件没绑定成功、JS 执行报错中断、或者条件判断没有进入发请求的分支。
• 请求状态是什么？如果请求显示为红色，状态码是 4xx 或 5xx，说明请求已经到达服务器，问题可能在后端，也可能在前端传参错误导致后端拒收。
• 请求耗时是多少？如果请求显示 pending 状态好几分钟，说明请求发出去后一直没有收到响应，这更像是后端处理慢或网络层异常。

这一步其实是把“前端 BUG”和“后端 BUG”区分开的最快方法。有一个经验法则：Network 面板里能看到请求，后端就说不上完全无辜；看不到请求，那问题大概率在前端。

3.2 再开 Console 面板，看 JS 是否报错

Console 面板会展示所有 JavaScript 运行时错误。常见的报错类型包括：

• 某个变量是 undefined，访问它的属性时报 TypeError；
• JSON.parse 解析了非 JSON 字符串；
• 跨域请求被浏览器拦截（CORS 错误）；
• 引入的某个第三方库版本不兼容。

这些报错通常直接指明了代码文件和行号，顺着 Source 面板打断点就能定位。需要提醒的是，有些前端错误是“静默失败”的——代码没有抛异常，但业务逻辑没执行。这时候要看 Network 面板有没有发出请求，以及 Vue/React 开发者工具里的组件状态是否正确。

3.3 用前端请求拦截器统一打印请求日志

实际项目中，每个页面都手动 console.log 一遍请求参数是不可行的。更规范的做法是在请求库中统一加拦截器，把请求和响应打印出来。这样排查问题时，只要打开控制台就能还原完整的请求链路。

下面是一个基于 axios 的请求日志示例：

// 文件路径：src/utils/request.js import axios from 'axios' const request = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：打印请求参数 request.interceptors.request.use(config => { console.log(`[请求] ${config.method.toUpperCase()} ${config.url}`, config.params || config.data || '') return config }) // 响应拦截器：打印响应内容，统一处理异常 request.interceptors.response.use( response => { console.log(`[响应] ${response.config.url}`, response.data) return response }, error => { if (error.response) { console.error(`[异常] ${error.config.url} 状态码 ${error.response.status}`, error.response.data) } else if (error.request) { console.error(`[超时或无响应] ${error.config.url}`, error.message) } else { console.error('[请求未发出]', error.message) } return Promise.reject(error) } ) export default request

这段代码的核心价值在于区分三类情况：

• 请求拦截器里的日志没打印，说明请求压根没到发送这一步，问题在前端调用方；
• 请求日志打印了，但响应拦截器报“超时或无响应”，说明请求发出后网络层或后端出了问题；
• 响应日志打印了，但页面渲染错误，说明问题在前端数据解析或渲染逻辑。

有了这套日志体系，前端 BUG 和后端 BUG 之间的模糊地带就能大幅缩小。

3.4 前端 BUG 的典型特征汇总

• Network 面板里看不到请求，Console 里有 JS 报错，通常是前端逻辑问题；
• Network 面板里能看到请求，但状态码是 4xx，通常是前端传参有问题或后端校验失败，需要结合后端响应内容判断；
• Network 面板显示请求成功（200），响应 JSON 也正常，但页面数据没变，问题通常在前端状态管理或组件更新逻辑；
• 同一个功能在本地正常、在线上异常，优先考虑是不是发布后前端代码被缓存。

4. 后端 BUG 的识别与定位方法

后端 BUG 的定位，核心是读接口返回、读日志、读监控。和后端协作时，最忌讳的就是没有日志依据就下结论。

4.1 先看 HTTP 状态码和响应内容

当前端把 Network 面板的请求详情、请求头、请求体、响应内容完整贴过来时，后端第一件事是看状态码和响应 JSON 里的业务错误码。常见的状态码含义如下：

状态码能给出一个大方向，但还不能精确定位代码问题。真正的关键信息在服务端日志里。

4.2 靠完整日志还原接口调用链

很多团队的后端日志是“能跑就行”级别——只在 catch 块里打一行 error，没有请求路径、没有参数、没有耗时、没有 traceId。这种日志在排查问题时几乎帮不上忙。

推荐在每个接口的入口和出口都打印结构化日志。下面是一个通用的 Spring Boot 拦截器示例，能够记录每个请求的方法、路径、状态码和耗时：

// 文件路径：src/main/java/com/example/demo/config/LogInterceptor.java @Component public class LogInterceptor implements HandlerInterceptor { private static final Logger log = LoggerFactory.getLogger(LogInterceptor.class); @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { request.setAttribute("startTime", System.currentTimeMillis()); return true; } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { long start = (long) request.getAttribute("startTime"); long cost = System.currentTimeMillis() - start; log.info("[接口日志] method={} uri={} status={} cost={}ms", request.getMethod(), request.getRequestURI(), response.getStatus(), cost); if (ex != null) { log.error("[接口异常] uri={}", request.getRequestURI(), ex); } } }

有了这样的日志，排查一个“接口很慢”的问题就简单了：先看 cost 字段是几十毫秒还是几秒。如果几秒，再往下游查 SQL 耗时、第三方服务耗时、Redis 耗时。

4.3 从异常栈定位代码问题

当日志里出现异常栈时，定位就进入了“代码级”阶段。一个合格的异常栈应该包括：

• 异常类型和消息，比如 NullPointerException、SQLException；
• 具体报错的类名、方法名、行号；
• 调用的完整链路。

拿着异常栈信息去代码里比对，通常能快速找到问题代码。这里要提醒一句：不要只看异常消息就动手改代码，要把异常栈里的完整链路读一遍，确认是当前系统代码的问题，还是第三方依赖抛出的问题。

4.4 数据库问题的初步定位

相当一部分后端 BUG 的根因在数据库层，比如慢查询、锁等待、连接池耗尽。定位数据库问题，可以先用一条 SQL 确认慢查询日志的状态：

-- 在测试环境执行，确认慢查询日志是否开启 SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'long_query_time';

如果慢查询日志开着，就能看到哪些 SQL 执行时间过长，再针对性地做 explain 分析。注意：生产环境不要随意执行影响性能的诊断命令，优先通过监控平台查看。

4.5 后端 BUG 的典型特征汇总

• 接口返回 5xx，日志里有对应异常栈，通常是后端代码问题；
• 接口返回 4xx，日志显示参数校验失败，要先和前端核对传参格式；
• 接口能收到请求，但处理超时，优先检查数据库慢查询和第三方依赖；
• 日志里出现连接池超时、线程池拒绝等字样，属于后端资源问题。

5. 环境 BUG 的识别与定位方法

环境 BUG 是三类 BUG 中最容易让人心态崩溃的。它的代码看起来完全正常，但换个环境就不工作，或者时好时坏。识别环境 BUG 有几个典型信号：

• 换环境就好：本地正常、测试环境报错，或者测试环境正常、生产环境报错；
• 重启就好：服务重启后恢复正常，过一段时间又出问题；
• 偶发复现：同一个操作有时成功有时失败，没有稳定规律；
• 别人正常你不行：同样的代码，同事电脑上正常，你电脑上就报错。

5.1 环境 BUG 的高发来源

根据经验，环境类问题最常见的根因集中在以下几个方面：

配置差异。每个环境都有独立的配置文件或环境变量。数据库地址写错、Redis 密码不对、第三方服务的 AppKey 不同，都会导致服务在某个环境正常、在另一个环境异常。这类问题排查时，要把正常环境和异常环境的配置逐项对比。

依赖版本不一致。前端的 node_modules、后端的 Maven 依赖、Python 的虚拟环境，如果安装的包版本不一致，行为就可能不同。

网络与代理。公司内网和外网的网络策略不同，代理设置不同，DNS 解析结果不同，都会导致请求超时或连接被重置。

缓存。浏览器缓存、CDN 缓存、Redis 缓存，任何一个缓存没有失效，都会让你看到的页面或接口数据是“旧的”。

资源限制与系统时间。磁盘写满、内存不足、文件描述符耗尽，这类问题通常伴随系统级告警。系统时间不同步则会导致 HTTPS 证书校验失败、JWT 签名验证失败等异常。

5.2 环境排查三连：对比、复现、最小化

遇到疑似环境问题时，最高效的思路是三连操作：

第一步，对比。找到正常工作的环境，把代码版本、依赖版本、环境变量、配置项逐项对比。差异点往往就是线索。

第二步，复现。先在异常环境上复现，再尝试在正常环境上复现。能在异常环境稳定复现、在正常环境无法复现，基本就锁定环境因素了。

第三步，最小化。逐步排除无关因素。比如把请求用 curl 直接打到后端服务，跳过前端页面、跳过 Nginx，看接口是否正常。

下面是一组排查环境差异时常用的命令：

# 对比当前环境变量（在两个环境分别执行，然后 diff） env | sort # 检查 Node.js 与 npm 版本 node -v npm -v # 查看当前项目的顶层依赖（排除依赖版本差异） npm ls --depth=0 # 检查 Java 与 Maven 版本（以你本机实际安装为准） java -version mvn -v # 检查域名解析是否一致（在正常环境和异常环境分别执行） nslookup your-api.example.com

5.3 用 curl 绕过浏览器定位环境问题

很多时候，一个接口在页面上调用失败，但在服务器上直接用 curl 调用却是正常的。这时问题通常出在浏览器到服务器之间的网络链路上，比如代理、防火墙、证书。

下面是一个直接用 curl 请求后端接口的示例：

# 直接请求后端接口，绕过前端页面，判断问题是否在浏览器到服务器之间 curl -i -X GET 'http://localhost:8080/api/users' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer YOUR_TOKEN'

如果 curl 返回正常 JSON，说明后端服务本身没问题，问题可能出在前端页面代码或浏览器网络配置；如果 curl 也失败，就要继续往后端服务和系统层排查。

5.4 环境 BUG 的典型特征汇总

• 同一套代码不同环境行为不一致，优先对比配置和依赖；
• 问题在重启后消失，优先检查资源限制和缓存；
• 问题在特定时间段出现，优先看定时任务、日志切割、流量高峰；
• 报错涉及证书、签名、Token 时，优先检查系统时间和密钥配置。

6. 一条完整请求链的逐层排查流程

当问题同时涉及前端、后端、环境时，最容易乱。这时候需要一套固定的排查顺序，像漏斗一样一层层过滤。下面这条链路适用于绝大多数前后端分离项目：

用户操作 -> 前端事件绑定与状态变更 -> 前端构造请求 -> 浏览器发送请求 -> 代理/网关转发 -> 后端接口接收 -> 业务逻辑处理 -> 数据库/第三方服务调用 -> 后端返回响应 -> 前端解析响应 -> 页面渲染

排查时可以按照以下顺序逐层排除：

第一步：确定现象。把用户看到的现象记录下来：是白屏、报错、加载中、还是数据不对？现象越具体越好。

第二步：打开 Network 面板。看请求是否发出、状态码是什么、耗时多长。这一步能判断问题在前端发出请求之前，还是在请求发出之后。

第三步：看后端日志。找到对应请求的记录。如果没有记录，说明请求可能没到后端，问题在网关或网络；如果有记录，看状态码、耗时有异常栈。

第四步：看下游依赖。如果后端有异常栈，定位是代码问题、数据库问题还是第三方服务问题。

第五步：对比环境。如果代码和日志都正常，但问题只在某个环境出现，那就启动环境对比流程。

这个顺序的本质是：始终沿着请求的方向走，不要跳步。很多排查失败的情况，都是因为一开始就跳到了代码细节里，而忽略了更基础的请求链路。

下面是一个排查记录的示例格式，建议在实际工作中使用：

问题现象： 复现步骤： 出现环境：本地 / 测试 / 生产 Network 面板观察结果： 后端日志情况： 数据库/第三方服务状态： 最近变更了什么：

最后一项“最近变更了什么”非常重要。大多数环境类 BUG 都是变更引起的，包括发布新代码、改配置、升级依赖、调整网络策略。找到触发变更的时间点，往往能直接定位根因。

7. 经典案例复盘：那些“归属模糊”的 BUG

理论讲完，用几个真实高频的案例来看看“归属模糊”型 BUG 到底怎么判断。这类案例的共同点是：表面看像一个模块的锅，实际根因在另一个模块。

7.1 接口返回 500，后端日志却干干净净

现象：前端调用接口返回 500，但后端服务日志里找不到这条请求的任何记录。

归属判断：如果后端日志没有记录，说明请求可能根本没有到达后端服务。此时的 500 很可能是网关层返回的，而不是业务代码返回的。

排查方向：检查网关日志（Nginx、Kong、Spring Cloud Gateway 等），看路由配置是否正确、上游服务地址是否可达、网关是否有权限拦截。

处理方式：如果 Nginx 日志显示 upstream 连接超时，说明后端服务没有正常启动或负载均衡节点已下线；如果显示 404 后再返回 500，可能是路径重写规则写错了。

7.2 本地正常，测试环境一上传文件就报错

现象：文件上传功能在本地开发环境完全正常，到了测试环境就报错，错误信息类似“系统找不到指定的路径”或“权限不足”。

归属判断：代码没有改动，换环境才出问题，优先考虑环境差异。

排查方向：检查测试环境的上传临时目录是否存在、是否有写入权限、磁盘是否已满。

处理方式：为测试环境创建对应的临时目录并配置写权限，或者在应用配置中显式指定可用的上传路径。这类问题属于典型的环境配置问题，跟业务代码无关。

7.3 接口响应正常，页面却显示旧数据

现象：前端 Network 面板显示请求已发出、状态码 200、响应体里的数据是新的，但页面显示的还是旧数据。

归属判断：请求和响应都正常，问题在前端渲染环节。

排查方向：检查前端状态管理（Vuex/Pinia/Redux）中的数据是否被正确更新，组件是否监听了数据变化，或者页面是否走了本地缓存逻辑。

处理方式：优先查看组件中数据赋值的代码，确认是否在响应返回后更新了状态，以及是否存在多个数据源互相覆盖的问题。

7.4 白天正常，晚上突然大量接口超时

现象：白天系统一切正常，晚上某个时段开始接口大量超时，过一会儿又自动恢复。

归属判断：这类问题背后通常是定时任务、数据库备份、日志切割等周期性操作，和具体业务代码关系不大。

排查方向：查看超时时间段内是否有定时任务在跑，数据库是否有大事务或锁等待，磁盘 IO 是否被打满。

处理方式：调整定时任务执行时间，或优化大事务的执行逻辑。这类问题属于系统资源层面的环境问题，需要用监控数据来定位。

7.5 同一份代码，同事电脑正常，自己电脑报错

现象：代码是从同一个 Git 仓库拉下来的，同事运行正常，自己一启动就报错。

归属判断：几乎可以断定是本地环境差异。

排查方向：对比自己和同事的依赖版本、Node/Java/Python 版本、本地数据库版本、环境变量配置。

处理方式：统一使用项目里的依赖版本锁定文件（package-lock.json、pom.xml 等），用 nvm 或 sdkman 管理语言版本，必要时重建本地依赖目录。

8. 常见问题快速对照表

下面这张表汇总了开发中最常见的几类 BUG 归属判断场景，建议收藏备用：

9. 减少协作摩擦的工程化建议

定位 BUG 归属只是第一步，真正让团队协作顺畅的是工程化规范。以下几条建议可以显著减少“前端说后端、后端说前端”的无效沟通。

9.1 前后端约定统一响应结构

如果每个接口的返回格式都不一样，前端排查一个报错就要去翻接口文档确认字段含义，效率极低。推荐在项目初期就约定统一响应结构：

{ "code": 0, "message": "success", "data": {} }

约定规则：

• code为 0 表示成功，非 0 表示业务错误；
• message为人类可读的错误信息；
• data存放业务数据。

有了这个约定，前端拦截器可以统一判断code，后端也能通过code快速区分业务异常和系统异常。

9.2 用 traceId 打通前后端日志

当前端报一个接口错误、后端找不到对应日志时，最痛苦的就是“请求到底有没有到达后端”。解决办法是引入 traceId。

后端在接收请求时生成一个唯一 ID，放到响应头里返回给前端；前端在后续排查中带上这个 ID，后端用这个 ID 就能在日志里精确定位整条调用链。

# 在响应头中查看 traceId curl -i -X GET 'http://localhost:8080/api/users' | grep -i trace

具体落地方式：后端网关生成X-Request-Id，同时写入日志上下文（如 MDC），传给下游服务。前端在判障时只需要把 Network 面板里的X-Request-Id复制给后端，后端就能一键检索全部相关日志。

9.3 不贴“我这边没问题”，贴日志和证据

在跨端沟通中，一句“我这边没问题”是最没有说服力的回答。更专业的做法是附上证据：

• 前端贴出 Network 面板截图、请求体、响应体；
• 后端贴出对应 traceId 的日志、异常栈；
• 环境管理员贴出配置对比结果、监控面板截图。

把沟通从“互相质疑”变成“共同分析数据”，排查效率会大幅提升。

9.4 沉淀一份联调环境清单

每个项目都应该有一份文档，记录好以下内容：

• 各环境的服务地址和登录方式；
• 数据库、Redis、文件存储等中间件的地址；
• 容易出现环境差异的配置项；
• 历史踩坑记录。

这份文档的价值在于，当新人遇到环境类问题时，不用从零开始查，直接对照清单就能排除常见坑位。

10. 小结与下一步

区分前端 BUG、后端 BUG 和环境 BUG，本质上是建立一套“分层定界”的排障思维。拿到问题后，先不要急着打开代码，而是沿着“现象 -> 请求 -> 响应 -> 日志 -> 环境”的顺序逐层排查，用证据说话，而不是靠猜测甩锅。

这篇文章给出的核心方法论可以浓缩成三句话：

• 看 Network 面板，确认请求是否发出、响应是否正常，这一步能区分前端与后端的责任范围；
• 看后端日志，确认是否有异常栈、耗时多长，这一步能定位后端代码、数据库还是依赖服务的问题；
• 看不复现规律，确认是否依赖特定环境、特定时间、特定机器，这一步能揪出最容易让人崩溃的环境 BUG。

下一步建议你把文中提到的“排查记录模板”用起来，下次遇到 BUG 时按格式记录一次。你会发现，当你能完整描述现象和排查过程时，解决方案往往已经自己浮出水面了。

如果这篇文章对你有帮助，建议收藏备用。遇到诡异 BUG 的时候翻出来，按照排查顺序走一遍，你会少熬很多夜。