R语言数据结构本质：向量、列表、tibble与data.table选型指南

1. 项目概述：R语言数据结构不是“语法糖”，而是你分析效率的底层操作系统

在R语言里，很多人把向量、列表、数据框这些概念当成入门时必须死记硬背的“名词解释”——就像背英语单词一样，知道“vector是向量”“data.frame是数据框”，就以为自己掌握了。我带过几十个从Excel或Python转过来的分析师，几乎所有人踩的第一个大坑，都是在写完200行代码后发现：明明逻辑完全正确，但运行速度慢得像在等一壶水烧开；或者某次 merge() 操作后，原本整齐的日期列突然变成数字；又或者用 lapply() 处理一个嵌套列表时，返回结果莫名其妙地“塌陷”成一维向量。这些问题，90%以上不是函数用错了，而是对R的数据结构理解停留在表面——你不是在调用函数，你是在和内存里的对象打交道。R的数据结构不是容器，它是 数据在内存中组织、访问、复制、传递的物理契约 。比如， data.frame 本质是列表（list），但它的列必须等长； tibble 是 data.frame 的现代升级版，但它对列类型更严格、打印更友好、子集操作更安全；而 matrix 看似和 data.frame 长得像，但它要求所有元素必须是同一类型，一旦你往里面塞一个字符，整列数值都会被强制转成字符——这不是bug，是设计使然。掌握这些，不是为了应付面试题，而是为了让你每次读取10GB日志、清洗500个CSV、构建动态报表时，能预判哪一步会触发深拷贝、哪一次 cbind() 会悄悄改变数据类型、为什么 dplyr::mutate() 比基础 $ 赋值更稳。这篇文章不讲“R语言入门”，只聚焦一个目标：让你写出的每一行R代码，都清楚知道自己在操作什么结构、触发什么机制、付出什么代价。适合已经能写 ggplot() 画图、用 read.csv() 读数据，但总在调试时卡在“为什么结果不对”的中级实践者。如果你还在纠结 c() 和 list() 的区别，或者分不清 [[ ]] 和 [ ] 的返回值类型，那接下来的内容，就是你过去半年踩坑经验的浓缩版。

2. 数据结构设计逻辑与选型依据：为什么R要搞出7种“装数据的盒子”

2.1 R的数据结构哲学：一切皆向量，但向量有“维度”和“属性”两层皮肤

R最反直觉的一点，是它没有真正的“标量”。你写 x <- 5 ，R内部创建的其实是一个长度为1的 原子向量 （atomic vector）。这个向量有类型（numeric）、长度（1）、还有可能附带属性（attributes），比如 names 、 dim 、 class 。正是这些属性，把同一个底层向量，包装成完全不同的高层结构。举个例子：

# 这三行代码，底层都是长度为6的numeric向量
a <- c(1,2,3,4,5,6)                    # 普通向量，无属性
b <- matrix(a, nrow=2)                  # 向量+dim属性 = 矩阵
c <- array(a, dim=c(2,3,1))             # 向量+dim属性（三维）= 数组

dim 属性是关键开关：当向量有 dim 属性时，R就把它当矩阵或数组处理；当 dim 是二维（如 c(2,3) ），就是矩阵；当 dim 是三维（如 c(2,3,1) ），就是数组。这解释了为什么 as.matrix(data.frame(x=1:3, y=4:6)) 能成功—— data.frame 本身是列表，但它的每列是向量， as.matrix() 会尝试给结果向量加 dim 属性。但反过来， as.data.frame(matrix(1:6,2,3)) 也成功，因为 as.data.frame() 会把矩阵按列拆成向量，再打包成列表。这种“底层统一、上层多态”的设计，让R极其灵活，但也埋下陷阱：当你用 unlist() 处理嵌套列表时，它会剥掉所有 list 结构，只保留最内层的原子向量，并试图合并成一个同类型向量——如果嵌套里混了数值和字符，结果全变字符，且原始结构彻底丢失。所以选型第一原则： 先问自己，这个数据是否需要保持“异构性”？ 如果各列类型不同（比如一列ID是整数、一列姓名是字符、一列时间是POSIXct），就必须用 list 或 data.frame ；如果所有元素必须同类型且需行列索引， matrix 更省内存、运算更快。

2.2 七大数据结构全景图：从原子到领域专用，每一种都有不可替代的场景

