1. 先说清楚：那套“序列号 + 文件替换”我没打算展开
三年前我换主力机的时候，把旧电脑上用了两年的 Typora 配置整个搬丢过一回。主题、自定义 CSS、图片相对路径规则、导出模板，全没了。当时第一反应不是重装，而是去网上翻“序列号”“激活文件替换”这类关键词——毕竟那会儿手头紧，能省一点是一点。翻了几个帖子、试了两三种流传很广的做法之后，我最后选择老老实实付费。不是因为道德感突然上线，而是那些野路子在实际使用中给我造成的麻烦，远远超过了省下来的那点钱。这篇文章就是把这个判断的完整过程摊开讲：为什么绕开授权的路走不通，正版到底该怎么买、值不值，不想花钱又有哪些真正能用的免费替代，以及“文件替换”这件事在合法范围内到底该怎么干——替换主题、替换 CSS、替换配置，这些才是 Markdown 写作者日常真正高频的操作。
我先明确一下本文的边界，免得你读到最后觉得跑题。标题里那种“找一个能过的序列号”“下载一个文件覆盖掉原程序”的做法，我不会给出任何具体步骤、链接或者可执行的文件名。原因很实在：这类操作改的是程序内部的授权判断逻辑，属于绕过软件授权机制，本身不合规；更要紧的是，散落在各种论坛和网盘里的“激活文件”是彻头彻尾的黑盒二进制，它在你机器上做什么，你没有任何办法验证。写作这件事最怕的就是机器环境不稳定，文档丢一次，损失远超软件本身的价钱。所以下面聊的“文件替换”，我会把它落回到几个安全的落点：主题文件、样式表、配置文件、导出模板——这些替换完你随时能回滚，出问题也不会损坏你的正文内容。
1.1 那些流传的激活手段，本质上在做什么
要把这件事想明白，得先知道商业软件是怎么判断“这个人买没买”的。绝大多数桌面软件走的是两条校验链路：一条在服务器端，激活时联网核对你输入的凭证；另一条在本地，把激活结果写成一个凭证文件或者注册表项，之后每次启动读它。买断制软件通常只在激活那一次联网，后续长期靠本地凭证——这个设计本身是为了让用户在没网的环境下也能正常用，但也正是它给了各种“替换法”可乘之机：既然判断发生在本地，那把本地的判断结果改成“通过”，程序自然就放行了。
流传的做法大致三类。第一类是伪造凭证，往配置目录里塞一份格式看起来对的授权信息，赌程序不做严格校验；第二类是替换核心可执行文件或者动态库，直接换掉那个负责判断的模块；第三类是拦住本地校验请求，让它永远返回成功。三类做法的共同点是，它们都在和程序的完整性校验赛跑。而正规软件几乎都会做完整性保护：文件哈希比对、代码签名验证、版本更新时覆盖核心文件。这就决定了一件事——每一次官方发新版，你都得重新走一遍流程，而且新版本的保护往往更严。
我把这套东西的脆弱性总结成一张表，你对照着看就明白为什么它不划算：
| 环节 | 野路子会遇到什么 | 后果 |
|---|---|---|
| 安装与首次运行 | 来源不明的可执行文件需要授予较高权限 | 机器环境不可控，风险落在自己身上 |
| 日常启动 | 部分方案需要常驻后台进程或修改系统配置 | 与其他软件冲突、开机变慢 |
| 版本更新 | 更新会覆盖被替换的文件 | 更新即失效，得重新折腾一遍 |
| 出问题时 | 官方渠道无法提供支持 | 只能自己摸索，文档安全没有兜底 |
| 长期使用 | 凭证伪造方式随版本演进而失效 | 隔一段时间就要重复投入时间 |
真正让我放弃的其实是最后一行的隐性成本。那段时间我算过一笔账：每次大版本更新后，我大概要花二十分钟到一小时重新找方案、试错、验证。一年更新几次，加上偶尔的兼容性折腾，累计时间足够我写完小半个项目文档了。时间才是写作者最贵的成本，这一点在学生时代很难意识到，工作之后体会特别深。
1.2 一次授权异常引发的连锁反应
我见过一个挺典型的场景，是某位开发者朋友的真实经历，细节我做了模糊处理。他用的是非正规方式装的环境，某天赶一份技术方案，写到凌晨两点，顺手点了软件提示的升级。升级完成后，程序启动正常，但他打开文档发现排版全变了——自定义主题被新版默认样式覆盖，代码块的行高和字号回到出厂状态，图片路径设置被重置成了绝对路径。最要命的是，他之前设置的“插入图片时自动复制到相对目录”这个选项失效了，后续插入的十几张截图全部指向了本地临时目录。等他把文档发给同事，对方打开全是红叉。
这个链条里最关键的一环不是软件坏了，而是他在出问题的时候没有任何求助渠道。正版用户遇到这种情况，可以去官方论坛翻 issue、可以发邮件、可以回滚到上一个稳定版本，官方至少会告诉你“这是已知问题，下个版本修复”。野路子用户只能自己啃。写作工具和别的软件不太一样，它承载的是你几个月甚至几年的沉淀，稳定性权重应该排在功能丰富度前面。我现在的判断标准很粗暴：一个工具如果我每天要打开它超过三次，那我就愿意为它的稳定性付钱；一个月用不到两次的，用免费方案完全够了。这个标准放在任何软件上都成立。
2. 把账算明白：正版授权到底值不值这个价
先把 Typora 的授权模式说清楚，因为很多人对它的印象还停留在“要订阅”上。它走的是买断制，一次付费、长期使用，官方条款里允许在有限数量的设备上激活（我印象中是三台，购买前建议再核对一下当期条款，这类细节官方会调整）。这个模式和订阅制的差别很大：订阅制是你每年都要掏钱，买断制是你掏一次然后一直用，代价是大版本升级可能需要重新付费——不过对 Markdown 编辑器这种功能相对稳定的品类来说，大版本之间的差异没有生产力工具那么剧烈。
价格层面，它在百元以内这个区间，大致相当于两杯咖啡到一顿简餐。我不想给你算“每天只要几毛钱”这种账，那种算法是营销话术。更有意义的算法是：把它和你单位时间的产出对标。如果你靠写文档、写方案、写稿子吃饭，一天里有两小时在这上面，那这个工具的年度成本占你收入的比例低到可以忽略。反过来，如果你一年只写四五篇笔记，那这笔钱确实可以不花，第 3 节里的免费方案足够覆盖你的需求。
2.1 授权模式拆解与人群对照
买断制最容易让人犹豫的点是“我到底需不需要为它付钱”，因为它不像订阅制那样有强制提醒。我做了一张对照表，按使用强度来分，比按职业分更准：
| 使用场景 | 日均使用时长 | 我的建议 | 理由 |
|---|---|---|---|
| 靠文档输出为主要工作内容 | 2 小时以上 | 直接买 | 稳定性收益远超成本，工具出错你损失的是交付 |
| 学生、科研写作、论文 | 1 小时左右 | 建议买，可先确认是否有教育优惠 | 长文档写作对排版一致性和导出质量要求高 |
| 偶尔写笔记、博客草稿 | 每周几次 | 先试用，试用期结束后看需求 | 需求不稳定时，免费方案性价比更高 |
| 团队协作、内容需要多人编辑 | 不定 | 先看团队协作方案 | 桌面单机工具不适合多人协同场景 |
| 已重度使用代码编辑器 | 不定 | 可以用编辑器插件替代 | 减少工具切换成本，第 3 节有对比 |
还有一个容易忽略的点：商业环境使用和个人的授权条款可能不一样。如果你在公司电脑上装、用来写公司文档，严格来说应该走商业授权。这件事很多人不知道，我也不打算展开讲条款细节，只提醒一句：入职新公司装工具前，问一下 IT 或行政有没有统一的采购渠道，多数规模稍大的公司是有软件资产管理的，走公司渠道既合规又不用自己掏钱。
2.2 三种先别急着付钱的情况
第一种，你其实根本不需要这么重的编辑器。Markdown 的核心价值是纯文本、可版本管理、跨平台。如果你平时就是记几条待办、写几段随笔，一个带预览的轻量编辑器完全够用，甚至直接用支持 Markdown 的笔记软件就行。重编辑器带来的实时渲染、大纲面板、数学公式、表格编辑这些能力，对短文本是过剩的。
第二种，你已经在用某款代码编辑器作为主力。代码编辑器加两三个插件之后，Markdown 写作体验能做到 Typora 的七八成，剩下那两三成差距主要体现在“所见即所得”的流畅度上。如果你本来就整天泡在编辑器里，为了写文档再开一个软件，切换成本反而更高。我自己有一段时间就是这样，所有笔记都在编辑器里写，好处是所有东西在一个窗口里，坏处是写长文时的沉浸感确实差一些。
第三种，你的文档需要在多端实时协同。桌面单机工具的协作能力天生弱于在线文档。如果团队里五六个人要同时改一份文档、要留评论、要看到彼此的光标，那不管桌面工具多好用，都得让位给协同方案。这不是工具好坏的问题，是形态不匹配。
3. 不花钱的替代方案：五款编辑器摆在一起比
我把市面上主流的几类方案拉出来，按实际使用感受聊，不讲参数堆砌。需要说明的是，下面提到的工具都在持续迭代，具体功能以你安装时的版本为准，我这里给的是选型思路和踩过的坑，不是功能清单抄录。
3.1 我选工具只看四个硬指标
第一个指标是渲染形态：即时渲染还是源码与预览分栏。即时渲染就是边打字边看到最终效果，光标所在行会露出一点 Markdown 语法；分栏则是左边写右边看。前者沉浸感强，适合写散文、方案、讲稿；后者对结构的掌控更清晰，适合写长文档和需要精确控制格式的技术文档。这个选择没有优劣，取决于你的写作类型。
第二个指标是图片资产管理。这是所有从 Typora 迁移出来的人踩的第一个坑，也是我把它列为核心指标的原因。图片是 Markdown 文档里唯一没法用纯文本表达的东西，它必须落成一个文件路径。路径一旦变成绝对路径，文档就绑死在这台机器上，发给别人必然裂图。所以一个合格的写作工具必须支持“粘贴图片自动复制到指定目录 + 自动写入相对路径”这个能力。
第三个指标是导出能力。很多人只关心写，不关心出。但真实场景里，文档最终往往要变成 PDF 交付、变成 HTML 发出去、变成 Word 给别人改。导出链路的成熟度直接决定了你要不要额外折腾一遍排版。
第四个指标是数据存放形态。纯本地文件夹存.md文件，和把内容存进数据库，是完全两种性质的方案。前者意味着你随时可以用任何工具打开、可以用 Git 管理、可以整目录打包迁移；后者意味着你被工具绑定，导出是唯一出口。
3.2 横向对比与逐项判断
| 方案 | 渲染形态 | 图片管理 | 导出能力 | 数据形态 | 上手成本 |
|---|---|---|---|---|---|
| Typora | 即时渲染 | 强，可配置粘贴规则 | 强，PDF/HTML/Word 等 | 本地 md 文件 | 低 |
| 代码编辑器 + 插件 | 分栏预览为主 | 中，需装粘贴插件 | 中，依赖插件 | 本地 md 文件 | 中 |
| Obsidian 类笔记工具 | 即时渲染 + 双链 | 强，附件目录可配 | 中 | 本地 md 文件 | 中 |
| MarkText 类开源编辑器 | 即时渲染 | 中 | 中偏弱 | 本地 md 文件 | 低 |
| 在线文档 | 即时渲染 | 强，拖拽即可 | 中 | 云端存储 | 极低 |
逐项说。代码编辑器这条路我用了很久，优点是所有工作在一个窗口里完成，写完代码顺手写文档，不用切软件；缺点是它的预览是分栏的，而且默认不处理图片粘贴，得额外装插件。插件配置起来不难，但要记得把粘贴目录设成相对路径，否则你在别的机器上打开照样裂图。这条路的另一个隐性优点是 Git 集成天然顺滑，写完直接提交，版本记录清清楚楚。
Obsidian 这类以本地文件夹为核心的笔记工具，最大的优势是它默认就把你的内容当成一堆 md 文件对待，附件目录、相对路径这些都可以在设置里指定，而且它自带的搜索和关联能力对长期积累很友好。缺点是对“纯写作”这件事来说，功能有点多，界面需要花时间整理，第一次打开容易被侧边栏和一堆面板劝退。
MarkText 这类开源编辑器是形态上最接近的免费选择，打开就是一个干净窗口，即时渲染，没有多余面板。它的短板在细节打磨上，比如复杂表格的编辑手感、超长文档的滚动流畅度，以及导出选项没有商业软件那么全。如果你只是要一个干净的写作环境、格式不用太复杂，它完全够用。
在线文档就不用多说了，协作是它的主场，本地化是它的短板。你需要接受内容存在别人服务器上这个前提，同时要接受它导出成 md 时格式可能有细微偏差。
提示：不管选哪条路，第一步都别急着搬历史文档，先新建一个测试目录，写三篇带图片、带代码块、带表格的假文档，跑通再迁移。我吃过直接迁移的亏，两百多篇文档一次性搬过去，图片路径全错，修了一晚上。
4. 迁移实战：把写作习惯整套搬过去
选好工具之后真正的活才开始。迁移的难点不在内容，内容就是一堆 md 文件，复制过去就完事；难在那些围绕内容建立起来的“习惯配置”——图片怎么存、样式怎么调、快捷键怎么按。这三样任何一样没对齐，你写起来就会一直别扭。
4.1 图片路径是第一道坎
我先把图片这件事讲透，因为它是迁移过程中翻车率最高的环节。Markdown 里插入图片写的是，这个路径有两种写法：绝对路径和相对路径。绝对路径长这样：/Users/xxx/Documents/notes/assets/img01.png，它指向这台机器上的一个固定位置；相对路径长这样：./assets/img01.png，它指向“当前文档所在目录下的 assets 文件夹”。
绝对路径的问题是显而易见的：文档一旦离开这台机器，路径就失效了。所以正确的做法只有一种——相对路径加统一的附件目录。具体做法是，在文档所在目录下建一个assets文件夹，所有图片放进去，文档里统一写./assets/文件名。这样整个文件夹打包发给任何人，图片都能正常显示。
不同工具的配置位置不一样，但逻辑是共通的。你要找的选项通常叫“插入图片时”“图片保存位置”“附件目录”之类的名字，把它设成“复制到指定目录”加“使用相对路径”。代码编辑器这条路需要装一个粘贴图片的插件，装完之后在设置里指定保存目录为${currentFileDir}/assets，这样它就会按当前文件位置生成相对路径。
迁移已有文档时还有一个更省事的办法：把旧文档里的图片集中到一个assets目录，然后用批量替换把绝对路径前缀统一改掉。具体操作是在编辑器里打开全局搜索替换，搜索旧文档所在的绝对路径前缀，替换成./assets，注意先备份再操作。
# 迁移前先整体备份，这一步别省 cp -r ~/Documents/notes ~/Documents/notes_backup_$(date +%Y%m%d) # 统计一下有多少文档引用了绝对路径 grep -rl "/Users/" ~/Documents/notes --include="*.md" | wc -l最后一行命令能帮你快速判断工作量。如果只有十几篇，手动改都行；如果有几百篇，就必须批量处理。批量处理之后一定要随机抽十篇打开验证，尤其要抽那些引用了多张图片的长文档。
4.2 自定义主题与样式的搬运
Typora 的主题本质就是一个 CSS 文件。你要做的不是“破解”它，而是把它复制出来，然后在新的工具里做适配——这一步完全合法，因为你自己写的样式表属于你自己的东西。需要调整的地方主要是选择器：Typora 的正文容器 id 是#write，别的工具可能用.markdown-body、.markdown-preview-view之类的类名。你把原样式里的#write替换成目标工具对应的容器选择器，大部分排版规则就能直接生效。
我建议搬样式的时候只搬“真正影响阅读体验”的那几条：正文字体、字号、行高、段落间距、代码块背景、表格边框。不要整份照抄，因为原样式里往往有大量针对特定界面元素的微调，搬过去之后可能互相打架，调起来更费劲。我自己的习惯是维护一份极简的“阅读优先”样式，控制在五十行以内，换工具的时候只改容器选择器，五分钟搞定。
4.3 快捷键、公式与表格的手感对齐
快捷键这件事，影响比想象中大。我改工具最不适应的一周，全是肌肉记忆在打架：写链接的时候下意识按了旧快捷键，结果弹出来别的东西。我的做法是先把最高频的五个操作找出来，在目标工具里重新绑定，其余的先不管。哪五个？加粗、插入链接、插入代码块、切换源码视图、保存。这五个覆盖了写作时八成以上的格式操作。
公式这块，只要工具基于同一套渲染引擎，语法就完全通用，$...$行内、$$...$$块级，迁移时基本不用改。真正需要验证的是行内公式和中文混排时的间距，有些渲染器处理不好会出现公式和文字贴在一起的情况，这个只能在迁移后实际打开几篇看一下。
表格是最容易被低估的一项。Markdown 表格本身语法就笨重，|---|---|这种分隔行手写起来很痛苦。不同工具对表格的辅助能力差别很大，有的支持 Tab 键跳格、自动补全分隔行，有的只能手写。如果你的文档里表格特别多，迁移前务必拿一个十行的表格在两个工具里各编辑一遍，感受差异，这个体验差异会天天影响你。
5. 文件替换的正确打开方式：主题、样式与配置
这部分是我认为最值得花时间的地方。前面几节讲的是选型和迁移，这一节讲的是长期维护——一个用得顺手的编辑器，八成靠的是配置，而不是它自带的功能。而配置的维护，核心手段就是“可控的替换”。
5.1 先搞清楚目录结构再动手
任何桌面软件的配置都放在固定的用户数据目录里，找到它就是所有定制化操作的第一步。多数软件会在设置菜单里提供一个“打开主题文件夹”或者“打开配置目录”的入口，这是最省事的路径。
如果你要手动找，规律大致如下：Windows 下在用户目录的AppData\Roaming里找对应应用名；macOS 下在用户目录的Library/Application Support里找；Linux 下通常在~/.config里。进去之后你会看到themes（主题）、conf（配置）这类目录。
目录里通常有三种东西：官方自带的默认主题、你放进去的自定义主题、以及一份用户配置文件。动手之前，把整个目录复制一份放到旁边，命名成themes_backup_日期。这个动作只花三秒钟，但能救你一次。
5.2 一份可以直接抄的极简排版样式
下面这份样式我用了两年多，思路是只调阅读相关的，不碰界面元素。你可以直接存成my-theme.css放进主题目录，然后在设置里选中它。
/* 阅读优先：只调正文排版，不动界面 */ :root { --body-serif: "Source Han Serif SC", "Songti SC", serif; --body-sans: "Source Han Sans SC", "PingFang SC", sans-serif; --mono: "JetBrains Mono", "Cascadia Code", monospace; --content-width: 46rem; --line-height: 1.85; --accent: #2b6cb0; } /* 正文容器，换工具时只需要改这一行选择器 */ #write { max-width: var(--content-width); margin: 0 auto; font-family: var(--body-serif); font-size: 16px; line-height: var(--line-height); color: #24292e; } #write p { margin: 0 0 1.1em; text-align: justify; text-justify: inter-ideograph; } #write h1, #write h2, #write h3 { font-family: var(--body-sans); font-weight: 600; margin-top: 1.8em; margin-bottom: .6em; border-bottom: 1px solid #eaeaea; padding-bottom: .25em; } #write h2 { font-size: 1.45em; } #write h3 { font-size: 1.2em; border-bottom: none; } #write code { font-family: var(--mono); font-size: .92em; background: #f4f4f5; padding: .12em .35em; border-radius: 3px; } #write pre { background: #fafafa; border: 1px solid #eaeaea; border-radius: 6px; padding: 1em 1.1em; overflow-x: auto; line-height: 1.6; } #write pre code { background: transparent; padding: 0; } #write table { border-collapse: collapse; width: 100%; margin: 1.2em 0; font-size: .95em; } #write th, #write td { border: 1px solid #dfe2e5; padding: .5em .8em; text-align: left; } #write th { background: #f7f8fa; font-weight: 600; } #write blockquote { border-left: 3px solid #c8ccd1; color: #57606a; margin: 1.2em 0; padding: .2em 0 .2em 1em; } #write img { max-width: 100%; display: block; margin: 1em auto; }几个参数的选择理由说一下。字号 16px 是屏幕阅读的舒适区间下限，再小长文容易累眼；行高 1.85 是中文排版的常见取值，中文字面比拉丁字母饱满，行高太小会显得密不透风；正文宽度限制在 46 个字符宽度附近，是为了控制每行字数——一行超过四十个汉字，眼睛从行尾回到行首时容易串行。这几个数字不是拍脑袋的，是长期试出来的，但每个人的屏幕尺寸和视力不同，你可以以此为起点微调。
代码块和正文用不同的字体族，这个区分很重要。等宽字体让代码对齐、让缩进可读，混排的时候一眼就能分辨“这是代码不是正文”。
5.3 替换前的备份与回滚清单
我现在把所有配置目录的备份做成了固定动作，具体清单是这样：
- 替换任何文件之前，先整目录复制一份，命名带日期
- 在备忘录里记下当前软件版本号，出问题时能判断是不是版本差异导致的
- 一次只改一个文件、一个变量，改完立刻重启验证
- 验证的时候打开一篇最长、最复杂的文档看，不要用空白文档看效果
- 如果样式导致界面元素错位，先把新文件挪出去再说，别现场调试
回滚很简单：把备份目录里的文件复制回来，覆盖当前文件，重启软件。关键是别在出问题的时候还想着“我改改看能不能修好”——样式冲突的排查是无底洞，先回滚到可用状态，再考虑要不要重新调。
注意：从网上找来的第三方主题文件，本质是一段 CSS。CSS 本身不会执行代码，风险相对低，但仍然建议打开看一眼，确认它没有引用外部的远程资源，尤其是不明来源的字体和背景图链接。能用本地文件就别用远程链接。
6. 长文档写作的稳定性保障
写到第六节，得聊一个比工具选型更重要的话题：你的文档怎么才丢不了。我见过的内容丢失事故，绝大多数不是因为软件坏了，而是因为“只有一个副本”和“改错了没法退回”。
6.1 三层备份结构
我现在用的是三层结构，从近到远：第一层是本地 Git 仓库，负责“改错了能退回”；第二层是同步盘，负责“机器坏了文件还在”；第三层是定期冷备，负责“同步也被误删了还有救”。
Git 这一层是性价比最高的，因为它解决的是同步盘解决不了的问题：误删一段内容、误改一个格式，同步盘会忠实地把这些错误同步到所有设备，而 Git 里你随时能翻出上周的版本。给写作目录建仓库非常简单：
cd ~/Documents/notes git init printf '*.DS_Store\nThumbs.db\n.obsidian/workspace*\n' > .gitignore git add . git commit -m "init: 写作库初始化" # 之后每天收工提交一次 git add -A git commit -m "daily: $(date +%Y-%m-%d)".gitignore那行很重要。写作目录里往往混着系统生成的隐藏文件和工具的工作区缓存，这些提交进去会让仓库越来越臃肿，还会在换机器时带来干扰。图片要不要提交？如果你图片不多、总量在几百兆以内，提交进去最省心，克隆下来就是完整的一份。如果图片量很大（比如做设计文档、大量截图），建议图片走同步盘，Git 只管文本。
同步盘这一层没什么技术含量，选一个你常用的就行，把写作目录放进去，设置成自动同步。要注意的是别同时开两个同步工具盯同一个目录，容易产生冲突副本。
冷备这一层我做得比较糙：每月把整个目录压缩一份，扔到一块外接硬盘或者另一个不常用的存储位置。不追求自动化，追求的是“这份备份和前面两层物理隔离”。
6.2 版本管理的最小可行方案
很多人一听 Git 就头大，觉得要学一堆命令。其实写作场景只需要四个动作：初始化、看状态、提交、回退。我把它压成一张极简对照表：
| 你想干什么 | 命令 | 什么时候用 |
|---|---|---|
| 看哪些文件改了 | git status | 每次收工前 |
| 把改动记录下来 | git add -A && git commit -m "说明" | 每天至少一次 |
| 看历史提交 | git log --oneline | 想找某天的版本时 |
| 把某个文件退回上一版 | git checkout -- 文件名 | 改坏了想撤销 |
提交信息别写“update”，写清楚改了什么，比如“补充第 3 节表格”“重写开头”。一周之后你回头翻，能看懂才有用。
还有一个细节：文档改名和移动位置要单独提交一次。Git 通过内容相似度判断重命名，如果你一边改内容一边移动文件，它可能认不出来，历史就断了。这个坑我在整理目录结构的时候踩过，两百个文件移动之后历史全乱，后来只能按日期重建。
最后分享个小技巧，关于长文档写作的节奏。我现在写超过五千字的东西，会拆成多个文件：00-大纲.md、01-第一节.md、02-第二节.md，最后用一个汇总文件按顺序引用。这样做的好处是每个文件都很小，编辑器打开快、滚动流畅、出问题时损失范围有限；坏处是导出前要做一次合并。合并用命令行最省事：
# 按文件名顺序拼接，注意排除大纲本身 cat 01-*.md 02-*.md 03-*.md > 全文.md我个人在实际操作中的体会是，工具折腾到一定程度就该停了。我见过太多人把时间花在换主题、调字号、比较快捷键上，写了三个月笔记，内容不到五千字。真正决定你产出质量的从来不是编辑器，是你在那个窗口里敲下去的东西。选一个顺手的、能稳定跑几年的，把配置一次性调舒服，然后就把注意力还给内容本身。我那份五十行的样式表两年没大改过，中间只跟着系统升级调过一次字体回退链，这大概就是配置这件事该有的分量。
