1. 乱码问题的第一现场：先搞清楚中文为什么会变成方块

先承认一件事：R语言绘图的中文乱码，几乎是每个用R做数据分析、科研绘图、数学建模的人都会撞上的墙。你可能是实验室里跑完一堆数据，最后出图时发现所有轴标签都是豆腐块；也可能是在公司里用ggplot2做了季度报表，中文标题全部变成一串问号。这个问题最气人的地方在于——它不是统一的报错，而是各种花样百出的乱法。

在我处理过的项目里，中文显示问题通常分成三类，你可以先对号入座：

第一类是方框/豆腐块。这种情况最常见，图表上中文全部变成一个一个空心小方框。说白了，就是R的绘图设备找不到能渲染中文字符的字体文件，于是拿一个默认字体硬顶，顶不上的字符就变成占位符。第二类是问号。如果你用的是Windows平台，出现问号通常是编码问题——字符串本身在进入绘图函数之前就已经坏掉了，字符编码从UTF-8被错误地转成了本地编码，绘图设备拿到的根本不是有效的中文。第三类是空白或乱码堆。常见于Linux服务器上跑R脚本，系统的locale环境没有正确设置，R读到的中文字符串变成了乱码，绘图时自然什么都画不出来。

我在实际调试中总结了一个判断口诀：先看控制台输出，再看图形设备。如果控制台里print出来是正常中文，但图上乱码，那就是字体问题；如果控制台输出本身就是乱码，那就是编码或locale问题。很多初学者一开始就在绘图参数里折腾，绕了一大圈发现根子根本不在这里。

理解了乱码从哪里来，后面所有操作就都有方向了。下面我会按照"Windows桌面端→Linux服务器→macOS"三条主线拆解完整方案，再把base R绘图、ggplot2、plotly这几种常见绘图体系逐一适配，最后附上高频报错速查表。全程只讲实际踩过坑之后验证过的方法，你可以照着走。

2. 解开乱码的底层逻辑：字体匹配、字符编码与绘图设备的关系

2.1 字体匹配：R绘图引擎如何决定用哪个字体渲染中文

R的绘图体系里，文字渲染最终都要落到一个具体的字体文件上。无论是base R的text()、title()，还是ggplot2里层层封装过的element_text()，它们最后都会把文本内容和字体参数传给底层图形设备。这个底层设备在不同平台上各自不同——Windows上是windows图形设备，macOS上是quartz，Linux上则是X11或cairo。

问题恰恰出在这个"字体参数"上。R的默认字体家族在Windows下通常是"sans"，映射到系统字体时，它优先取Arial一类西文字体。当一段文本里既有ASCII字母又有中文字符时，R会把整段文本按单一字体去渲染，结果中文部分因为Aril里根本没有对应字形，直接变成方框。

一个容易被忽视的细节是：R不是按单个字符去挑选字体的，而是整段文字绑定一个字体。这就是为什么你有时候把中文字体设置好了，英文反而变得不好看——因为中文字体里的英文字形通常不如专门的西文字体精致。反过来，如果只设置了Arial，中文就全灭。所以正确的做法不是"找一个大而全的字体"，而是"在文本中显式声明中文字体家族"。

2.2 字符编码：字体找到了，字符串却在半路就坏了

字体匹配解决的是"渲染"环节，编码解决的是"传输"环节。R脚本文件本身保存的编码格式，决定了R读入中文字符串时能否正确识别。这里要分清两个层面的编码：

第一层是脚本文件的存储编码。你用RStudio编辑脚本时，文件的保存编码可能是UTF-8，也可能是系统默认的GBK（中文Windows下常见）。当RStudio默认以UTF-8读取一个GBK编码的脚本时，脚本里的中文字符串就已经被错误解析，后续无论怎么设置字体都是白搭。

第二层是系统locale环境。在Linux服务器上，如果Sys.getlocale()返回的不是zh_CN.UTF-8这一类支持中文的locale，R脚本里直接写入的中文字符串就会在解析阶段变成乱码。这个问题在Windows上相对少见，因为R的Windows版本在启动时会自动处理代码页，但Linux下特别容易踩坑。

我见过太多人在网上发帖问"为什么我的R图中文全是问号"，下面一堆回复让换字体，结果换了半天还是问号——其实问题就出在脚本文件本身的编码上。排查顺序一定是先确认字符串是否正确，再考虑字体。

