R语言实战：从环境配置到四大统计场景的完整路径

很多人第一次接触R，不是因为要写论文，也不是因为要做数据分析，而是被一句话说服的：这东西做统计和画图特别顺手。结果真正打开电脑，第一步就卡住了——R和RStudio到底是两个东西还是一个东西？装完之后满屏的红色报错怎么看？学了两周语法，还是不知道怎么把手里那张Excel表变成一张能放进报告的图。这本《R语言实战（第3版）》之所以能被三十万以上的学习者拿来当入门和案头工具，核心原因不在于内容有多高深，而在于它把"从装环境到跑通一个完整分析"的链路给串起来了。

我自己前前后后带过几批新人上手R语言，也帮不少做微生物组、代谢组、时间序列和生态学建模的同事排查过环境问题。看得多了会发现一个规律：真正劝退人的从来不是统计模型本身，而是安装、包管理、编码、版本这些"看起来不重要"的杂事。这篇内容就围绕R语言实战这条主线，把安装配置、数据清洗、可视化以及α多样性、OPLS-DA、SARIMA、GLMM这四个高频统计场景串成一条可复现的路径，顺便把教程里通常不会写全的坑一次性讲清楚。不管你是完全没碰过R语言的新手，还是已经会写几句代码但总在报错里打转的人，都能按下面的顺序对着做一遍。

1. 一本R语言教程真正要解决的是什么问题

1.1 新手放弃的三个真实节点

我带新人时有个习惯，先不问"你会不会写for循环"，而是问"你卡在哪一步"。统计下来，放弃的人几乎都停在这三个位置。

第一个节点是环境。R语言本体和RStudio是两套东西：前者是解释器，真正干活的引擎；后者是编辑器，负责让你敲代码舒服一点。很多人在搜索"r语言下载"的时候看到两个下载页面，随手装了RStudio就以为完事了，结果双击打开发现提示找不到R，或者打开之后控制台一片空白。这是最冤的一种放弃方式，因为问题本身只要五分钟就能解决。

第二个节点是语法碎片化。零散地记住了mean()、sd()、table()，但不知道它们之间怎么拼起来。真实的分析流程是"读入数据→检查结构→清洗→变换→建模→出图→导出"，是一条流水线，而碎片化的知识点是散落在地上的零件。教程的价值很大程度上在于把这些零件按装配顺序摆好。

第三个节点是报错。R语言的报错信息对新手其实不算友好，object 'x' not found和there is no package called 'xxx'看起来都很像天书。更麻烦的是，网上搜到的答案可能是五年前写的，用的包早就换了接口，代码复制过去继续报错，几次下来人就麻了。我在实操中总结出来的经验是：先看报错的最后一行，再往上找触发的位置，最后用sessionInfo()确认版本，绝大多数问题都能在两分钟内定位到方向。

1.2 教程迭代到第三版，取舍逻辑在哪里

R语言这些年最大的变化，是从以base R为核心，慢慢转向了tidyverse这套风格统一的工具集。老版本教程里大量使用subset()、apply()家族和$取列，能跑，但对新手不友好，因为每一步的写法都不一样。新版教程普遍会把dplyr、ggplot2比重调高，同时保留base R的关键内容，这个取舍是合理的——真实项目里你两套都会遇到，别人发给你的老脚本是base风格，你自己写新脚本用管道更顺手。

另一个明显的变化是加入了更多完整的案例链路，而不是只讲单个函数。这一点对做科研的人尤其重要。做α多样性分析、跑OPLS-DA、拟合SARIMA模型、处理嵌套结构的GLMM，这些都不是"一个函数搞定"的事情，中间涉及数据格式转换、假设检验、模型诊断、结果可视化四五个环节。教程把这些环节连起来讲，比自己啃函数文档效率高太多。

提示：不要一次性把教程从头到尾"看完"再动手。R语言是操作性极强的技能，看书和敲代码的时间比建议控制在1:3，看十分钟就停下来把例子跑一遍，记忆效果完全不一样。

2. 在macOS上把R跑起来：安装、绑定与验证

2.1 R本体：架构选择和镜像设置

macOS上装R语言本体，第一条要确认的是芯片架构。Apple Silicon（M系列）和Intel芯片需要下载不同的安装包，装错了不是完全不能用，而是会遇到一些包编译异常的问题，排查起来很费时间。判断方法很简单，左上角苹果菜单进"关于本机"，看芯片那一栏写的是Apple M系列还是Intel。

