盘古之白：中文和英文之间的那个空格

一句话结论

中英文混排时，中文与英文、数字、半形符号之间必须加空格。 这个空格叫「盘古之白」，是中英文排版的基本规范，不是可选的美化。

为什么这个空格不能省

中文是方块字，英文是字母，两者的字宽和视觉密度完全不同。紧贴在一起时会产生三个具体问题。

词边界模糊

读者的眼睛需要逐字扫描才能判断「Node.js」是一个整体还是「Node」和「js」两个词。有空格时，视觉上自然分组，大脑可以直接识别。

❌ 部署到Kubernetes集群后通过Prometheus监控
✅ 部署到 Kubernetes 集群后通过 Prometheus 监控

没空格的版本，「Kubernetes」和「集群」糊在一起，「Prometheus」和「监控」糊在一起。技术名词本身就长，再和中文黏连，阅读负担成倍增加。

这个问题在技术文档中尤为严重——技术名词通常比日常用语更长、更不常见，读者识别它们本身就需要更多认知资源。如果再加上词边界模糊，阅读效率会断崖式下降。

数字歧义

当数字和中文紧贴时，容易产生歧义或误读。

❌ 2024年发布了3个版本，分别是v1.0、v1.1和v2.0
✅ 2024 年发布了 3 个版本，分别是 v1.0、v1.1 和 v2.0

「2024年」没空格时，读者需要回读确认边界。版本号「v1.0」和后面的顿号挤在一起，视觉上也需要额外拆分。

标点粘连

半形标点（@、#、%、/）和中文紧贴时，视觉上会和中文笔画混在一起。

❌ 请发送到admin@example.com，CPU占用80%以上时告警
✅ 请发送到 admin@example.com，CPU 占用 80% 以上时告警

行业实践

Google 的中文开发者文档、Apple 的中文产品页面、Microsoft 的中文技术白皮书，全部遵循了中英文之间加空格的规范。国内的少数派、阮一峰博客、美团技术博客、字节跳动技术团队等技术媒体也一致采用。

从排版学的角度看，这个空格的作用等同于西文排版中的「字距调整」（kerning）——在视觉密度不同的字符之间人为增加间距，让整段文字的灰度更均匀。中文排版大家范用先生在《书籍装帧设计》中也提到：

「中西文混排时，须在两者之间留出适当间距，以免笔画相犯。」

它已经是中文技术写作的事实标准。

一个有趣的类比

可以把盘古之白想象成城市道路中的人行道。中文汉字是建筑，英文字母是路灯杆——建筑和路灯杆紧贴在一起时，行人（读者）需要侧身绕行（额外注意力）。留出人行道（空格）后，行人可以顺畅通过。人行道不是建筑的一部分，也不是路灯杆的一部分，它是两者之间的公共空间，服务于通行（阅读）这个目的。

这个类比也解释了为什么「全形标点不需要空格」——全形标点本身就是建筑的一部分（方块字体系），和中文汉字之间不需要人行道。

盘古之白是什么

盘古之白指的是中文（及中文标点）与半形字符之间的空白。「盘古」取开天辟地之意——这个空格劈开了全形字和半形字之间的混沌。

需要加空格的场景

需要加空格的半形字符分为三类：英文字母、数字、半形符号。

类型	示例	正确写法	说明
英文字母	React、Docker、iOS	使用 React 框架	所有英文单词与中文交界处
数字	128、3.14、2024	共 128 个文件	阿拉伯数字与中文交界处
版本号	v2.0.1、Node 18	升级到 v2.0.1	版本号本质是字母+数字组合
半形符号	@、#、%、/	占比 80%	半形符号与中文交界处
命令行	npm install、docker build	运行 npm install 命令	CLI 命令与中文交界处
协议名	HTTP、REST、gRPC	通过 HTTP 协议通信	缩写词与中文交界处
数据库	MySQL、Redis、MongoDB	配置 MySQL 连接	数据库名与中文交界处

不需要加空格的场景

场景	说明	示例
全形标点与英文之间	全形标点本身已有视觉间距	使用 React。
中文与中文之间	同为方块字，字宽一致	安装完成后配置
英文内部	英文单词之间的空格是英文语法	npm install
专有名词内部含中文	品牌名本身含中文成分	微信小程序
数学公式	公式有自己的排版规则	x² + y² = z²
代码块内	代码块遵循编程语言的语法规范	`console.log('hello')`

边界情况 {id="edge-cases"}

中文引号与英文之间

中文引号（「」""''）是全形字符，和英文之间不需要额外空格。但半形引号（""''）和中文之间需要空格。

✅ 他说「Hello World」    ← 全形引号，不需要空格
✅ 他说 "Hello World"    ← 半形引号，需要空格

括号与英文之间

全形括号（（））不需要，半形括号（()）需要。

✅ 安装了 Node.js（版本 18）  ← 全形括号，不需要空格
✅ 安装了 Node.js (版本 18)  ← 半形括号，需要空格

连字符与中文之间

连字符（-）作为连接符时，前后是否加空格取决于它连接的是什么。

✅ client-side rendering          ← 英文复合词，连字符前后不加空格
✅ 基于 client-side rendering 的方案  ← 中文和英文之间加空格

三种实现方式

根据使用场景不同，实现盘古之白有三种方式，分别对应写作阶段、发布阶段、运行阶段。