2.3 绘图设备的差异：png、pdf、屏幕显示为什么行为不一致

同样一段代码，在RStudio的Plots窗口显示正常，导出成PNG就乱码；或者用ggsave()存PDF没问题，但不指定设备直接保存就乱码。这种"换个设备就翻车"的现象，核心原因在于不同图形设备对字体的处理机制完全不同。

• windows()设备：这是Windows平台RStudio的默认屏幕设备，它直接调用Windows系统的字体渲染接口。如果系统装了中文字体（绝大多数Windows都自带微软雅黑），那么只要R能找到字体别名，屏幕显示一般没问题。
• png()设备：早期R的png()设备默认使用Xlib或Windows GDI，字体的映射规则和屏幕设备不同，经常出现屏幕正常、导出乱码的情况。在Linux服务器上尤其明显，因为很多精简版系统根本没装中文字体。
• pdf()设备：PDF设备有一个特别麻烦的特性——它默认嵌入的是字体子集，而且R的PDF设备对非ASCII字符的支持曾经很弱。即使你设置了family="STSong"，生成的PDF在部分阅读器里可能正常，但在另一些阅读器里中文字符会变成空白。
• cairo设备：png(type="cairo")或svg(type="cairo")这类基于cairo库的设备，字体渲染走的是系统fontconfig方案，对中文支持明显比传统设备好很多。这也是我强烈推荐的方案之一。

所以面对"同一份代码，不同设备表现不同"的问题，你要做的是统一设备的字体处理路径，而不是挨个设备去试，下面的实操环节会展开说明。

2.4 三种"一键全平台"的解决思路对比

在进入具体实操前，我想先给你一个整体方案选型的框架。我在不同项目里用过好几种思路，各有优劣：

我自己现在的习惯是：新项目一律用showtext，老代码里遇到乱码优先排查后切到showtext。这套方案的核心优势是它直接把字体文件（比如msyh.ttc）嵌入到渲染流程中，不依赖系统有没有注册这个字体，因此你在Windows上写的脚本放到Linux服务器上跑，只要字体文件路径对，输出完全一致。下面各节的实操就会围绕showtext展开，同时也会告诉你不用它时怎么兜底。

3. 实操第一步：Windows环境下中文显示的完整配置

3.1 从零开始：检查系统字体与R的字体发现机制

在Windows上，绝大多数乱码问题的根源其实不在R，而在于R没有正确找到系统中文字体。先做一个基础检查：

# 查看当前绘图设备 names(dev.cur()) # 查看系统里有哪些中文字体可以被R发现 # Windows下通常能看到Microsoft YaHei、SimHei、SimSun等 if (interactive()) { windowsFonts() }

如果你在windowsFonts()的输出里看不到任何中文字体，那问题就很直接了：R的Windows图形设备默认只注册了少数几种字体，中文字体没有自动挂载。这时候就算你在代码里写了family = "SimHei"，R也认不出来。

解决办法是显式注册。以微软雅黑为例：

# 注册中文字体到R的windows图形设备 windowsFonts( YaHei = windowsFont("Microsoft YaHei"), SimHei = windowsFont("SimHei"), SimSun = windowsFont("SimSun") ) # 验证是否能正常渲染 png("test_cn.png", width = 800, height = 600, type = "cairo") plot(1:10, main = "中文标题测试：你好，世界") dev.off()

这里有两个关键点。第一，windowsFonts()注册属于当前R会话，每次重启R都需要重新执行，如果你想长期省事，建议写进.Rprofile文件里。第二，type = "cairo"很重要，cairo设备对中文字体的兼容性远好于默认的GDI设备，能减少很多莫名其妙的乱码。

3.2 showtext方案：一套配置通吃屏幕、PNG和PDF

如果你不想在每次绘图时都操心设备类型，showtext是更省心的选择。基本配置只有三行：

# 安装并加载showtext install.packages("showtext") library(showtext) # 从系统字体目录加载字体文件，或者直接指定ttf/ttc路径 font_add("yahei", "C:/Windows/Fonts/msyh.ttc") # 打开全局开关，后续所有绘图自动走showtext渲染 showtext_auto()

一旦执行了showtext_auto()，无论是RStudio的Plots窗口，还是ggsave()导出PNG，都不需要再额外设置family。ggplot2里直接用中文字体名称即可：