安装包是pkg格式，双击一路下一步就行，默认会把R装到/Library/Frameworks/R.framework/下面，同时把可执行文件链接到/usr/local/bin/R（M系列芯片较新的版本可能在/opt/homebrew/bin/附近）。装完之后可以在终端里直接输入R进入交互式控制台，输入q()退出。这一步能成功，说明解释器本身没问题了。

接下来是镜像。默认的CRAN主站对国内用户来说下载速度不稳定，装一个几十兆的包等十几分钟很常见。所以第一件事是设置镜像：

# 查看当前镜像 getOption("repos") # 设置镜像（官方全球CDN，稳定性较好） options(repos = c(CRAN = "https://cloud.r-project.org")) # 想永久生效，写进配置文件 file.edit("~/.Rprofile") # 在文件里加入上面那行 options(...)，保存即可

把options()写进~/.Rprofile这个操作，很多人不知道，结果每次重开R都要重新设一遍镜像。这个文件是R启动时自动读取的用户配置文件，除了镜像，还可以在这里设置默认的绘图字体、关闭科学计数法显示、设定字符串不被自动转成因子等等。我一般会建议新手在装完R之后立刻建这个文件，把常用的全局选项一次性写好，后面能省掉大量重复劳动。

2.2 RStudio Desktop与Positron的定位差异

RStudio Desktop是绝大多数人的选择，免费版功能已经完全够用。安装完第一次打开，它会自动扫描本机的R版本；如果没扫到，可以在Tools → Global Options → General → R version里手动选择。手动指定的路径通常是/Library/Frameworks/R.framework/Resources/bin/R。

安装RStudio时有一个细节值得注意：路径里尽量不要出现中文和空格。我见过有人把RStudio放在"下载/我的软件/R语言工具/"这样的目录下，结果某些包在编译时因为路径解析问题反复失败。稳妥的做法是直接放在/Applications/下面，一步到位。

至于Positron，这是近两年推出的新一代数据科学IDE，底层基于VS Code的架构，界面风格和扩展体系和RStudio差别不小。它怎么运行R语言？核心逻辑其实和RStudio一样，需要先指定本机的R解释器路径，然后在工作区里创建.R文件，通过内置的R扩展启动语言服务，控制台、变量面板、绘图面板都会出现。它更适合已经习惯VS Code、或者同时要写Python和R的人。如果你完全是新手，我的建议是先老老实实用RStudio把基础打牢，等你能独立完成一个完整分析流程之后，再去折腾新工具，不然工具本身的配置问题会和语言学习问题混在一起，很难分辨是哪里出错。

2.3 装完之后必做的五项验证

装完不代表配好，我在每台新机器上都会跑一遍下面这段验证代码，五项全过才算环境可用：

# 1. 版本信息 R.version.string # 2. 完整会话信息（排查问题的第一手资料） sessionInfo() # 3. 镜像是否生效 getOption("repos") # 4. 中文路径与编码 x <- data.frame(组别 = c("对照组", "处理组"), 均值 = c(12.3, 15.8)) print(x) write.csv(x, "测试_中文文件名.csv", row.names = FALSE, fileEncoding = "UTF-8") # 5. 绘图设备是否正常 pdf("test_plot.pdf", width = 6, height = 4) plot(1:10, main = "绘图测试") dev.off()

第三项和第五项是最容易被忽略的。第三项验证镜像，能避免后面装包时怀疑人生；第五项验证图形设备，涉及中文标题能否正常输出。很多人第一次画中文图得到一堆方框，就是字体没配置，后面第3节会专门讲。

注意：sessionInfo()输出里会包含R版本、平台、已经加载的包及其版本。以后不管是在社区提问还是找同事帮忙，先贴这段信息，别人能省掉一半的沟通成本。

3. 环境配置里那些教程没写全的细节

3.1 包管理与编译工具链

R语言的生态优势几乎全在包上，但装包这件事本身就有一堆坑。

第一个坑是源码编译。CRAN上的包分两种分发形式：编译好的二进制包和源码包。macOS上如果某个包没有对应的二进制版本，R就会尝试本地编译，而本地编译需要Xcode Command Line Tools，有些包含Fortran代码还需要额外的gfortran编译器。没有这些工具，报错信息会很含糊，比如clang: error: unsupported option '-fopenmp'或者ld: library not found for -lgfortran。解决办法是先在终端执行xcode-select --install，装好命令行工具，再考虑装编译器。

