在移动端网络请求中，如何处理网络请求失败（如超时、服务器错误）或数据解析错误？请设计错误处理机制，包括用户反馈、重试策略及日志记录？
答案
1) 【一句话结论】移动端网络请求失败需构建分层错误处理机制，从网络层捕获异常、业务层分类处理、UI层提供友好反馈，结合指数退避重试策略与结构化日志记录，平衡用户体验与系统稳定性。
2) 【原理/概念讲解】老师口吻，解释关键概念：
网络请求失败分三类：网络错误（超时、连接失败，由网络环境导致）、服务器错误（400/404/500，由后端逻辑或数据问题导致）、数据解析错误（JSON解析失败，由数据格式问题导致）。
处理层级：网络层拦截超时/连接失败，触发重试或提示网络问题；业务层处理服务器错误/解析错误，判断是否可重试；UI层根据错误类型展示不同反馈（如网络错误提示“检查网络”，服务器错误提示“请求失败，稍后重试”）。
重试策略：指数退避（首次重试间隔1秒，第二次2秒，依次翻倍），避免频繁请求压垮服务器。
日志记录：结构化日志（包含请求URL、方法、参数、错误类型、时间戳、设备信息等），便于排查问题。
3) 【对比与适用场景】
| 错误类型 | 定义 | 处理方式 | 适用场景 |
|---|---|---|---|
| 网络错误 | 超时、连接失败、无网络 | 立即提示用户检查网络，不重试 | 用户处于弱网环境 |
| 服务器错误 | 400/500等 | 业务层判断是否可重试（如500可重试，400不可），指数退避 | 后端服务暂时不可用 |
4) 【示例】
伪代码展示请求封装与错误处理：
function fetchData(url, params, maxRetries=3) {
let retryCount = 0;
while (retryCount <= maxRetries) {
try {
const response = request(url, params);
if (response.ok) {
return parseData(response);
} else {
handleBusinessError(response);
if (isRetryable(response.status)) {
retryCount++;
continue;
}
}
} catch (e) {
handleNetworkError(e);
if (isNetworkRecoverable()) {
retryCount++;
continue;
}
}
retryCount++;
}
throw new Error("Max retries exceeded");
}
function handleNetworkError(error) {
showNetworkError(); // UI层：提示“网络连接失败，请检查网络”
logError("NETWORK_ERROR", error.message, new Date()); // 日志：记录网络错误
}
function handleBusinessError(response) {
showBusinessError(response.status); // UI层：根据状态码提示
logError("SERVER_ERROR", response.status, new Date()); // 日志：记录业务错误
}
function logError(type, message, timestamp) {
const log = {
type: type,
message: message,
timestamp: timestamp,
url: url,
method: "GET",
params: params,
device: "iOS"
};
sendLogToServer(log); // 发送到日志服务
}
5) 【面试口播版答案】（约90秒）
“面试官您好，针对移动端网络请求失败的处理，我会设计一个分层且智能的机制。首先，核心思路是分层处理：网络层捕获超时、连接失败等网络错误，业务层处理服务器错误（如400、500）和数据解析错误，UI层给用户友好反馈。然后，用户反馈方面，网络错误直接提示‘检查网络’，服务器错误提示‘请求失败，稍后重试’，避免用户困惑。接着，重试策略采用指数退避，比如第一次超时后等待1秒重试，第二次2秒，这样既保证重试，又避免频繁请求压垮服务器。最后，日志记录是关键，结构化记录请求URL、错误类型、时间、设备等信息，方便后续排查问题。整体来看，这个机制能平衡用户体验和系统稳定性，确保即使遇到错误，用户也能得到及时反馈，同时系统也能通过重试和日志持续优化。”
6) 【追问清单】
- 问：重试策略中，如何判断一个错误是否可重试？
答：比如500 Internal Server Error通常可重试，400 Bad Request不可重试（因可能是用户输入错误或参数问题）。 - 问：不同错误类型的重试次数是否不同？
答：可设置不同错误类型的最大重试次数，比如网络错误重试3次，服务器错误重试5次，避免资源浪费。 - 问：日志记录中，除了基本字段，还需要记录什么？
答：比如请求上下文（用户ID、请求ID）、设备信息（iOS版本、型号）、网络环境（Wi-Fi/蜂窝网络）等，更全面定位问题。 - 问：UI反馈的时机如何控制？
答：网络错误发生时立即反馈，服务器错误在重试失败后反馈，避免频繁打扰用户。 - 问：如何处理取消网络请求的情况？
答：使用iOS的URLSessionTask.cancel()方法，在用户离开页面或长时间无响应时取消请求，避免资源占用。
7) 【常见坑/雷区】
- 坑1：只处理业务错误，忽略网络错误，导致用户无法使用功能。
- 坑2：重试无限次，导致服务器压力过大，甚至被拉黑。
- 坑3：日志不结构化，难以分析错误原因，排查问题效率低。
- 坑4：UI反馈不友好，直接显示错误码，用户无法理解。
- 坑5：未区分不同错误类型的重试策略，比如所有错误都用相同策略，导致效果不佳。