写作时

最可靠的方式是在写作时直接输入空格。这是源头控制——从第一行文字开始就符合规范，不需要后续处理。

优点： 零依赖、零成本、完全可控。作者可以精确决定哪些地方加空格、哪些地方不加。

缺点： 依赖作者的习惯和自觉性。如果团队成员习惯不一致，产出的文档风格会参差不齐。

实施建议： 在输入法中设置中英文切换快捷键（如 Shift 或 CapsLock），减少切换成本。部分输入法（如搜狗输入法、微信输入法、RIME）支持自动在中英文之间插入空格，可以开启此功能。macOS 自带的中文输入法从 Sonoma 开始也支持这一特性。

发布时

对已有的大量文本，可以在内容发布管线中用工具批量插入空格。核心逻辑是用正则表达式匹配 CJK 字符与半形字符的交界处，在两者之间插入空格。

匹配规则本质上只有两条：

规则1：CJK字符 + 半形字符 → 中间插入空格
规则2：半形字符 + CJK字符 → 中间插入空格

优点： 一次性处理大量存量内容，不需要修改作者的写作习惯。

缺点： 正则规则可能误伤——URL 中的中文路径、代码注释中的中英文混排、Markdown 标记语法中的空格、已有空格的位置重复插入，都可能被错误处理。需要针对不同格式做白名单排除。

⚠️ 注意： 处理前先做 dry-run（只检测不修改），人工确认匹配结果是否合理。对 Markdown 文件特别谨慎——Markdown 中的空格有语法含义，批量处理大概率会搞坏格式。

运行时

不想改源数据、只想在展示层修正排版的场景，可以在浏览器端自动处理。核心原理是用 MutationObserver 监听 DOM 变化，对新增的文本节点做正则匹配并插入空格。

优点： 不修改源数据，对 CMS、评论区、用户生成内容等不可控来源特别有用。

缺点： 只能处理浏览器端渲染的内容，对服务端渲染的纯文本、API 返回的数据、导出的 PDF 无效。

实施建议： 只处理文本节点（nodeType === 3），跳过 <code>、<pre>、<script>、<style> 标签内的内容。用 debounce 避免频繁触发。对于单页应用（SPA），还需要监听路由变化，在页面切换后重新处理新内容。

运行时方案对 SEO 的影响： 运行时插入的空格会被搜索引擎爬虫抓取到。如果你的 SEO 策略对页面文本精确匹配有要求，需要评估这个影响。不过对于绝大多数网站，运行时插入的空格对 SEO 没有负面影响——Google 的中文搜索本身就理解中英文之间的空格。

适用边界

盘古之白有明确的适用范围，核心判断标准是：这段文本的最终呈现形式是什么？

呈现形式	是否适用	原因
HTML 网页	✅	空格在 HTML 中是展示层，不影响语义
纯文本	✅	空格直接提升可读性
富文本编辑器	✅	空格是内容的一部分，直接可见
PDF / 打印	✅	空格在排版中起分词作用
Markdown 源文件	❌	空格有语法含义，可能破坏标记格式
代码文件	❌	遵循编程语言的语法规范
数据库存储	⚠️	看情况，推荐在展示层处理

Markdown 是最常见的踩坑场景

警告

Markdown 中的空格有多种语法含义，批量插入几乎一定会搞坏格式。

语法	空格的作用	被破坏的后果
`code`	前后空格影响是否被识别为行内代码	代码标记失效，变成普通文本
`[text](url)`	内部空格可能破坏链接语法	链接无法点击
`bold`	边界空格影响加粗是否生效	加粗标记暴露为星号
列表 `- item`	行首空格决定缩进层级	列表层级错乱

正确做法是在 Markdown 编辑器中手动加空格，或者在 Markdown 渲染为 HTML 之后再处理。

数据库存储的取舍

如果你的系统中同一份数据会被多个渠道展示（网页、APP、邮件、PDF 导出），有两种处理策略：

存储层处理

在写入数据库时就插入空格。

✅ 所有渠道一致
❌ 修改了原始数据
❌ 部分渠道可能不需要空格（如纯英文展示）

展示层处理

在渲染输出时才插入空格。

✅ 原始数据干净
✅ 各渠道独立控制
❌ 每个渠道都要实现一遍逻辑

中文与日文、韩文的差异

盘古之白主要针对中英文混排。日文和韩文有自己的混排规则：

语言	混排规则
中文	中文与半形字符之间加空格
日文	日文中使用半形片假名时通常不加空格
韩文	英文空格规则和中文类似但不完全相同

如果你的内容面向多语言受众，需要分别处理，不能一刀切。

总结

盘古之白的本质是一个排版效率问题——在视觉密度不同的字符之间插入空格，降低读者的认知成本。它不需要额外的工具、不需要改变写作流程，只需要在中英文交界处多按一下空格键。

如果你记不住所有规则，只需要记住一条：中文遇到英文或数字，中间加空格。 这条规则覆盖了 95% 的场景。剩下的边界情况（全形标点、代码块、Markdown 语法）遇到时再具体判断。

养成这个习惯后，你会发现自己的文字读起来更舒服，别人读你的文字也更舒服。这个空格不大，但积少成多，整篇文章的阅读体验会有质的提升。好的排版就像好的空气——你不会注意到它的存在，但一旦缺少它，你会立刻感到不适。