第二个坑是依赖顺序。装A包报错说缺B包，去装B包又报错说缺C包，一层层剥下去很烦躁。我现在的习惯是装包时加上依赖参数，让它自动处理：

install.packages("tidyverse", dependencies = TRUE) # 一次装多个 pkgs <- c("tidyverse", "vegan", "forecast", "lme4", "ropls") install.packages(pkgs, dependencies = TRUE) # 检查哪些包需要更新 old.packages() # 查看已装包 installed.packages()[, c("Package", "Version")]

第三个坑是"装上了但加载不了"。library(xxx)报there is no package called 'xxx'，可能是装到了别的库路径里。用.libPaths()看一下当前的库路径列表，确认安装位置和加载位置是不是同一个。多版本R共存的时候这个问题特别常见——你在R 4.2下装的包，切到R 4.3下自然找不到。

第四个坑是版本冲突。有些包对依赖包有版本上限要求，更新一个包可能导致另一个包失效。稳妥策略是：分析项目一旦跑通，就用renv把当时的包版本快照下来，不要在项目进行中途无脑update.packages()。

3.2 中文乱码、字体与绘图输出

中文问题几乎每个中文用户都会遇到，表现形式有三种：控制台输出乱码、读入文件中文列名变问号、画图时中文变方框。三种的成因不一样，处理方式也不同。

控制台和读入的问题，多半是编码不匹配。macOS上文本文件默认是UTF-8，Windows上常是GBK。跨平台传文件时最容易出事。读入时显式指定编码是最稳妥的做法：

# 读入时指定编码 df <- read.csv("data.csv", fileEncoding = "UTF-8", check.names = FALSE) # 如果是从Windows传来的GBK文件 df2 <- read.csv("data_gbk.csv", fileEncoding = "GBK") # 写完文件也指定 write.csv(df, "out.csv", row.names = FALSE, fileEncoding = "UTF-8")

check.names = FALSE这个参数很实用，它阻止R自动把中文列名里的特殊字符改掉，避免后面按列名取数据时对不上。

绘图方框的问题，本质是图形设备找不到支持中文的字体。两个思路：一是用ragg包作为图形后端，它对字体的处理比默认设备好得多；二是用showtext包显式加载中文字体。

# 方案一：ragg后端 install.packages("ragg") library(ragg) agg_png("plot_cn.png", width = 8, height = 6, units = "in", res = 300) plot(1:10, main = "中文标题测试") dev.off() # 方案二：showtext library(showtext) font_add("heiti", "/System/Library/Fonts/STHeiti Light.ttc") showtext_auto() plot(1:10, main = "中文标题测试")

我个人的偏好是导出位图用ragg，导出矢量图或者需要精确控制字体的场合用showtext。另外PDF导出中文需要额外注意，pdf()设备对字体的支持一直比较弱，用cairo_pdf()通常更省事。

3.3 项目制工作流：一个分析一个目录

新手最常见的工作状态是：桌面上躺着十几个脚本，名字叫分析1.R、分析2_改.R、分析2_最终版.R，数据文件散落在各处，过两个月自己都不知道哪个是最新的。这不是懒，是没人告诉他应该怎么组织。

我的做法是每个分析任务建一个独立目录，用RStudio的Project功能管理：

metabolomics_project/ ├── metabolomics_project.Rproj # 项目文件，双击进入 ├── data/ │ ├── raw/ # 原始数据，只读，绝不修改 │ └── processed/ # 清洗后的中间数据 ├── R/ # 函数脚本 ├── output/ │ ├── figures/ # 图 │ └── tables/ # 表 ├── renv/ # 包版本快照 └── 01_import.R # 脚本按执行顺序编号

.Rproj文件的作用是让RStudio把工作目录自动切换到项目根目录，所有相对路径都从这里算起。这样一来，脚本里写read.csv("data/raw/otu.csv")永远能找到文件，换台电脑也不影响。原始数据只读这条原则尤其重要，我见过太多因为直接在原始表上做修改，最后无法回溯的案例。

4. 从读入到出图：数据分析主线的完整链路

4.1 数据读入：不同来源用不同工具

R语言读数据的函数很多，按来源选工具能省不少事：

