带图 Markdown 单文件打包实验室

把一份带 3 张截图的文档，现场打成 ZIP、base64 内嵌、自包含 HTML 三种「单文件」，对比真实体积和你真正在乎的属性。结论可能和你想的相反。

先别急着下结论

「单文件自包含 Markdown 标准」
其实早就有，只是没一个赢下来

下面这份样例文档有正文 + 3 张真实截图。点一下，看它分别打成三种单文件后有多大、丢了什么。

选一个 .md 文件 + 它引用的图片（图片文件名要和 ![]( ) 里写的一致）。文件不上传，全部在你浏览器里处理。

选 .md 选图片（可多选）

左边是渲染效果，右边是源码。注意源码里图片只是一行 ![](文件名)——所以单独发 .md 文件，对方看到的是裂图。

渲染效果

Markdown 源码

体积是现场算出来的真实字节数（真实 PNG、真实 base64、真实 ZIP 字节流）。每张卡片都能直接下载，对方拿到就能用。

把常见格式摆在一起看。✓ 支持 △ 部分/有条件 ✗ 不支持。没有任何一种格式能同时占满「单文件 + 可 diff + 可文本编辑 + 双击即看」。

Markdown 的全部价值在于它是纯文本：能 git diff、能 grep、任何编辑器都能改。塞进 ZIP 或 base64，这些立刻全废。自包含和纯文本天生打架。

Markdown 没有统一标准机构，CommonMark、GFM 各管一摊。DOCX 背后是微软 + ISO，JAR 背后是 Sun/Oracle，单一推手才能形成网络效应。Markdown 没有。

创作态用纯文本 .md + assets（保留 diff 和可编辑），分发态渲染成自包含 HTML 或 PDF。你要的「单文件」其实就是 pandoc --embed-resources 出来的那个 HTML，它一直都在。

base64 内嵌让文件膨胀约 33%（3 字节编码成 4 个字符，数学上跑不掉），还杀死了纯文本属性；ZIP 体积最小却要先解压；自包含 HTML 双击即看却不再是 Markdown。三个方向各有取舍，谁也没法既当源格式又当分发格式——这才是「没有统一标准」的真正原因。