在R语言里写网络请求代码，最让人头疼的往往不是接口逻辑本身，而是那些突如其来的异常：连接超时、DNS解析失败、服务器返回500，任何一个都能让脚本当场停止执行。R的默认行为是遇到error就终止运行，也就是说，一个批量采集任务跑了两小时，可能在最后一个请求上崩掉，前面的进度全部作废。tryCatch是R语言官方提供的异常处理机制，它能把运行期错误拦截下来，转换成你可以控制的结果，这篇文章就来把它在网络请求场景下的用法讲透。
为什么网络请求必须做异常处理
先看R语言处理错误的方式。R把运行期的问题分成两类：warning和error。warning只是提醒，程序会继续往下跑；error则直接中断执行，控制权交还给顶层。对于本地数据分析，这个设计没什么问题，因为数据就在内存里，出错了修一下重跑就行。但网络请求完全不同，它的成败取决于你控制不了的外部因素。
网络环境的不可控性体现在多个层面：目标服务器可能宕机，DNS可能解析不到，防火墙可能拦截请求，接口可能限流返回429，甚至网线被碰松了都会导致连接失败。httr包这类HTTP客户端在遇到无法建立连接的情况时，会直接抛出error，比如常见的Could not resolve host或者timeout was reached。如果代码里没有捕获逻辑，一条这样的错误就足以让整个循环中断。
批量请求场景下问题会被放大。假设你要遍历一百个URL抓取数据，写到第37个时对方服务器临时不可用，没有异常处理的脚本会立即停止，后面63个请求一个都不会发出，已经抓到的数据如果还没落盘也会丢失。更麻烦的是定时任务，凌晨自动跑的脚本崩了可能要到第二天上班才发现，白白损失一整晚的数据。所以网络编程里异常处理不是可选项，而是保证程序健壮性的基础工程。
tryCatch的基本语法与工作机制
tryCatch的完整结构包含四个部分：expr是正常执行的代码块，warning参数接收警告处理函数，error参数接收错误处理函数，finally里的代码无论成败都会执行，适合做资源清理。它的运行逻辑是：expr正常跑完就返回其结果；跑的过程中如果产生了warning，就调用warning对应的函数；如果产生了error，则调用error对应的函数，并把错误对象作为参数传进去。
# tryCatch 基本结构
result <- tryCatch({
# 正常执行的代码
x <- 10 / 2
x
}, warning = function(w) {
# 捕获警告，返回警告信息
paste("捕获到警告:", conditionMessage(w))
}, error = function(e) {
# 捕获错误，返回错误信息
paste("捕获到错误:", conditionMessage(e))
}, finally = {
# 无论如何都会执行的清理代码
message("本次执行结束")
})
有几个细节值得注意。第一，warning和error的参数都是函数，函数体里return的值会成为整个tryCatch表达式的返回值，所以error handler里可以返回一个标记失败的对象，而不是只能打印信息。第二，conditionMessage函数用来提取错误的具体内容，比直接print错误对象更干净。第三，finally块拿不到任何参数，也不影响tryCatch的返回值，它只负责善后。
很多人会混淆tryCatch和try这两个函数。try是简化版，它只捕获error，捕获后返回一个try-error类的对象，你需要在后续代码里用inherits去判断是否失败。写法上try更省事，但结构化程度低，错误信息也不方便定制。另外还有一个常见误区：tryCatch默认只捕获error，warning如果不显式处理，程序会照常继续执行，只是打印一条警告。如果你希望把警告也当作异常拦下来，就必须显式写出warning参数。
实战：用tryCatch包装httr的GET请求
讲完语法，回到网络请求场景。httr包是R里最常用的HTTP客户端，GET函数发起请求后返回一个response对象。这里有个关键点需要分清：HTTP状态码是404或500时，httr默认不会抛error，请求本身是成功的，只是服务器告诉你资源有问题；只有连接层面失败（域名解析不了、超时、连接被拒绝）才会真正抛error。所以完整的异常处理要覆盖两层：连接层用tryCatch，状态码层用if判断。
library(httr)
# 安全的GET封装，统一返回结构化结果
safe_get <- function(url, timeout_sec = 10) {
tryCatch({
resp <- GET(url, timeout(timeout_sec))
code <- status_code(resp)
if (code >= 200 && code < 300) {
# 2xx 状态码视为成功
list(ok = TRUE, status = code,
data = content(resp, as = "parsed"))
} else {
# 4xx、5xx 状态码，请求成功但业务失败
list(ok = FALSE, status = code,
data = NULL, message = paste("HTTP状态码:", code))
}
}, error = function(e) {
# 连接层失败：超时、DNS错误、拒绝连接等
list(ok = FALSE, status = NULL,
data = NULL, message = conditionMessage(e))
})
}
# 调用示例
res <- safe_get("https://api.ipipp.com/users")
if (res$ok) {
print(res$data)
} else {
cat("请求失败，原因:", res$message, "\n")
}
这段代码的设计思路是把所有可能的失败统一收敛成一个list结构，用ok字段标记成败，用message字段携带原因。调用方只需要检查ok字段就能决定后续动作，不必区分失败到底发生在哪一层。timeout参数建议总是显式设置，httr默认没有超时限制，如果服务器一直不响应，脚本会无限期挂起，这比报错更难排查。
POST请求的处理方式完全一样，把GET换成POST并加上body参数即可。如果接口返回的是JSON，content(resp, as = "parsed")会自动解析成R的list；想拿原始文本可以用as参数设为text，方便自己控制解析逻辑或者排查格式问题。
进阶：自动重试与错误日志
网络错误有一个特点：大部分是瞬时的。服务器重启的几秒钟、网络抖动的一瞬间，都会造成请求失败，但过一会儿再试就恢复了。所以捕获错误之后，比直接放弃更好的策略往往是自动重试。配合指数退避（每次重试的等待时间递增），既能提高成功率，又不会在服务器故障时雪上加霜。
# 带重试机制的请求封装
fetch_with_retry <- function(url, max_retries = 3, base_wait = 2) {
for (attempt in seq_len(max_retries)) {
res <- safe_get(url)
if (res$ok) {
message("第", attempt, "次尝试成功")
return(res)
}
# 记录失败原因到日志文件
log_error(url, attempt, res$message)
# 未到最大次数则等待后重试，等待时间逐次翻倍
if (attempt < max_retries) {
wait <- base_wait * 2^(attempt - 1)
message("等待", wait, "秒后重试...")
Sys.sleep(wait)
}
}
# 全部重试失败，返回标记失败的空结果
list(ok = FALSE, status = NULL, data = NULL,
message = "重试次数已用尽")
}
# 简单的错误日志函数
log_error <- function(url, attempt, msg) {
line <- sprintf("[%s] 尝试第%d次失败 | %s | 原因: %s",
format(Sys.time()), attempt, url, msg)
cat(line, "\n", file = "request_error.log", append = TRUE)
}
重试次数不宜设得太大，3到5次通常足够，等待时间用2的幂次递增可以避免短时间内高频冲击目标服务器。日志部分建议至少记录时间戳、URL、失败原因三个要素，排查问题时这些信息能帮你快速定位是特定接口的问题还是整体网络的问题。如果项目规模较大，可以把日志函数换成futile.logger这类专业日志包，支持分级输出和滚动文件。
还有一种策略叫优雅降级：请求失败时不重试也不报错，而是返回一个合理的默认值，让主流程继续执行。比如读取远程配置文件失败时，退回本地的默认配置；获取实时汇率失败时，使用上一次缓存的值。这种思路特别适合对数据实时性要求不高的场景，能最大限度保证主任务不被外部依赖拖垮。
# 优雅降级示例：远程配置获取失败时使用默认配置
get_config <- function() {
res <- tryCatch({
resp <- GET("https://api.ipipp.com/config", timeout(5))
list(ok = TRUE, data = content(resp, as = "parsed"))
}, error = function(e) {
list(ok = FALSE, data = NULL)
})
if (res$ok) {
message("使用远程配置")
res$data
} else {
message("远程配置不可用，回退到默认配置")
list(theme = "light", page_size = 20, lang = "zh")
}
}
几个容易踩的坑
第一个坑是把状态码错误当成异常错误。前面反复强调过，404和500不会触发tryCatch的error分支，如果你只写了error处理而不检查status_code，程序会拿着一个失败的响应继续往下走，解析content时才暴露问题，排查起来反而更绕。正确做法是像safe_get那样两层都覆盖。
第二个坑是在error handler里又触发了新错误。比如handler里访问了错误对象上不存在的字段，或者调用了另一个会抛错的函数，这个新错误不会被同一个tryCatch捕获，程序照样会崩。handler里的代码应该尽量简单，只做信息提取和结果构造，不要塞复杂业务逻辑。
第三个坑和循环有关。在for循环里用tryCatch时，一定要确保每次迭代的返回值都被正确收集，否则一次失败可能悄悄把前面的结果覆盖掉。建议为每次迭代都构造独立的list元素，用results[[i]]这样的方式赋值，失败时也占一个位置并标记状态，这样事后能完整还原每一轮的执行情况。
掌握这些要点之后，R语言的网络请求代码就能从能跑变成跑得稳。核心思路其实就一句话：把所有可能失败的地方显式包起来，把失败转换成数据结构里的一部分，让主流程永远有路可走。