内容会上传到服务器吗？
不会。整理源码、渲染预览、富文本转换和下载全部在浏览器本地通过 JavaScript 完成，页面没有后端接口，也不会把你粘贴的内容发送到任何服务器。适合处理还没发布的稿子和内部文档。页面加载完之后断开网络，工具照常可用，这是最直接的验证方法。
这个词容易被理解成两件事。一件是把 .md 渲染成排好版的样子看，那属于阅读，用MD 文件在线打开；另一件是把源码本身写规范，比如该空行的地方补上空行、该对齐的表格对齐。这一页做的是后者：进去是 Markdown，出来还是 Markdown，只是排整齐了。如果你的目的是把它交给别人看，需要的多半是Markdown 转 Word / PDF。
Markdown 有几个空白敏感的地方，写错了不会报错，只会悄悄渲染成别的东西。最常见的是列表紧贴在上一段文字下面没有空行，很多渲染器会把整个列表当成普通段落的续行，符号原样显示出来；标题的 # 后面漏了空格也是同类问题，在 GitHub 上不生效，在某些编辑器里却正常。这类毛病在源码里看着没问题，换个地方打开才发现版没了。补空行这一项修的就是它，属于「改对了」而不是「改好看了」。
中文和英文、数字紧挨着的时候加一个空格，是中文技术写作里通行的排版习惯，理由是汉字是方块字、拉丁字母不是，不留空隙时两边会挤在一起。工具按这个规则处理，同时把中文后面误用的半角逗号、句号、问号换成全角。有两个地方故意不动：代码块和行内代码里的内容一个字节都不改，否则 my_var_name 这种标识符会被改坏；中文.md 这样后面跟着字母的句点也不会被当成句号，只有真正处在句末的才转。英文文档把「中文排版」那两项关掉即可。
从这些地方复制内容时，剪贴板里除了纯文本还带着一份 HTML，标题、列表、表格、加粗这些结构都在里面。所以粘贴时把它转成 Markdown 是一次确定的转换，不是根据文字长相去猜。反过来，纯文本粘进来不会被自动加上 # 和 -：那种猜测经常猜错，而猜错的代价是你得再手工改回去。只想要纯文本的话按 Ctrl+Shift+V，或者把「粘贴」那一项的勾去掉。
整理源码是纯粹的文本处理，渲染预览也可以完全在浏览器里做，没有一步必须交给服务器。这不只是隐私上的好处：没有上传就没有文件大小限制、没有排队、没有次数限制，页面加载完之后断网照样能用。还没发布的稿子、内部文档、写了一半的技术方案，都不必先交给一个你不认识的服务器。
不会。整理源码、渲染预览、富文本转换和下载全部在浏览器本地通过 JavaScript 完成，页面没有后端接口，也不会把你粘贴的内容发送到任何服务器。适合处理还没发布的稿子和内部文档。页面加载完之后断开网络，工具照常可用，这是最直接的验证方法。
不会。用 ``` 或 ~~~ 围起来的代码块，以及用反引号包起来的行内代码，内容一个字节都不动 —— 不加空格、不改标点、不动缩进、不重排。这是硬约束，否则 my_var_name 会被当成斜体、a,b 里的逗号会被换成全角，代码就不能跑了。链接里的网址同理，只有链接的文字部分会被处理。
不能，这是有意不做的。从 Word、网页、飞书、语雀复制过来的内容剪贴板里带着 HTML，标题和列表是明确写在里面的，转成 Markdown 是确定的事；而一段纯文本里哪行是标题、哪几行是列表，只能靠长相去猜，猜错了你还得手工改回来，比自己敲 # 更费事。所以这一页只在检测到带格式的内容时才自动转换。
最常见的原因是列表紧贴在上一段文字下面，中间没有空行。GitHub 按 CommonMark 解析，这种写法会把列表当成上一段的续行，于是 - 原样显示出来。另一个常见原因是标题的 # 后面漏了空格。把内容粘进来点「格式化」，「标题、列表、代码块、表格前后补空行」和「标题统一用 # 写法」这两项就是修这个的。
不是规范要求，是中文技术写作里通行的排版习惯，多数中文技术文档、多数团队的写作规范都这么做。它不影响 Markdown 的解析，纯粹是阅读体验。如果你的项目不这么要求，或者文档本来就是英文的，把「中文排版」那两项的勾去掉即可，其余整理照常进行。
勾了「有序列表重新编号」就会改成 1. 2. 3.。全写 1. 是一种常见写法，渲染结果和依次编号完全一样，好处是中间插入一项时不用改后面所有的号。如果你就是想保留这种写法，把这一项关掉。另外要注意：中间只隔一个空行的两段有序列表，按 CommonMark 仍然算同一个列表，所以编号会连着往下走，不会从 1 重新开始 —— 想真正断开需要在中间插入一段文字或别的内容。
不会。Markdown 里行尾的两个空格表示强制换行，工具认得这个写法并保留下来；三个以上的会收成正好两个，而不是当成手滑一并删除。其余情况下的行尾空白才会被清掉。如果你更习惯用反斜杠换行，那种写法本来就不受影响。
可能会。对齐靠的是给单元格补空格，而中文字符在等宽字体里占两个字符宽 —— 工具按这个规则算，所以在 VS Code、Typora 这类等宽显示的地方是齐的。如果某个编辑器用非等宽字体显示源码，看起来就不齐。这只影响源码的观感，渲染出来的表格永远是对的，因为渲染只看竖线的位置，不看空格数量。
那一页是纯阅读器：拖进去直接看排好版的样子，不编辑、不导出，适合收到一份 README 想读一遍。这一页会改写你的源码，输出还是 Markdown。想看用MD 文件在线打开，想整理用这一页。
在这一页点「复制」，然后粘到Markdown 转 Word / PDF里导出，或者先「下载 .md」再把文件拖到那一页。分成两页是因为两件事的产物不一样：这一页给你 Markdown 源码，那一页给你能直接发给同事的 .docx 或 .pdf 文件。
表格支持，会按列宽对齐。任务列表（- [ ]）、删除线、脚注这些扩展语法会被原样保留，不会被破坏，只是没有针对它们的专门整理规则。预览用的是 GitHub 风格的解析器，所以表格和任务列表在右边能正常显示。
整理本身是纯文本处理，几万行也很快。可能变慢的是右边的实时预览 —— 它要为每个元素生成 DOM。如果文档特别大又觉得卡，可以先把关心的部分截出来处理。输入停止约 0.2 秒后才会重新渲染，正常打字不会每敲一个字就重排一次。