readr系列比base的read.csv()快很多，而且默认不把字符串转成因子，这点对新手特别友好——用base函数读入时，如果没加stringsAsFactors = FALSE，所有文本列都会变成因子，后面做字符串操作就会莫名其妙报错。

读入之后的第一件事永远是看结构，不是直接开始算：

library(tidyverse) df <- read_csv("data/raw/samples.csv") glimpse(df) # 一眼看清列名、类型、前几行 dim(df) # 行列数 colSums(is.na(df)) # 每列缺失值数量 summary(df) # 数值列分布概览

glimpse()这个函数我要强烈推荐，它把列名、类型和示例值竖着排开，比str()更容易读。养成读入后立刻glimpse的习惯，能拦下后面一大半的类型错误。

4.2 数据清洗：把脏数据摊在阳光下

真实数据从来没有干净的。清洗环节我一般按固定的顺序走：先看缺失，再看异常，最后看一致性。

缺失值的处理要看缺失机制。如果缺失比例很低且随机，直接删掉是最省事的；如果某列缺失超过一半，这列基本可以放弃；如果缺失和分组相关，那就不能简单删除，得考虑插补或者把它当作信息本身建模。naniar包有个很直观的缺失可视化，扫一眼就知道问题严重不严重。

异常值我不太喜欢用"超过3倍标准差就删"这种机械规则。做生物或医学数据的时候，极端值往往是最有信息量的样本。更稳的做法是先画箱线图或散点图看分布形态，再结合专业判断决定保留还是标记。

一致性方面，最容易出问题的是分组名称。同一个"对照组"，在这张表里写"CK"，在那张表里写"Control"，一join就出问题。清洗阶段统一命名规范，比在建模阶段调试半天要划算得多。

# 统一分组命名 df <- df %>% mutate(group = str_trim(group), # 去首尾空格 group = str_replace_all(group, " ", ""), # 去中间空格 group = case_when( group %in% c("CK", "Control", "control") ~ "Control", group %in% c("TR", "Treat", "treatment") ~ "Treatment", TRUE ~ group )) # 检查有没有意外的分组名 table(df$group, useNA = "ifany")

useNA = "ifany"这个参数值得记住，它会单独列出缺失值的个数。不加这个参数，缺失值就悄悄消失了，你根本不知道有多少行没被统计进去。

4.3 可视化：从探索图到出版级图

ggplot2的语法结构和base绘图完全不同，核心是图层叠加：数据层、映射层、几何层、标度层、分面层。刚开始学的时候，我建议按这个顺序理解，而不是死记参数。

library(ggplot2) p <- ggplot(df, aes(x = group, y = value, fill = group)) + geom_boxplot(alpha = 0.7, outlier.shape = NA) + geom_jitter(width = 0.15, size = 1.8, alpha = 0.6) + scale_fill_manual(values = c("Control" = "#4C72B0", "Treatment" = "#DD8452")) + labs(x = NULL, y = "测定值", title = "两组指标对比") + theme_classic(base_size = 13) + theme(legend.position = "none") ggsave("output/figures/boxplot.pdf", p, width = 5, height = 4)

箱线图叠加散点这个组合，我几乎每个分析都会用。箱线图能看出中位数和离散程度，散点能看出样本量和分布形态，两者合起来比单纯画一个柱状图信息量大得多。柱状图加误差棒这种画法在统计上其实是有争议的，因为它隐藏了分布信息。

图片导出这块，ggsave()会自动根据文件后缀判断格式，PDF是矢量图适合排版，PNG适合放进PPT。分辨率参数dpi在导PNG时至少设300，不然打印出来会糊。尺寸单位默认是英寸，写的时候脑子里过一下目标期刊的单栏宽度大约是3.5英寸，双栏约7英寸，按这个设不容易返工。

5. 四类高频统计场景的落地路径

5.1 α多样性分析：从OTU表到稀释曲线

做微生物组或者生态学的人绕不开α多样性。它的输入通常是一张OTU/ASV丰度表，行是特征，列是样本，加一份样本分组表。核心步骤是：抽平或标准化→计算多样性指数→统计检验→可视化。

library(vegan) otu <- read.table("data/raw/otu_table.txt", header = TRUE, row.names = 1, sep = "\t", check.names = FALSE) otu_t <- t(otu) # vegan要求样本为行 # 抽平到最小测序深度 depth <- min(rowSums(otu_t)) otu_rare <- rrarefy(otu_t, sample = depth) # 计算多个指数 shan <- diversity(otu_rare, index = "shannon") simp <- diversity(otu_rare, index = "simpson") chao <- estimateR(otu_rare)["S.chao1", ] result <- data.frame(Shannon = shan, Simpson = simp, Chao1 = chao, Group = meta$Group)