library(ggplot2) df <- data.frame( category = c("产品A", "产品B", "产品C"), value = c(23, 45, 67) ) ggplot(df, aes(x = category, y = value)) + geom_col(fill = "#4C72B0") + labs(title = "各产品销量对比", x = "产品类别", y = "销量（件）") + theme_minimal(base_family = "yahei")

这里需要解释一下为什么showtext能做到"一套配置通吃"。它的原理是拦截R的文本绘制请求，把文本先转成路径（polyline）再交给图形设备渲染，相当于在R和图形设备之间加了一层"翻译官"。因为最终绘制的是路径而不是字体，所以图形设备本身支不支持中文已经无所谓了。

不过要提醒一句：showtext对中文路径的渲染会稍微增加出图时间，如果你在做几千张图的批量渲染，能感觉到明显差异。这种情况下可以考虑只在最终出图阶段开启showtext，中间探索阶段用默认设备。

3.3 在RStudio里的字体设置陷阱：编辑器和绘图窗口是两回事

还有一个经常被忽略的地方：RStudio编辑器里的中文显示正常，不代表绘图窗口也正常。编辑器的字体渲染走的是Qt/CEF那套，跟R的图形设备完全无关。所以你在编辑器里看到中文很正常，但一跑plot()还是方框，两者没有任何关联。

反过来，如果你在RStudio里把编辑器字体设置成了某种不含中文的等宽字体，那只是编辑器显示问题，不影响R输出的图表。这两个概念很多新手分不清，以为改RStudio的设置就能改图的字体——根本没有用。

真正的操作路径是：RStudio的Tools → Global Options → Appearance → Editor Font里设置的是代码编辑器的字体；而图的字体完全由R代码控制。别把时间浪费在错误的地方。

3.4 保存图片时的编码风险：ggsave和png设备不能乱用

在Windows上还有一个高频坑：在RStudio里用ggsave()默认保存图片时，图片里的中文显示正常；但如果你在命令行里跑同样的脚本（比如Rscript test.R），保存出来的图片中文就乱码了。原因同样落在字体发现机制上——Rscript环境下没有初始化RStudio那套图形设备，也没有附带执行.Rprofile里的配置（取决于你启动Rscript的方式）。

我建议保存图片时显式指定设备和字体，不要依赖默认值：

# 推荐写法：显式指定cairo设备 ggsave("output.png", width = 8, height = 6, dpi = 300, device = png, type = "cairo") # 或者干脆用ragg，一步到位 install.packages("ragg") ggsave("output.png", width = 8, height = 6, dpi = 300, device = agg_png)

ragg包是这几年比较推荐的新方案。它的渲染引擎是纯C实现的AGG库，对字体回退（font fallback）的支持比R自带的设备成熟得多。如果你有一段文本里混着简体中文、英文字母甚至偶尔几个生僻字，ragg能自动在系统里找到合适的字体完成渲染，不需要你手动指定font family，这对结构化输出的自动化脚本尤其重要。

4. 实操第二步：Linux服务器环境下彻底解决中文乱码

4.1 先检查环境和字体安装情况

在Linux服务器上跑R脚本，遇到中文乱码的概率比Windows高得多，因为很多服务器是精简安装，中文字体压根不存在。先跑这几行代码检查：

# 终端检查系统里有没有中文字体 fc-list :lang=zh

如果输出为空，那就说明系统里没有可用中文字体，后面设置再多R参数也无济于事。安装方法根据发行版不同有差异：

# Debian/Ubuntu系 apt-get install -y fonts-wqy-zenhei fonts-wqy-microhei # CentOS/RHEL系 yum install -y wqy-zenhei-fonts wqy-microhei-fonts

文泉驿系列是目前Linux上最常用的中文字体之一，而且开源免费，不用担心版权问题。装完之后再跑一次fc-list :lang=zh，应该能看到字体列表了。

4.2 设置locale：确保R能正确读取中文字符串

字体装好了，还需要确保R能正确解析中文字符串。在运行R脚本之前，先在终端设置locale：

# 设置环境变量 export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8

然后进入R环境验证：

Sys.getlocale()

如果返回结果里LC_CTYPE是zh_CN.UTF-8，说明环境没问题。如果系统里根本没有zh_CN.UTF-8这个locale，还需要先运行locale-gen zh_CN.UTF-8（Debian系）或修改/etc/locale.conf（CentOS/RHEL系）。

