写了三年 Markdown，我最后把自己锁进了一个 200 行的 HTML 文件里。听起来很折腾，但这事真的不折腾。本地 Markdown 编辑器我用过 Typora、Obsidian、VS Code 加各种插件，也试过各种写作软件，最后发现每天打开次数最多的，居然是一个用浏览器打开的 html 文件。它没有安装包、不建索引、不写配置文件，双击之后立刻能写，左边输入 Markdown 语法，右边实时出预览，还能一键导出 PDF 和 HTML。这篇文章适合所有被“编辑器配置”折磨过的人，也适合刚接触 Markdown 语法、想搞懂网页制作基础的人。我会把为什么放弃桌面端、怎么用单文件替代、核心代码怎么实现、踩过哪些坑，一次性讲清楚。
1. 先说说我为什么对一个单文件解决方案上瘾
1.1 本地 Markdown 编辑器替我解决过什么问题，又带来了什么问题
最早我也是本地 Markdown 编辑器的忠实用户。Markdown 语法写起来干净，纯文本文件不怕格式崩，拿到任何设备上都能打开，这种“反脆弱”的感觉很吸引人。桌面编辑器能补上实时预览、文件树、标签系统、全文搜索，让我觉得写东西是一件有仪式感的事。
但用得越久，问题越明显。首先，几乎所有主流编辑器都在往“全家桶”方向走。Typora 收费之后，更新节奏和激活策略让人心累；Obsidian 的插件生态确实强大，可光是挑选和配置插件就能消耗掉一个下午，真正落笔的时间反而被压缩了。VS Code 装完一堆 Markdown 扩展后，功能是强了，但它本质上是个代码编辑器，界面、快捷键、自动补全的默认行为都在为写代码优化，而不是为写文章服务。
功能越多，选择越多，写作的阻力反而越大。我那时候常常陷入“先整理工作区再写作”的怪圈，切主题、调插件、改主题、同步配置，折腾完之后已经没有心思好好写了。后来我意识到，Markdown 的核心是让写作回归纯文本，那为什么编辑器本身不能更纯粹一点？
1.2 编辑器的“全家桶”陷阱：功能越多，写作越累
这不是否定功能，而是说工具要和场景匹配。短博客、草稿、临时笔记这种轻量写作，根本不需要一个带数据库、图谱、双链、插件市场的巨型工具。我试过把 Obsidian 当作“第二大脑”来经营，结果笔记越来越厚，图谱越来越密，但我真正回头读的次数少得可怜。大部分内容只是被收藏、被归档，而不是被消化、被输出。
后来我开始做减法。笔记管理交给专门的文件系统，写作场景只保留一个输入框和一个预览区。一个 HTML 文件的方案就是在这个背景下出现的：它不管理任何东西，只负责把 textarea 里的 Markdown 文本渲染成漂亮的 HTML。写完了，导出文件，关掉页面，没有任何残留状态。没有启动器、没有托盘图标、没有后台进程。
有时候工具“难用”，不是缺少功能，而是功能太密。写作需要的不是更多按钮，而是一个足够安静、足够直接的空间。HTML 文件天然具备这种克制，因为它没有权限常驻后台，也没有能力在你没打开它的时候搞事情。
1.3 “编译器”和“编辑器”的差别，决定了我怎么理解 Markdown
这里想澄清一个经常被搞混的概念：编译器和编辑器不是一回事。文本编辑器负责让你录入、修改文本，它本身不关心内容含义；编译器负责把源代码翻译成机器可执行的程序。Markdown 编辑器更像是一个“编辑器 + 解释器/渲染器”的组合：你输入 Markdown 语法文本，程序把它翻译成带样式的 HTML 标签，然后展示在预览区里。
理解这一点特别重要。当我意识到 Markdown 渲染本质上就是“文本 -> HTML 结构 -> 浏览器样式”时，我忽然明白，浏览器本身就是最好的 Markdown 渲染容器。既然我天天都用浏览器，为什么还要在电脑里多装一个软件，让它再包一层浏览器引擎去做同样的事？于是单 HTML 文件方案变得顺理成章：我打开一个网页文件，这个网页里既有输入区，也有解析逻辑，还有预览样式，所有事情在一个页面里闭环。
2. 200 行的 HTML 文件，凭什么能当编辑器用
2.1 核心结构：左边写，右边看
整个编辑器只有三大块：一个 textarea 作为输入区，一个 div 作为预览区，以及一段 JavaScript 把两者连接起来。
textarea 是最容易被低估的原生控件。它天然支持光标、选区、撤销重做、系统拼写检查、快捷键操作，这些能力是 contenteditable 方案很难稳定复刻的。很多人想自己实现一个“所见即所得”编辑器，结果掉进 contenteditable 的深坑：光标位置漂移、粘贴样式混乱、不同浏览器行为不一致。而 textarea 把这一切都交给内核处理，稳定得让人感动。
预览区就是一个 div，JavaScript 每拿到一段新的 Markdown 文本，就把它解析成 HTML 字符串，然后塞进这个 div 的 innerHTML 里。用 CSS 控制排版：字体、行高、内边距、代码块配色、表格边框，全都自己说了算。这种“左写右看”的结构，和很多桌面 Markdown 编辑器几乎一模一样，但它的本质只是一个网页，不依赖任何框架和构建工具。
布局上我用的是 CSS Grid，一行代码就能实现左右分栏：
main { display: grid; grid-template-columns: 1fr 1fr; height: calc(100% - 44px); }左侧 textarea 设置resize: none和outline: none，右侧预览区设置overflow: auto。窗口缩小时自动出现滚动条，窗口放大时两边均分空间，比任何桌面软件都听话。
2.2 Markdown 转 HTML 的原理，没那么玄
Markdown 能流行，是因为它发明了一套“用纯文本表达文档结构”的约定。写# 标题就相当于 HTML 里的<h1>，写- 列表项就相当于<ul><li>，写 `code` 就相当于<code>。这个翻译过程可以用一个函数完成：输入字符串，输出 HTML 字符串。
我没有重新发明轮子，直接用了一个成熟的解析库：marked。它能把 GFM（GitHub Flavored Markdown）标准语法解析成 HTML，支持表格、删除线、任务列表、代码块等扩展功能。核心调用只有一行：
preview.innerHTML = marked.parse(input.value);marked 的处理流程大致是：先做词法分析，把字符串切成一个个 token（比如“这是一个标题”“这是一段代码”），再做语法分析，把 token 组装成 DOM 结构，最后序列化成 HTML 字符串。这些底层逻辑很复杂，但使用者只需要知道输入输出就行。
为什么强调“200 行”却不自己写解析器？因为真正值得自己写的不是 Markdown 语法解析，而是编辑器的工作流。解析器是成熟的基础设施，重复造轮子既容易出错，也浪费时间。我的业务逻辑主要围绕输入、防抖、自动保存、导出文件展开，这部分完全可控，加起来大概 200 行。
2.3 为什么敢说只有 200 行：把第三方库也塞进这一个文件
很多人听到“200 行的 HTML 文件”第一反应是：不可能，光 Markdown 解析器就不止 200 行。这里有个容易误解的点：我说的是我自己写的业务代码大概 200 行，没有算压缩后的第三方库去重后的体积。marked.min.js 虽然内容很多，但压缩后只有一行。
所以实际文件结构是这样：我在 HTML 文件的<head>或<script>区域里，把 marked.min.js 的压缩版内容直接复制进来，滚动起来很长，但行数只有一行。浏览器解析 JS 时不会因为它是一行就区别对待，照样能正常执行。这样整个文件依然只有一个 .html 文件，双击就能用，不需要联网加载 CDN，不需要本地安装 npm 包，也不需要启动一个本地服务器。
如果你不想把这个库内联进去，也可以引入 CDN 地址：
<script src="https://cdn.jsdelivr.net/npm/marked@12.0.2/marked.min.js"></script>但 CDN 方案换来的是对网络的依赖，一旦离线，编辑器就只剩一个不会渲染的 textarea。我个人的建议是：第一次使用时把 marked.min.js 的内容保存到本地，再用一行的<script>...</script>内联进 HTML。这样文件仍然单文件、离线可用、在任何电脑上打开都长一样。
3. 自己动手写一个：从零复刻我的 Markdown 工作台
3.1 打开记事本，先搭 HTML 骨架和 CSS 布局
环境要求低到不可思议：一个文本编辑器加一个浏览器。Windows 上可以用记事本，macOS 上可以用文本编辑，甚至直接在 IDE 里新建一个 .html 文件。不需要安装 Node.js，不需要运行命令，不需要 package.json。
先写页面骨架：
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Markdown 工作台</title> <style> * { box-sizing: border-box; } html, body { height: 100%; margin: 0; } body { font-family: system-ui, "PingFang SC", "Microsoft YaHei", sans-serif; } main { display: grid; grid-template-columns: 1fr 1fr; height: calc(100% - 44px); } textarea { width: 100%; height: 100%; border: 0; outline: none; resize: none; padding: 20px; font-family: ui-monospace, Consolas, "Courier New", monospace; font-size: 14px; line-height: 1.8; background: #fafafa; color: #333; } #preview { padding: 24px 32px; overflow: auto; background: #ffffff; line-height: 1.8; max-width: none; } header { height: 44px; display: flex; align-items: center; gap: 8px; padding: 0 12px; background: #f0f0f0; border-bottom: 1px solid #ddd; } header button { padding: 4px 12px; border: 1px solid #ccc; background: #fff; border-radius: 4px; cursor: pointer; } </style> </head> <body> <header> <button id="btn-dark">暗色模式</button> <button id="btn-export-md">导出 Markdown</button> <button id="btn-export-html">导出 HTML</button> <button id="btn-print">打印 / PDF</button> </header> <main> <textarea id="input" placeholder="在这里输入 Markdown 内容..."></textarea> <div id="preview"></div> </main> <script> // 核心逻辑写在这里 </script> </body> </html>这段结构里最值得注意的一点是<meta charset="UTF-8">必须放在 head 最前面。如果把它漏了，中文内容可能出现乱码。另一个小技巧是box-sizing: border-box全局设置，可以避免 width、padding、border 三者相加超出容器宽度的问题。
3.2 核心更新逻辑：输入、解析、渲染，一个函数搞定
把 marked 库内联好后，在<script>标签里写核心逻辑：
const input = document.getElementById('input'); const preview = document.getElementById('preview'); function render() { const raw = input.value; preview.innerHTML = marked.parse(raw, { gfm: true, breaks: true }); } let timer; input.addEventListener('input', () => { clearTimeout(timer); timer = setTimeout(render, 200); }); render();我打开过很多人写的类似脚本，最常见的错误是每次input事件都立刻执行render()。如果文章很长，或解析库处理不够快，会出现明显卡顿。所以我在中间加了一层 200 毫秒的防抖：用户连续输入时，只有停顿超过 200 毫秒才真正触发渲染。体感上几乎无延迟，但性能大幅提升。
gfm: true开启 GitHub 风格，支持表格、任务列表、删除线等扩展语法；breaks: true让单个换行也变成<br>，更符合中文用户“回车即换行”的习惯。这两个参数是影响日常写作体验最明显的开关，很多人觉得某些编辑器换行逻辑奇怪，往往是这里没配置好。
3.3 把“本地应用”该有的功能补上：自动保存、导出、打印、暗色模式
一个只有输入和预览的页面，还不算一个合格的写作工具。我补了几个经常会用到的能力。
自动保存用 localStorage：
const KEY = 'md-draft'; input.addEventListener('input', () => { localStorage.setItem(KEY, input.value); }); window.addEventListener('load', () => { const saved = localStorage.getItem(KEY); if (saved) { input.value = saved; render(); } });这个方案可以在意外关闭页面后找回内容。但要注意，浏览器对file://协议下的 localStorage 支持并不完全可靠，所以它只能当作“意外保险”，不能替代导出备份。
导出 Markdown 用的是Blob加a.download：
function download(filename, content, type) { const blob = new Blob([content], { type }); const a = document.createElement('a'); a.href = URL.createObjectURL(blob); a.download = filename; a.click(); URL.revokeObjectURL(a.href); } document.getElementById('btn-export-md').addEventListener('click', () => { download('note.md', input.value, 'text/markdown'); });导出 HTML 的思路是把预览区的 innerHTML 放进一个完整 HTML 模板里，再把模板字符串下载下来：
document.getElementById('btn-export-html').addEventListener('click', () => { const full = `<!DOCTYPE html> <html lang="zh-CN"> <head><meta charset="UTF-8"><title>export</title> <style>${document.querySelector('style').textContent}</style> </head> <body>${preview.innerHTML}</body> </html>`; download('note.html', full, 'text/html'); });打印功能更简单，直接调用window.print()。结合浏览器的“另存为 PDF”，就是免费的 PDF 导出通道。为了让打印效果好看，我会在 CSS 里加一段@media print：
@media print { textarea, header { display: none !important; } main { display: block; } #preview { overflow: visible; } }这样打印预览时只输出文章内容，干净利落。
3.4 细节决定体验：同步滚动、暗色模式、默认内容
虽然不是必需，但同步滚动是让我放弃桌面编辑器的关键体验之一。实现并不复杂：
preview.addEventListener('scroll', () => { const p = preview.scrollTop / (preview.scrollHeight - preview.clientHeight); input.scrollTop = p * (input.scrollHeight - input.clientHeight); });反过来左侧滚动时也能同步右侧。因为两个区域内容量接近，直接用比例映射即可。多试几次，误差很小，完全够用。
暗色模式我用了一个按钮 + 一个 CSS class 实现：
document.getElementById('btn-dark').addEventListener('click', () => { document.body.classList.toggle('dark'); });然后在 CSS 里写暗色变量。比如：
body.dark textarea { background: #1e1e1e; color: #ddd; } body.dark #preview { background: #252525; color: #ddd; } body.dark header { background: #333; }如果你想让页面默认跟随系统主题，也可以用prefers-color-scheme: dark。不过手动切换按钮更直观，用户体验更好。
4. 我用的时候踩过的坑，以及排查技巧
4.1 文件全是乱码，问题往往不是你写错了
我第一次把这个 HTML 文件发给其他人时，对方反馈打开后中文是乱码。后来发现不是我内容的问题，而是原本用记事本保存时，默认编码不是 UTF-8，或者文件被某些编辑器保存成了 GB2312。
排查顺序一般是三处：一是head里的<meta charset="UTF-8">是否在title之前；二是保存文件时是否选择了 UTF-8 编码；三是如果 HTML 里引入过外部 CSS/JS，它们的编码也要是 UTF-8。最保险的办法是直接用 VS Code 或 Notepad++ 这类现代编辑器打开 HTML，右下角选择 UTF-8 保存，然后重新打开。
4.2 图片在本地打不开，是浏览器安全边界在起作用
在浏览器里通过file://协议打开本地 HTML，图片引用如果写的是相对路径，通常能显示。但我遇到过一种情况：文章里的图片放在了 C 盘某个深层目录，HTML 文件在另一个盘，使用绝对路径时浏览器直接拒绝加载，因为跨目录访问被当成潜在风险。
解决方式有三种：把图片复制到 HTML 同目录下，用相对路径引用；把图片转成 base64 内嵌到 Markdown 里；或者给整个文件夹起一个静态服务。最省事的是第一和第三种。我后来在自己的工作台里加了一个“导入图片”按钮，用 FileReader 把图片转成 base64 塞进 textarea，这样导出的 md 文件虽然体积大一点，但图片不会丢。
4.3 粘贴内容后页面卡顿或直接白屏，八成是解析问题
某一次我从网页上复制了一大段带嵌入内容、样式标签的文字，粘贴进 textarea 后页面明显变慢。原因是这段文本里包含异常字符或超大代码块，导致 marked 解析时消耗了大量 CPU。
针对这种情况，我只做了两个优化：一是防抖时间从 200 毫秒拉长到 500 毫秒，让粘贴后的整体解析只触发一次；二是限制预览区一次渲染的最大长度，超过一定字数就只渲染前 10 万个字符，并给出一行提示：“内容过长，预览已截断”。对于纯笔记和博客草稿，10 万字完全够用。
如果你遇到页面直接白屏，打开开发者工具查看 Console，最常见的是 marked.parse 不是函数。这个错误基本是 marked 库没有加载成功。检查一下是不是把marked.min.js复制成了空文件，或者 CDN 地址写错了。
4.4 直接把预览 innerHTML 有风险，安全问题不是小事
这里必须强调：把用户输入直接塞进innerHTML，如果内容里包含<script>或者onerror属性，浏览器会尝试执行。虽然大多数情况下你只是自己写笔记，不会故意投毒自己，但从网页复制粘贴的内容，谁也保不准带什么异常标签。
一个简单做法是先转义，再让 marked 处理。可以用一个escapeHtml函数把<、>、&全部转成实体符，但这会影响代码块的展示。更稳妥的方式是引入 DOMPurify 做消毒：
preview.innerHTML = DOMPurify.sanitize(marked.parse(raw));DOMPurify 也是一个压缩后只有一行的库，完全可以像 marked 一样内联进 HTML 文件。付出几 KB 体积，换来踏实的安全性，这笔买卖值得做。
5. 什么东西不适合用这个方案
5.1 别拿它替换 Obsidian、Notion 这类知识库工具
我的 HTML 文件虽然好用，但它没有任何知识管理能力。没有标签系统、没有双链、没有搜索索引、没有关系图谱、没有历史版本。如果你把 Obsidian 当作“第二大脑”，在里面建了几百篇笔记，并且依赖双向链接串联知识网络，那就老老实实继续用 Obsidian，不要被一个 200 行的玩具蛊惑。
工具选择的核心是匹配需求。知识管理需要“连接”，写作需要“专注”。HTML 文件只解决专注，不负责连接。硬用它管理大量笔记，等于用一支钢笔去开挖掘机，方向就错了。
5.2 它真正擅长的地方：临时笔记、博客草稿、纯文本迁移
但我依然强烈推荐它，因为有一堆场景它做得比任何大软件都好。
临时笔记：开会、电话、灵感突发时，双击打开 HTML，写完直接导出，不用新建笔记本，不用选择分类。
博客草稿：很多静态博客系统的源文件就是 Markdown，用这个编辑器写稿子，保存成 .md 后放入博客目录，样式和最终网页高度接近，所见即所得。
给同事发一个“md 阅读器”：很多非技术人员收到 .md 文件不知道用什么打开。如果你把写好的内容放进这个 HTML 文件里导出成 HTML，发送给对方，任何人用浏览器都能直接阅读，排版还很好看。这本质上是用 HTML 充当一个跨平台的 Markdown 阅读器。
我还给文件加了一个导入 .md 文件的功能。点击按钮选择本地 Markdown，FileReader 读取内容后塞进 textarea，相当于给这个单文件应用扩展了“打开文件”的能力：
const fileInput = document.getElementById('file-input'); fileInput.addEventListener('change', (e) => { const file = e.target.files[0]; if (!file) return; const reader = new FileReader(); reader.onload = (ev) => { input.value = ev.target.result; render(); }; reader.readAsText(file); });配合一个隐藏的<input type="file" accept=".md,.markdown,.txt">，这个 HTML 文件就从“纯编辑器”变成了“md 查看器 + 编辑器 + 导出器”的三合一工具。
我自己现在的工作流是：桌面放着一个md.html，所有短文、草稿、临时想法都在里面完成。写完导出 .md 归档，或者直接复制预览内容去发博客。偶尔遇到同事问我某个 .md 文件怎么打开，我也顺手把这个 HTML 文件发过去，对方双击就能看，什么问题都解决了。
这个小工具教会我一件很重要的事：好的工具不是功能越多越好，而是让创作路径上的阻力越小越好。当你不再需要花时间管理编辑器本身，你才有更多时间管理自己的文字和想法。如果你也在被各种 Markdown 编辑器配置折腾到头大，不妨试试用浏览器打开一个属于自己的单 HTML 文件，动手改上几十行，就是最适合你的写作工作台。