抽平这件事争议一直存在，有人主张用稀释曲线确认测序深度充分即可，不一定要抽平。我的经验是：如果各组测序深度差异很大，抽平更稳妥；如果深度接近，用相对丰度或者CSS标准化也可以。关键是方法要在报告里写清楚，不能偷偷换。

指数选择上，Shannon对低丰度物种更敏感，Simpson对优势物种更敏感，Chao1估的是物种总数。三个一起报，配合稀释曲线（rarecurve()），基本能说明问题。统计检验常用Kruskal-Wallis或者Wilcoxon，前者不要求正态性，在样本量小的时候更保险。

5.2 OPLS-DA：判别建模与过拟合防线

代谢组学、转录组学里，OPLS-DA是用来区分组间差异、筛选标志代谢物的常用方法。ropls包是R里比较成熟的实现。

library(ropls) x <- as.matrix(read.csv("data/processed/metabolites.csv", row.names = 1)) group <- factor(read.csv("data/processed/group.csv")$Group) model <- opls(x, group, predI = 1, orthoI = NA) # 提取评价指标 model@summaryDF # R2X, R2Y, Q2Y vip <- getVipVn(model)

判断模型是否可信，我的标准是看三个数：R2Y表示模型对Y的解释能力，Q2Y是交叉验证预测能力，两者差值如果超过0.3，就要警惕过拟合。更严格的检验是置换检验，把分组标签随机打乱几百次重新建模，看真实模型的Q2Y是否显著高于随机分布的尾部。

perm <- randtest(model, nperm = 200) # 或用ropls内置的置换功能 plot(perm)

选差异代谢物时，VIP大于1是一个常用阈值，但我不建议只看VIP。更稳的做法是VIP、单变量p值（校正后）、变化倍数三个条件取交集。只靠VIP筛出来的物质列表，经常包含一堆在生物学上没法解释的东西。

5.3 SARIMA：时间序列的定阶、诊断与预测

SARIMA适合有趋势和季节性的序列，比如月度销量、季度监测数据。整个流程是：平稳性检验→差分定阶→模型拟合→残差诊断→预测。

library(forecast) ts_data <- ts(values, start = c(2018, 1), frequency = 12) # 平稳性检验 adf.test(ts_data) # 自动定阶（关闭stepwise，搜索更充分但慢） fit <- auto.arima(ts_data, seasonal = TRUE, stepwise = FALSE, approximation = FALSE) summary(fit) checkresiduals(fit) forecast(fit, h = 12) %>% autoplot()

auto.arima()很方便，但不是万能的。它按信息准则选模型，有时候会选出参数过多、解释性差的模型。遇到这种情况，我会用Acf()和Pacf()看自相关图手动判断，或者把max.p、max.q限制在合理范围内再用它搜。

残差诊断这一步绝对不能跳。checkresiduals()会给出残差图、残差ACF和Ljung-Box检验结果。如果残差还有明显的自相关，说明模型没把结构提取干净，预测结果不可信。"模型跑出来了"和"模型可用"是两码事，很多新手直接跳过诊断看预测值，这是最容易翻车的地方。

5.4 GLMM：处理嵌套结构和非正态数据

当数据不独立（比如同一个采样点的多个样本）或者响应变量不是正态分布（计数、比例、二分类），普通线性模型就不适用了，需要广义线性混合模型。

library(lme4) m1 <- glmer(cbind(success, fail) ~ treatment + (1 | site), data = d, family = binomial) m2 <- glmer(count ~ treatment + (1 | site) + (1 | plot), data = d, family = poisson) summary(m1) VarCorr(m1) # 随机效应方差

模型选择上，固定效应是你要检验的主效应，随机效应是必须考虑但本身不是研究重点的结构。判断某个变量该放固定还是随机，看你的研究问题：如果关心"不同处理之间的差异"，处理是固定效应；如果样本来自若干随机选取的地点、只希望控制地点带来的变异，地点是随机效应。