这里有个容易忽略的细节：R脚本文件本身的编码。如果你在Windows上写好脚本，用FTP传到Linux服务器，文件编码很可能还是GBK，这时候Linux上R以UTF-8读取就会乱码。最简单的处理方式是用iconv转换一下：

iconv -f GBK -t UTF-8 original.R > converted.R

4.3 showtext在Linux下的字体配置方式

Linux下showtext的用法和Windows基本一致，差别在于字体文件路径不同。上面安装的文泉驿字体，文件一般位于/usr/share/fonts/truetype/wqy/目录下，你可以这样注册：

library(showtext) font_add("wqy", "/usr/share/fonts/truetype/wqy/wqy-zenhei.ttc") showtext_auto()

有条件的也可以直接上传微软雅黑或思源黑体的ttf文件到服务器任意目录，用绝对路径加载，完全不依赖系统字体注册表。这就是showtext的优势——它直接读文件，不走系统fontconfig。

4.4 批量出图场景的实际案例：一个科研绘图脚本的完整配置

我在做一个批量物种多样性分析项目时，需要在Linux服务器上一次性渲染几百张图，每张图都有中文标题和中文轴标签。当时踩过一轮坑，最终稳定下来的脚本结构是这样的：

#!/usr/bin/env Rscript # 批量出图脚本：中文显示统一配置 library(showtext) library(ggplot2) # 使用绝对路径加载字体，不依赖系统字体注册 font_add("heiti", "/data/fonts/source-han-sans-cn.ttf") showtext_auto() # 统一绘图主题，所有图共用 theme_cn <- theme_minimal(base_family = "heiti") + theme( plot.title = element_text(size = 16, face = "bold", hjust = 0.5), axis.title = element_text(size = 12) ) # 循环出图 for (i in 1:nrow(species_list)) { p <- ggplot(...) + labs(title = species_list$name[i], ...) + theme_cn ggsave(paste0("plot_", i, ".png"), p, width=8, height=6, dpi=300) }

这套配置跑完几百张图没有出现一例乱码。关键点在于：字体的绝对路径确保任何环境下都能找到字体文件；showtext_auto()统一接管所有设备的渲染。如果你的出图量没那么大，这个方法基本是零成本复制的。

4.5 如果系统要求不能用showtext，还有哪些Linux兜底方案

showtext依赖R包安装，如果你的环境是离线内网，装包不方便，可以用R自带的cairo_pdf()或png(type="cairo")配合系统字体：

# 使用cairo设备 + 系统字体 png("output.png", width=800, height=600, type="cairo", family="WenQuanYi Zen Hei") plot(1:10, main="中文标题") dev.off()

family参数直接填系统中文字体的名称（不一定和文件名一致，用fc-list查到的family名）。这种方式不需要任何额外R包，但要求系统中文字体已经安装到fontconfig里。它的问题在于跨平台代码不可复用，如果代码要同时跑Windows和Linux，还是老实写两套配置或者用showtext统一更好。

5. 实操第三步：不同绘图体系的中文适配指南

5.1 base R绘图：par参数与title函数的细节

base R绘图的文字渲染逻辑最直接，但坑也不少。核心是设置par(family=...)，注意它必须在plot()之前设置才会生效：

# base R + showtext方案 library(showtext) font_add("cn", "C:/Windows/Fonts/msyh.ttc") # Windows示例 showtext_auto() par(family = "cn") plot(iris$Sepal.Length, iris$Petal.Length, main = "鸢尾花数据散点图", xlab = "花萼长度", ylab = "花瓣长度")

有一个细节容易踩：par(family=...)设置的字体家族会被plot.default()继承，但如果你在绘图后又调用了par(family=...)去改别的参数，会连带影响已经画好的图吗？不会，已经画好的图形不受之后par()改变的影响，但后续的新图会受影响。所以批量绘图时，记得在循环里每轮重新设置，或者用oldpar <- par(no.readonly=TRUE)配合on.exit(par(oldpar))做保护性编程。

此外，text()函数添加文字标注时，family参数同样会生效。比如你想在图里手动标记某个点的名称，只要在text(x, y, labels="某个样本", family="cn")指定一次就行，不用改全局的par。这在实际标注散点图、路径图时很实用。

5.2 ggplot2体系：base_family与theme的配合位置

