glow 实测：196 毫秒渲染一份 markdown｜实测库

glow 是终端里的 markdown 渲染器，主程序 19396096 字节。给它一份 .md，它把标题 / 列表 / 引用 / 代码块与表格排成能直接读的样子。

它替掉的是「打开编辑器预览」这一步。改完文档想看一眼效果，编辑器要多占一个窗口，浏览器要点两次；glow 一条命令 196 毫秒出结果，看完就退回提示符。

这次用一份 6687 字节的 markdown 跑完整一轮，里面 30 个小节。量了版本命令 / 渲染耗时 / 输出字节，还有样式开关前后的差值。

解压出来 7 个文件

官方 zip 7025299 字节，解开是 7 个条目共 19437101 字节。主程序一个人占 19396096 字节，剩下的是 LICENSE 和 README 这类文本。

它把样式表编进了 exe

19396096 字节里有几套配色和渲染规则，解压之后不需要额外的主题文件。这也是它比同等功能脚本大的原因，换主题靠参数而不是换文件。

版本命令连跑三次

# 三次耗时 376 / 169 / 175 毫秒
glow --version
glow version 3.0.0 (add5e7a)

第一行那个 376 毫秒是杀毒软件在扫新解压的 exe，后面两次 169 和 175 毫秒才是它自己的启动开销。

渲染一份 6687 字节的文档

文件里有 1 个一级标题和 30 个二级标题，正文是 60 条列表项、30 段引用与 30 个代码块。固定宽度 100 列，连跑三次是 214 / 199 / 196 毫秒。

十二倍的体积差在颜色码上

同一份 6687 字节的源文件，带色输出 349966 字节，不带色 28591 字节。多出来的 321375 字节全是转义序列，平均到每个字符要配十几个字节的样式指令。

# 源文件 6687 字节
# 带色：349966 字节
glow -s dark -w 100 demo.md
# 不带色：28591 字节
glow -s notty -w 100 demo.md

宽度参数决定折行位置

-w 100 是按 100 列折行。终端实际宽度 96 列时设 92 更稳，留出边框位置；设 0 就不折行，长段落会一行顶到底，需要横向滚动。

不带 -w 时它读终端宽度。同一份文件在 104 列和 80 列窗口里渲染，折行位置完全不同，这一点在管道重定向时尤其明显。

样式开关就在一个参数上

-s 后面跟样式名，dark 是深色终端的默认档，notty 关掉全部颜色只留缩进和对齐。实测这两个值之外的样式名要自己写 JSON。

管道里默认不上色

输出到文件或者管道时，auto 会走无样式分支，体积掉到 28591 字节这一档。要往文件里灌带色内容必须显式写 -s dark。

写进文件的转义序列在文本编辑器里是乱码，在终端里 cat 出来才是彩色。存归档用 notty，截图用 dark，两个用途别混。

中文要跑在 65001 代码页下

渲染中文文档前先执行 chcp 65001。实测在 65001 下标题与正文里的中文都正常，代码块也没掉字，一份 471 字节的示例文件排出来标题有底色、表格有分栏。

示例文件里能看出四件事

那份 471 字节的测试文档渲染后：一级标题带整行底色，行内代码有浅色背景，引用块左边一条竖线，表格画出横线与分栏。这几样就是它和纯文本输出最直观的差别。

没有配置文件

解压目录 7 个文件里没有 .toml 或 .yaml，样式和宽度全靠命令行参数。想固定默认值只能写别名或者包一层 bat，它不读用户目录里的配置。

三个真会踩的地方

代码页不对就是一堆方块

cmd 默认代码页下渲染中文文档，汉字位置会出现方块和问号。先 chcp 65001 再跑，同一份文件立刻正常。

宽度设大了会横向溢出

窗口 80 列时设 -w 100，每行都要横向滚动才能看全。按窗口列数减 8 设比较稳，80 列的窗口用 72。

重定向以后颜色变成乱码

glow demo.md > out.txt 出来的文件里如果带 ^[[ 这样的字符，说明样式没关。加 -s notty 再来一次，输出掉到 28591 字节这一档就干净了。

同一份文件和 type 的差别

把 6687 字节的 demo.md 用三种方式过一遍，都在同一个 cmd 外壳里计时，三次取中位。type 是系统自带，另外两条是 glow 的两种样式。

208 毫秒买的是 21904 字节的排版

type 原样输出 6687 字节，glow 关掉样式后是 28591 字节，多出来的 21904 字节是缩进和表格对齐补的空格。对着一段 30 小节的文档，这些空格决定了三级标题能不能一眼分清。

带色比不带色反而快一点

三次测下来带色 401 / 349 / 321 毫秒，不带色 445 / 342 / 309 毫秒，中位分别是 349 和 342 毫秒，差 7 毫秒。这个差值落在误差范围里，说明着色本身几乎不花时间，前面那 321375 字节的体积差只是传输成本。

读文件本身是 1 毫秒

同一份文件用 Python 读一遍是 1 / 0 / 0 毫秒。剩下三百多毫秒全在解析 markdown、算列宽和起进程上，磁盘不是瓶颈。

宽度设大了不是免费的

同一份 6687 字节的文档，关掉样式后在四个宽度下各渲染一次。行数一直是 275 行，字节数跟着宽度线性涨。

每加一列多 273 字节

60 列 17671 字节，120 列 34051 字节，差值 16380 字节摊到 60 列是每列 273 字节。275 行每行都补齐到同一宽度，所以字节数跟列数成正比，跟内容多少无关。

行数不变说明它是在补空格

四个宽度下都是 275 行，没有一次重新折行。这段测试文本每行本来就短，宽度只影响右侧补多少空格——而补出来的空格在代码块和引用块里要画满底色，这才是它必须补齐的原因。

换个长段落多的文档，折行会真的发生，行数就不再是 275。想量自己那份文件的折行行为，把 -w 换几个值各跑一次，对比行数就行。

什么场景值得上

写 README 和写笔记的人最合适。改完一段就想看排版，命令行一行比切窗口快；6687 字节的文档渲染 196 毫秒，比手动滚动找格式问题省事。

反过来，一天只读一个文件的人没必要装。系统自带的 type 加上合适的缩进已经够看，多一个 19396096 字节的 exe 换不来多少。