GLMM最常见的两个问题是收敛失败和过度离散。收敛失败一般先试试把连续变量标准化、减少随机效应复杂度、换优化器（control = glmerControl(optimizer = "bobyqa")）；过度离散在泊松模型里很常见，可以改用负二项族，或者用glmmTMB包，它支持的族更多，收敛也往往更稳。

6. 跑得快、跑得稳、跑得可复现

6.1 性能优化：先找瓶颈再动手

很多人一遇到慢就想着上并行，其实大部分时候瓶颈不在计算，而在代码写法。我在给脚本提速时会按这个顺序检查。

先看有没有在循环里反复增长对象。for循环里不断rbind或者c()是典型的性能杀手，提前预分配容器能带来数量级的提升。

# 慢 result <- c() for (i in 1:10000) { result <- c(result, i^2) } # 快 result <- numeric(10000) for (i in 1:10000) { result[i] <- i^2 }

再看能不能向量化。R的向量化运算底层是C实现的，比循环快得多。能用ifelse()、apply家族或者dplyr的向量化函数解决的，就别写循环。实在要循环，考虑purrr::map_*系列，语法更统一。

真正需要并行的时候，future加furrr的组合比传统并行包好用得多：

library(future) library(furrr) plan(multisession, workers = 4) results <- future_map(1:100, function(i) { Sys.sleep(0.5) i^2 })

plan()这一行的好处是，你换并行策略的时候不用改下面任何代码，从串行切到多进程只改一行。这个设计我用下来非常舒服。

6.2 可复现性：半年后还能跑通

可复现这件事，看起来是给别人看的，实际最大的受益人是半年后的自己。我自己踩过的坑是：一个分析做完三个月，合作者让补一张图，代码跑不起来了——某个包更新后改了函数签名。

三个措施能解决九成问题。

第一个是种子。任何涉及随机数的操作（抽样、聚类初始化、交叉验证划分、置换检验）之前都设set.seed()，不然每次跑出来结果都不一样，没法核对。

第二个是renv。项目初始化时执行renv::init()，它会在项目目录里记录当时用的所有包版本，换机器时执行renv::restore()就能还原到完全一致的环境。这个包用了就回不去了。

install.packages("renv") renv::init() # 初始化 renv::snapshot() # 记录当前包版本 renv::restore() # 在新环境还原

第三个是脚本结构。我习惯把分析拆成几个编号的脚本，每个都尽量做到"从项目根目录出发，一路执行到底"：01_import.R读入并保存中间数据，02_clean.R清洗，03_analysis.R建模，04_figures.R出图。中间结果存成rds文件，用readRDS()读取，比每次重新算快得多，也方便定位问题出在哪一环。

saveRDS(clean_df, "data/processed/clean_df.rds") df <- readRDS("data/processed/clean_df.rds")

rds格式比csv好用的地方在于它能完整保存数据类型（因子、日期、列表列），读回来不用重新转换类型。

6.3 报错排查：一套可以复用的思路

R语言报错信息读起来费劲，但有固定套路。

第一步看最后一行。R的报错往往是"错误信息 + 调用栈"，最后一行通常是根本原因，上面几行是触发路径。比如Error in filter(., group == "A") : object 'group' not found，问题明显出在列名上。

第二步确认对象是否存在、类型是否正确。class(df)、names(df)、str(df)这三条几乎能解决一半的"object not found"和"unused argument"问题。特别是列名，中文列名、带空格列名、大小写差异都会导致找不到。

第三步才是搜报错。搜的时候把具体变量名去掉，只留报错模板，命中率会高很多。找到答案后先看发布时间和适用的包版本，超过两三年且涉及具体函数的答案要打折。

第四步，如果还是解决不了，构造最小可复现示例。把数据和代码精简到十几行，很多时候在精简的过程中问题自己就暴露了。这个习惯看着费事，实际是最快的路径。

我把常见报错整理成了一张对照表，贴在显示器旁边能省不少时间：

最后分享一个我用了很多年的小习惯：每次解决完一个报错，就在项目目录里建个notes.md，把报错原文和解决办法记一行。坚持半年之后，你会发现新报错越来越少，因为R语言世界里的坑，翻来覆去就是那些。我自己那份笔记到现在攒了快两百条，带新人的时候直接给他们，比任何教程的附录都实用。至于要不要现在就去折腾新出的工具、要不要上高性能计算，我的建议是先把一个完整流程从原始数据跑到成图，跑通三遍以上再说，工具的门槛永远比方法低，先把手上的数据变成能解释的结果，比什么都重要。