ggplot2的中文适配比base R稍微复杂一点，因为文字散落在多个主题元素里，包括标题、轴标签、图例文字、注释文本等。如果你只设置了theme(plot.title = element_text(family="cn"))，轴的标签还是乱码——因为轴标签是另一个theme元素。

比较省事的做法是直接在theme_minimal()这一类主题函数里指定base_family：

library(ggplot2) # 主题级别统一设置 theme_set(theme_minimal(base_family = "cn")) # 后续所有ggplot图自动使用该字体 p <- ggplot(mtcars, aes(x = wt, y = mpg)) + geom_point() + labs(title = "汽车重量与油耗关系", x = "重量（千磅）", y = "每加仑行驶里程")

如果你不想用theme_set()改变全局设定，也可以在单个图里调用：

p + theme(text = element_text(family = "cn"))

建议能设置base_family就不要单独设置element_text(family=...)，因为base_family会传递给所有文字元素，单独设置容易漏掉图例文字。

这里还有一个经验之谈：ggplot2里如果用了geom_text()或geom_label()给点上加中文标注，它的字体是不受theme(text=...)控制的，必须在geom_text(aes(label=...), family="cn")里显式指定。我经常看到有人图例、坐标轴都正常了，唯独点上的标签还是方框，原因就在这。

5.3 plotly与交互式图形的中文适配

R里用plotly做交互式图表越来越常见，它走的是HTML5渲染路线，字体控制逻辑和base R、ggplot2完全不同。plotly的默认字体是前端CSS字体栈，中文字体支持取决于打开图表的浏览器环境，而不是R环境。

要让plotly图的中文显示稳定，可以在layout里统一设置字体：

library(plotly) p <- plot_ly( x = c("产品A", "产品B", "产品C"), y = c(20, 30, 40), type = "bar" ) %>% layout( title = list(text = "中文标题测试", font = list(family = "Microsoft YaHei")), xaxis = list(title = list(text = "类别", font = list(family = "Microsoft YaHei"))), font = list(family = "Microsoft YaHei") )

这里的family传入的是浏览器端可识别的CSS字体名，所以必须是"Microsoft YaHei"、"PingFang SC"、"Noto Sans CJK SC"这类通用名称，不能用R里自定义的别名。如果你部署了Shiny应用，把plotly图嵌入网页时，还需要确保客户端浏览器所在的系统安装了对应字体，否则换一台没装微软雅黑的Linux机器访问，中文还是会变成方块，但这是前端问题了，R帮不上忙。

5.4 图片保存时的字体嵌入问题：PDF、PNG、SVG的行为差异

很多人在出图时还有一个盲区：同样的代码，另存为PNG正常，存成PDF再打开中文就消失了。这是因为PDF文件需要把字体本身嵌入进去，而R的pdf()设备默认对非ASCII字体的嵌入支持并不稳。

解决PDF中文问题最可靠的方法，还是用showtext配合cairo_pdf()：

library(showtext) font_add("cn", "C:/Windows/Fonts/msyh.ttc") showtext_auto() # 用cairo_pdf替代base pdf cairo_pdf("output.pdf", width = 8, height = 6) plot(1:10, main = "中文测试") dev.off()

如果是ggplot2，也可以：

ggsave("output.pdf", plot = p, device = cairo_pdf)

一定要记住：showtext_auto()开启后，它会自动把字体轮廓嵌入到PDF里，不开的话，PDF打开就只剩空白。这个坑我当年踩过，交了一份全是空白的PDF给合作方，场面极度尴尬。

至于SVG格式，R的svg()设备同样建议用cairo版本：

svg(filename = "output.svg", width = 8, height = 6, family = "cn") plot(1:10, main = "中文测试") dev.off()

不过SVG文件里即使字体名写对了，对方打开时系统如果没有这个字体，渲染还是会变化。最保险的做法还是把文字转成路径（showtext会自动做），这样任何设备、任何系统打开都是同一效果。

6. 排查与兜底：高频报错与终极应急方案

6.1 高頻问题速查表

我把这些年做R语言科研绘图时真正遇到过的坑，按症状、可能原因、解决方案整理成了一张速查表，你可以直接收藏：

这张表不是我凭空整理的，每一条都在真实项目里出现过。尤其是"Windows正常，Linux乱码"这一条，我见过很多团队把开发环境里跑的代码部署到服务器出图时出问题，最后发现服务器上连中文字体都没装，跟R代码无关。

6.2 终极应急方法：不依赖任何中文字体也能出图