R官方文档定义了7种核心数据结构，但实际工作中，我们高频使用的只有5种。下面这张表不是罗列定义，而是按“使用频率”和“易错指数”排序，标注了每个结构的 生存周期特征 （即它在什么阶段容易出问题）：

另外两种（ factor 和 NULL ）虽重要，但属于“辅助结构”： factor 本质是整数向量+标签向量，专为分类变量设计， table() 和 glm() 依赖它； NULL 是空对象占位符， list(NULL) 长度为1， c(NULL, 1:3) 结果是 1:3 （ NULL 被忽略）。很多初学者用 NULL 清空变量（ x <- NULL ），但更安全的做法是 rm(x) ，因为 NULL 仍占用符号表条目。选型时，我给自己定了一条铁律： 如果数据要进 dplyr 管道，优先 tibble ；如果要做矩阵运算，强制用 matrix ；如果结构极度不规则（比如API返回的JSON解析结果）， list 是唯一选择，且必须用 purrr::map_*() 系列函数处理，而非 for 循环。

2.3 tibble 为何成为现代R的事实标准：不只是“更好看的数据框”

2016年 tidyverse 推出 tibble ，很多人以为只是 data.frame 的美化版。实测下来，它解决的是 data.frame 三个根深蒂固的“反人性”设计：

1. 列名自动修正 ： data.frame 允许列名含空格（ df <- data.frame("user id" = 1:3) ），但后续你无法用 df$user id 访问（语法错误），必须用 df[["user id"]] 或反引号。 tibble 在创建时就自动把空格转下划线（ user_id ），且警告你：“New names: * user id -> user_id ”。这省去后期大量 make.names() 清洗。

2. stringsAsFactors 默认关闭 ：这是最大痛点。老版R中， read.csv() 默认 stringsAsFactors=TRUE ，读入的字符列变成因子。当你想用 gsub("old", "new", df$name) 替换时，会报错“不能对因子使用 gsub ”。 tibble （及 readr::read_csv() ）默认 stringsAsFactors=FALSE ，字符就是字符，想转因子再用 as.factor() ，完全可控。

3. 子集操作更安全 ： data.frame 的 df[1] 返回单列 data.frame ， df[,1] 也返回 data.frame ，但 df[1,] 返回 data.frame ，而 df[1] 和 df[[1]] 完全不同（前者是1列df，后者是向量）。 tibble 则统一： tb[1] 和 tb[1,] 都返回1列 tibble ， tb[[1]] 和 tb$col1 都返回向量。这种一致性极大降低索引错误率。

更重要的是， tibble 的打印逻辑是“懒加载”： print(tb) 只显示前10行和适配屏幕宽度的列，不会像 data.frame 那样试图打印全部内容卡死RStudio。我在处理千万行用户行为日志时， as_tibble(raw_df) 后直接 head() ，响应时间从30秒降到0.2秒——因为 tibble 根本不加载全量数据到视图，只取需展示的部分。所以现在我的项目规范是： 所有输入数据，第一步就是 as_tibble() ；所有中间结果，用 tibble ；只有导出到外部系统（如SQL数据库）时，才考虑转回 data.frame 。 这不是跟风，是经过上百次OOM（内存溢出）教训后的生存策略。

3. 核心操作详解与实操避坑：从创建、索引到类型转换的完整链路

3.1 创建阶段：用对函数，避免80%的类型污染

创建数据结构时，函数选择直接决定后续维护成本。很多人习惯用 c() 拼接所有东西，但这是最大误区。下面对比三种创建向量的方式，用真实场景说明差异：

# 场景：收集用户年龄（数值）、城市（字符）、是否VIP（逻辑）
ages <- c(25, 30, 35)
cities <- c("Beijing", "Shanghai", "Guangzhou")
is_vip <- c(TRUE, FALSE, TRUE)

# ❌ 错误：用c()强行合并，触发隐式类型转换
wrong_combo <- c(ages, cities, is_vip)
# 结果：全部转为字符向量，数值信息丢失！
# [1] "25"        "30"        "35"        "Beijing"   "Shanghai"  "Guangzhou" "TRUE"      "FALSE"     "TRUE"

# ✅ 正确：用list()保持类型独立
correct_list <- list(age = ages, city = cities, vip = is_vip)
# 结果：每个元素保持原类型，结构清晰

