在实际操作中，处理教师招聘信息时可能会遇到异常情况（如信息格式错误、数据缺失、信息源不可用）。请说明如何设计异常处理机制，确保系统的稳定性和用户体验。

1) 【一句话结论】：设计异常处理机制需分层处理（捕获、重试、降级、日志），结合业务逻辑与系统架构，通过精准的异常分类、友好的用户提示、合理的重试策略及全面的日志记录，确保系统稳定与用户体验。

2) 【原理/概念讲解】：异常处理的核心是“预见并应对意外”，好比系统遇到“故障”时，需按预设规则处理。关键概念包括：

• 异常分类：按来源分技术异常（如网络故障）和业务异常（如数据格式错误）；按影响分致命异常（系统崩溃）和非致命异常（数据缺失）。
• 处理策略：分层处理（如先捕获技术异常，再处理业务异常），重试机制（对可恢复的异常尝试重试），降级处理（异常时切换到简化功能），用户提示（友好提示而非技术错误）。
• 类比：系统异常如同人生遇到挫折，需先尝试解决（重试），不行则调整（降级），并记录原因（日志），最后告知用户（提示），避免用户困惑。

3) 【对比与适用场景】：用表格对比不同异常处理策略

策略	定义	特性	使用场景	注意点
异常捕获（try-catch）	捕获运行时异常，执行特定逻辑	精确控制异常流程	所有需要处理异常的代码段	需明确异常类型，避免捕获所有异常导致隐藏问题
重试机制	对可恢复异常（如网络）多次尝试	自动化恢复流程	网络请求、数据库连接等	设定重试次数与间隔，避免资源耗尽
降级处理	异常时切换到简化功能（如无图片显示文字描述）	保持核心功能可用	系统部分模块异常时	降级功能需保证业务核心需求
日志记录	记录异常信息（时间、类型、上下文）	分析问题根源	所有异常处理环节	日志需包含关键参数，便于排查

4) 【示例】（伪代码）：

def fetch_teacher_info(info_source):
    max_retries = 3
    retry_delay = 1  # 秒
    for attempt in range(max_retries):
        try:
            data = get_data_from_source(info_source)
            if not validate_data(data):
                raise ValueError("数据格式错误")
            return process_data(data)
        except ConnectionError:
            if attempt == max_retries - 1:
                log_error("网络不可用，最终重试失败", source=info_source)
                return {"error": "信息源不可用，请稍后重试"}
            time.sleep(retry_delay)
        except ValueError as e:
            log_error(f"数据验证失败: {e}", source=info_source)
            return {"error": f"信息格式错误，请检查数据后重试"}
        except Exception as e:
            log_error(f"未知异常: {e}", source=info_source)
            return {"error": "处理信息时出现未知错误"}
    return {"error": "系统处理信息时出现未知错误"}

5) 【面试口播版答案】：（约90秒）
“面试官您好，针对教师招聘信息处理中的异常情况，我设计的异常处理机制核心是分层、精准、用户友好。首先，我会对异常进行分类：比如网络不可用属于技术异常，数据缺失是业务异常，格式错误是数据异常。然后，针对不同异常采取不同策略：对于网络异常，设置3次重试，每次间隔1秒，避免频繁请求；对于数据格式错误，捕获后提示用户修正数据；对于数据缺失，提示用户补充信息。同时，所有异常都会记录详细日志，包括异常类型、时间、信息源，方便排查问题。最后，给用户友好的提示，比如‘信息源暂时不可用，请稍后重试’，而不是技术错误代码。这样既能保证系统稳定，又能提升用户体验。总结来说，通过异常分类、重试、降级和日志记录，确保系统在遇到异常时能自动恢复或友好提示，维护稳定性和用户体验。”

6) 【追问清单】：

• 追问1：如何区分业务异常和技术异常？
  回答要点：业务异常是因数据逻辑错误（如格式错误），技术异常是系统资源或网络问题（如连接失败），通过异常类型和上下文判断，业务异常需用户操作，技术异常需系统修复。
• 追问2：重试机制中，重试次数和间隔如何确定？
  回答要点：根据经验或测试数据，比如网络请求通常重试3次，间隔1-2秒，避免资源耗尽；对于关键数据，可增加重试次数，但需平衡系统负载。
• 追问3：降级处理的具体场景是什么？
  回答要点：当信息源不可用时，降级为显示历史数据或提示用户手动输入；当数据格式错误时，降级为显示部分有效数据并提示修正。
• 追问4：如何保证日志的详细程度？
  回答要点：日志需包含异常类型、时间戳、信息源、关键参数（如数据字段），以及处理步骤，便于后续分析问题根源。
• 追问5：用户反馈的收集如何与异常处理结合？
  回答要点：通过用户提示中的反馈按钮，收集异常时的用户操作，结合日志分析，优化异常处理策略。

7) 【常见坑/雷区】：

• 坑1：捕获所有异常导致隐藏问题。
  雷区：使用try-except Exception捕获所有异常，导致系统无法识别具体错误，排查困难。
• 坑2：重试无限次导致资源耗尽。
  雷区：未设置重试次数和间隔，持续请求导致服务器或网络资源耗尽，影响系统稳定性。
• 坑3：异常提示不友好。
  雷区：直接输出技术错误代码（如500），用户无法理解，降低用户体验。
• 坑4：未区分异常类型导致错误处理逻辑混乱。
  雷区：所有异常统一处理，无法针对不同异常采取最优策略，比如网络异常和格式错误用相同逻辑，效果不佳。
• 坑5：日志记录不详细。
  雷区：仅记录异常类型，未包含关键参数，导致无法定位具体问题，影响问题排查效率。