最后分享一个偏门但关键时刻能救命的方案。如果你所处的环境完全没法安装中文字体（比如极度受限的内网机器）、也没法安装R包，但必须出中文图，可以用这个思路绕开字体问题：

把文本直接绘制成图片后嵌入。具体原理是：先用png()在某个已知支持中文的图形设备（比如ggplot2在Windows上）把中文文本单独渲染成一张透明背景的图片，然后在主图里用graphics::rasterImage()或ggplot2的annotation_custom()把它放上去。这个方法会很繁琐，不推荐日常使用，但我在一个几乎没有权限的服务器上靠它撑过了紧急汇报。

更现实一点的应急方案是：直接用英文标签出图，在PPT、Word或AI里补中文。很多科研论文的投稿阶段其实也是这样操作的——先用R出英文无乱码的图，排版时再统一替换成中英双语。这样既避免了系统字体问题，也让图表在跨语言环境中更通用。

6.3 汉化字体环境的一个完整实战脚本

最后附上一个我常用的完整脚本模板，把前面所有方案融成一个可以直接跑通的文件，你只需要按自己系统的路径改一下字体位置即可。这套模板同时覆盖了Windows和Linux，使用方式是在脚本开头设置sys_name：

# ==================================== # R语言绘图中文字体统一配置模板 # 适用：Windows / Linux / macOS # ==================================== library(showtext) library(ggplot2) # 根据系统选择字体路径（按需修改） font_path <- switch( Sys.info()[["sysname"]], Windows = "C:/Windows/Fonts/msyh.ttc", Linux = "/usr/share/fonts/truetype/wqy/wqy-zenhei.ttc", Darwin = "/System/Library/Fonts/PingFang.ttc" ) font_add("custom_cn", font_path) showtext_auto() # 统一主题 theme_cn <- theme_minimal(base_family = "custom_cn") + theme( plot.title = element_text(size = 15, face = "bold", hjust = 0.5), axis.text = element_text(size = 10), axis.title = element_text(size = 11), legend.text = element_text(size = 10) ) # 测试出图 df <- data.frame( lab = c("中文标签一", "中文标签二", "中文标签三"), val = c(0.3, 0.5, 0.8) ) p <- ggplot(df, aes(x = lab, y = val)) + geom_col() + labs(title = "R语言中文适配验证", x = NULL, y = "数值") + theme_cn ggsave("chinese_test.png", p, width = 8, height = 5, dpi = 300)

macOS的字体路径我写的是PingFang.ttc，在部分系统版本里这个路径可能不可用。如果你在macOS上跑，可以先用fc-list :lang=zh找一下系统里实际存在的字体路径再填入。这个模板只要字体路径正确，在任何环境下都能得到同样的中文显示效果。

7. 我长期使用下来的一些体会

处理R语言绘图中文显示这个问题，前前后后也折腾了好几年。最初我走的是最原始的路线——每换一台电脑、每换一个系统，就重新去搜一遍网上零散的教程，试一遍各种方案。后来发现，真正稳定的路径其实非常朴素：确认字符串在进入绘图函数之前是好的，然后让字体处理脱离系统环境，这两件事做到位，乱码问题基本就消灭了。

这些年下来，我对新手朋友的建议始终是：不要急着在RStudio的界面设置里找答案，先把print()一个中文字符串看看有没有乱码；确认无误后，再直奔showtext方案配好字体路径。整个排查过程排除了"编码"和"字体"两大变量之后，剩下的问题基本都集中在具体绘图函数的细节上，比如geom_text()需要单独指定family这一类的"小坑"。

最后再分享一个小经验：如果你的图需要发表在论文、报告或者PPT里，建议统一用ragg或cairo_pdf()保存成高分辨率的位图或PDF，而不要直接截图。截图不仅画质低，而且可能会隐藏字体问题——有时候屏幕上看着好好的，截图里也正常，但放到别人机器上打开就变样。存成嵌入字体的PDF或多倍分辨率的PNG，至少能保证交付出去的文件在别人手里也长一样。

中文显示不是R语言里最核心的统计功能，但它恰恰是最影响工作流顺畅度的环节之一。顺利解决了这个问题之后，你会发现批量出图、跨平台部署、团队协作都变得顺畅很多。希望这篇整理能帮你在处理图表中文显示的时候少走弯路，把时间留给真正该做的数据分析本身。