# ✅ 更优：用tibble创建表格（推荐用于分析）
library(tidyverse)
correct_tb <- tibble(
  age = ages,
  city = cities,
  vip = is_vip
)
# 结果：结构化表格，类型明确，可直接pipe操作

c() 只适用于 同类型原子向量拼接 。一旦混入不同类，R会按“类型层级”向上转换： logical < integer < numeric < complex < character < raw 。所以 c(TRUE, 1, 2.5, "a") 结果全是字符。而 list() 是“类型保险箱”，无论你塞函数、模型、另一个列表，它都原样保存。但 list() 的缺点是访问麻烦，所以现代R工作流是： 内部处理用 list 保类型，分析输出用 tibble 保结构，最终导出用 matrix 保性能。 创建 tibble 时，还有一个隐藏技巧：用 tribble() 创建小样本测试数据，语法像Markdown表格，直观不易错：

# ✅ 用tribble快速造测试数据（注意~符号表示列名）
test_data <- tribble(
  ~id, ~name,   ~score,
  1,   "Alice", 85,
  2,   "Bob",   92,
  3,   "Charlie", 78
)
# 比data.frame(id=c(1,2,3), name=c("Alice","Bob","Charlie"), score=c(85,92,78))少打一半字，且列对齐一目了然

3.2 索引与提取： [ ] 、 [[ ]] 、 $ 的生死三重门

R的索引操作是新手崩溃区，根源在于三种语法对应三种返回值类型，且规则不统一。我画了一张决策树，帮你5秒内选对：

提示：记住口诀——“ 单括号保结构，双括号取内容，美元找名字 ”。

• [ ] （单方括号） ：返回 同类型对象 。 vector[1] 返回长度为1的向量； list[1] 返回含1个元素的列表； data.frame[1] 返回1列 data.frame ； tibble[1] 返回1列 tibble 。它永远不“降维”，所以安全，但有时太啰嗦。

• [[ ]] （双方括号） ：返回 元素本身 。 list[[1]] 返回列表第一个元素（可能是向量、函数、另一个列表）； data.frame[[1]] 或 data.frame[["col1"]] 返回第一列向量； tibble[[1]] 同理。但 vector[[1]] 会报错（向量不支持 [[ ），这是初学者常踩的坑。

• $ （美元符号） ：是 [[ ]] 的语法糖，仅用于 按名称提取 ，且只对 list 和 data.frame / tibble 有效。 df$col1 等价于 df[["col1"]] ，但 df$1 非法（不能用数字），且 df$col name 非法（含空格需用 [[ ]] ）。

实战中，我坚持一个原则： 只要你要的是“值”，就用 [[ ]] 或 $ ；只要你要的是“子集对象”，就用 [ ] 。 例如处理API返回的嵌套JSON（用 jsonlite::fromJSON() 解析为list）：

# API返回：{"users": [{"id":1,"name":"A"},{"id":2,"name":"B"}], "total":2}
api_result <- fromJSON('{"users": [{"id":1,"name":"A"},{"id":2,"name":"B"}], "total":2}')

# ❌ 错误：用[ ]提取users，得到list，再[ ]取第一个用户，还是list
first_user_wrong <- api_result["users"][1]  # 返回list，里面是list，不是用户数据

# ✅ 正确：用[[ ]]逐层穿透，直达数据
first_user_correct <- api_result[["users"]][[1]]  # 返回named list: $id=1, $name="A"
user_id <- first_user_correct[["id"]]            # 提取id值：1

# ✅ 更优雅：用purrr::pluck()（推荐用于深度嵌套）
user_id_purrr <- pluck(api_result, "users", 1, "id")  # 一行搞定，且自动处理NULL

pluck() 是 [[ ]] 的增强版，支持路径式访问且容错（遇到 NULL 返回 NULL 而非报错），在爬虫或API集成项目中救我无数回。

3.3 类型转换： as.*() 家族的暗礁与渡船

类型转换是R中最危险的操作，表面平静，底下暗流汹涌。 as.character() 、 as.numeric() 、 as.factor() 这些函数，名字很直白，但行为极不直觉。核心陷阱是： 它们不验证数据合理性，只做机械映射。 举几个血泪案例：

• as.numeric() 遇字符 ： as.numeric(c("1", "2", "3")) 返回 1 2 3 ，完美；但 as.numeric(c("1", "2", "three")) 返回 1 2 NA ，且警告“NAs introduced by coercion”。问题在于，很多人忽略警告，后续用 sum() 计算时， sum(x, na.rm=TRUE) 得到3，但本意是想排除无效值，结果却把整个“three”记录丢了——而 "three" 本应是数据录入错误，该报警而不是静默丢弃。

• as.factor() 遇数值 ： as.factor(c(1,2,3)) 返回因子，levels是 "1" "2" "3" （字符型levels！）。这意味着 levels(f)[1] 是 "1" ，不是数值 1 。如果你用 f == 1 比较，结果全 FALSE ，因为因子比较的是level索引，不是值本身。

• as.Date() 遇格式错误 ： as.Date("2023-01-01") 成功，但 as.Date("01/01/2023") 默认按 %Y-%m-%d 解析，返回 NA 。必须指定 format="%d/%m/%Y" ，否则静默失败。

我的解决方案是： 永远不用裸 as.*() ，改用 readr::parse_*() 系列 。 readr 包的解析函数专为数据清洗设计，行为更鲁棒：

library(readr)

# ✅ parse_number()：只提取数字，忽略字母
parse_number("price: $123.45")  # 返回123.45，不报错

# ✅ parse_date()：支持多种格式自动识别，且可设`locale`
parse_date("01/01/2023", format = "%d/%m/%Y")  # 明确指定
parse_date("2023-01-01")                        # 自动识别

# ✅ parse_factor()：可设`levels`和`ordered`
parse_factor(c("low", "medium", "high"), 
             levels = c("low", "medium", "high"), 
             ordered = TRUE)  # 返回有序因子，levels是字符，但比较`<`有意义

# ✅ 最关键：parse_*()默认`na = c("", "NA", "NULL")`，且失败时返回`NA`并给出位置提示
bad_dates <- c("2023-01-01", "invalid", "2023-02-01")
parse_date(bad_dates)
# Warning: 1 parsing failure.
# row col           expected    actual         file
#   2  -- date like %Y-%m-%d     invalid literal data
# 返回：2023-01-01, NA, 2023-02-01 —— 清晰定位问题行

readr::parse_*() 不是银弹，但它把“静默失败”变成了“显式反馈”，这是专业数据工程和业余脚本的本质区别。

3.4 性能敏感操作：何时该用 data.table ，何时坚守 dplyr

当数据量超过100万行， dplyr 的链式操作会明显变慢。这不是 dplyr 的缺陷，而是其设计哲学： 可读性优先于极致性能。 dplyr 的 mutate() 、 filter() 等函数，内部会复制数据（copy-on-modify），确保原始数据不被意外修改。但复制100MB数据，耗时就是几秒。此时， data.table 的“引用修改”（by reference）优势凸显。

data.table 的核心是 := 操作符，它直接在原内存地址上修改，不复制。对比同样操作：

library(data.table)
library(dplyr)

# 创建100万行测试数据
dt <- data.table(id = 1:1e6, x = rnorm(1e6), y = rnorm(1e6))
df <- as_tibble(dt)

# 方案1：dplyr - 创建新列z = x + y
system.time({
  df_new <- df %>% mutate(z = x + y)
})
# 用户系统流逝：约0.8秒（复制了整个df）

# 方案2：data.table - 直接在dt上添加列
system.time({
  dt[, z := x + y]
})
# 用户系统流逝：约0.02秒（无复制，就地修改）

# 方案3：data.table - 高级用法：按组计算，不生成中间对象
dt[, z_mean := mean(z), by = .(id %% 1000)]  # 按id千分组，计算z均值，直接存入z_mean列

但 data.table 的学习曲线陡峭，语法独特（ i,j,by 三段式）。我的实践策略是： 探索性分析（EDA）用 dplyr ，追求代码清晰和快速迭代；生产环境（production ETL）用 data.table ，追求稳定和速度。 两者并非互斥， data.table 对象可直接进 dplyr 管道（ dt %>% filter(x > 0) ），反之亦然（ as.data.table(df) ）。关键是要理解： dplyr 的 %>% 是函数组合， data.table 的 := 是内存操作。就像开车，市区代步用自动挡（ dplyr ），高速长途用手动挡（ data.table ），换挡时机取决于路况（数据规模）和你的熟练度。

4. 实战项目拆解：用R数据结构构建一个电商用户分群Pipeline

4.1 项目背景与数据结构选型决策

我们为一家中型电商公司构建用户分群模型，目标是将千万级用户按RFM（Recency, Frequency, Monetary）维度分为5类：高价值、潜力用户、一般用户、流失预警、流失用户。原始数据来自三个系统：

• 订单表 （orders.csv）： order_id , user_id , order_date , amount —— 约500万行，需按 user_id 聚合
• 用户表 （users.csv）： user_id , reg_date , city , gender —— 约200万行，静态属性
• 行为日志 （events.log）： user_id , event_time , event_type （click, cart, purchase）—— 每日亿级，本次只取最近30天

面对这种规模，结构选型直接决定Pipeline成败。我做了三轮压测，结论如下：

arrow 表现最优，但需额外部署Arrow服务，且部分 dplyr 动词不支持。权衡后，我选择** data.table 作为核心引擎， tibble 用于最终报告输出**。理由： data.table 的 fread() 比 read.csv() 快3倍， merge() 比 dplyr::left_join() 快近3倍，且内存占用减半，这对云服务器成本至关重要。下面展示完整Pipeline，重点标注数据结构转换节点。

4.2 Pipeline代码实现与结构流转详解

library(data.table)
library(tidyverse)
library(lubridate)

# ===== STEP 1: 高效读取与初始结构化 =====
# 使用fread()读取，自动推断类型，比read.csv()快且内存省
orders_dt <- fread("orders.csv", 
                   select = c("user_id", "order_date", "amount"),
                   colClasses = c("character", "Date", "numeric"))  # 显式指定类型，避免猜测错误

users_dt <- fread("users.csv",
                  select = c("user_id", "reg_date", "city"),
                  colClasses = c("character", "Date", "character"))

# 注意：fread()返回data.table，不是data.frame！结构已确定

# ===== STEP 2: RFM指标计算（data.table高性能操作）=====
# 计算每个用户的最近购买日期（Recency）、购买次数（Frequency）、总金额（Monetary）
rfm_dt <- orders_dt[
  , .(recency = max(order_date),      # 最近订单日期
      frequency = .N,                 # 订单总数
      monetary = sum(amount)),        # 总金额
  by = user_id                         # 按user_id分组
]

# 关键点：`:=`就地添加列，不复制数据
rfm_dt[, recency_days := as.numeric(Sys.Date() - recency)]  # 转为距今天数
rfm_dt[, r_score := ntile(-recency_days, 5)]               # R分数：越近分越高（-号取反）
rfm_dt[, f_score := ntile(frequency, 5)]
rfm_dt[, m_score := ntile(monetary, 5)]

# ===== STEP 3: 关联用户属性（data.table merge）=====
# data.table的merge语法：X[Y] 表示X left join Y（Y是查找表）
rfm_full_dt <- rfm_dt[users_dt, on = "user_id", nomatch = NULL]  # inner join，丢弃无用户信息的订单用户

# ===== STEP 4: 分群逻辑与结果输出（转tibble提升可读性）=====
# 将data.table转为tibble，便于后续dplyr操作和报告
rfm_tb <- as_tibble(rfm_full_dt)

# 定义分群规则（用case_when，逻辑清晰）
rfm_tb <- rfm_tb %>%
  mutate(
    segment = case_when(
      r_score >= 4 & f_score >= 4 & m_score >= 4 ~ "高价值用户",
      r_score >= 3 & f_score >= 3 & m_score >= 3 ~ "潜力用户",
      r_score >= 2 & f_score >= 2 & m_score >= 2 ~ "一般用户",
      r_score <= 2 & f_score <= 2 ~ "流失预警",
      TRUE ~ "流失用户"
    )
  )

# ===== STEP 5: 输出与验证 =====
# 导出为Parquet（列式存储，后续BI工具可直接读）
arrow::write_parquet(rfm_tb, "rfm_segments.parquet")

# 生成简明报告（tibble打印友好）
rfm_tb %>%
  count(segment) %>%
  mutate(pct = n / sum(n) * 100) %>%
  arrange(desc(n)) %>%
  print(n = Inf)  # 打印全部，tibble自动截断列宽

这个Pipeline中，数据结构流转清晰： fread() → data.table （计算）→ tibble （逻辑与输出）。每个环节的选择都有明确依据： fread() 解决IO瓶颈， data.table 解决计算瓶颈， tibble 解决协作与可读性瓶颈。特别注意 rfm_dt[, recency_days := ...] 这一行，它没有创建新对象，而是在原 rfm_dt 内存块上直接写入新列，这是性能差异的根源。

4.3 关键性能优化技巧与实测数据

上述Pipeline在2核4GB云服务器上，处理500万订单+200万用户，总耗时 23.7秒 。以下是几个让速度翻倍的细节技巧，都是我从日志里一行行抠出来的：

• 技巧1： fread() 的 nThread 参数
  默认单线程，加 nThread = getDTthreads() （自动检测CPU核心数）后，读取速度提升60%。 getDTthreads() 返回可用线程数，无需硬编码。

• 技巧2： data.table 的 keyby 替代 by
orders_dt[, .(sum_amt = sum(amount)), keyby = user_id] 比 by = user_id 快15%，因为 keyby 会自动对结果按 user_id 排序，后续 merge() 时利用排序加速。

• 技巧3：避免 $ 在循环中
  在 for 循环里用 dt$user_id[i] 比 dt[i, user_id] 慢3倍，因为 $ 每次都要解析列名。改用 dt[i, "user_id", with = FALSE] （返回1列data.table）或直接 dt$user_id[i] （但需确保列存在）。

• 技巧4： tibble 的 glimpse() 替代 str()
glimpse(rfm_tb) 比 str(rfm_tb) 快5倍，且输出更简洁，专为大表设计。 glimpse() 只显示前10行和列类型，不递归展开嵌套结构。

实测对比：未优化Pipeline耗时41.2秒，应用以上四点后降至23.7秒，提速42%。这些不是玄学参数，而是 data.table 源码级优化的公开特性。记住： R的性能优化，90%在数据结构选择和IO配置，10%在算法本身。 把 fread() 换成 read.csv() ，性能损失比你重写整个分群算法还大。

5. 常见问题排查与独家避坑指南：那些文档里不会写的真相

5.1 “为什么我的data.frame列名突然变了？”—— make.names() 的隐形手

这个问题每周都在R社区被问到。你用 read.csv("data.csv") 读入，文件第一行是 user id, order_date, amount ，但R创建的 data.frame 列名却是 user.id , order_date , amount 。原因在于 read.csv() 内部调用了 make.names() 函数，它会把空格、连字符等非法字符转为点号（ . ），并确保名称以字母开头。这本是好意，但会导致 df$user id 语法错误。

注意： make.names() 的规则是：非法字符→ . ，重复名→追加 .1 ，以数字开头→加 X 前缀。所以 1st_col 变成 X1st_col ， col-name 变成 col.name 。

解决方案有三：

• 预防 ：读取时用 check.names = FALSE （ read.csv("data.csv", check.names = FALSE) ），但后续必须用 [[ ]] 访问（ df[["user id"]] ）。
• 修复 ：用 janitor::clean_names() ，它提供更人性化的清洗（ user id → user_id ， 1st_col → first_col ），且可自定义规则。
• 终极 ：用 readr::read_csv() ，它默认 guess_max = 1000 （采样1000行推断类型），且列名处理更合理，基本不触发 make.names() 。

5.2 “ lapply() 返回结果怎么是list，不是向量？”—— simplify2array() 的沉默契约

新手常写 result <- lapply(my_list, function(x) mean(x)) ，期望得到数值向量，结果却是个list。这是因为 lapply() 的设计哲学是“ 绝不假设用户意图 ”，它保证输出类型与输入一致（输入list，输出list）。想转成向量，必须显式调用 simplify2array() 或 unlist() ：

# ❌ 错误：期望向量，得到list
means_list <- lapply(list(1:3, 4:6), mean)  # list(2, 5)

# ✅ 正确：用vapply()，它强制指定返回类型，且更安全
means_vec <- vapply(list(1:3, 4:6), mean, FUN.VALUE = numeric(1))

# ✅ 更推荐：用purrr::map_dbl()，语义明确
library(purrr)
means_vec_purrr <- map_dbl(list(1:3, 4:6), mean)

vapply() 比 sapply() 更优，因为 sapply() 会尝试“智能简化”，有时返回matrix有时vector，难以预测； vapply() 要求你声明 FUN.VALUE （如 numeric(1) 表示返回长度为1的数值向量），R会严格检查，