NAS笔记迁移实战：私有格式转Markdown完整指南

说实话，我最初写这些 NAS 笔记的时候，完全没想过有朝一日会为“迁移”这件事焦虑一整个周末。事情发生得很突然：登录 NAS 后台准备做例行维护，结果瞥见存储池状态那一栏显示异常警告。虽然最后确认只是某个硬盘的 SMART 自检触发了提醒，虚惊一场，但我盯着那个警告标记看了很久，脑子里只有一个念头——如果这块硬盘真的在明天凌晨挂掉，我那些写了三年的笔记，能救回来多少？答案很不体面：几乎救不回来。

笔记数据锁在私有格式里，平时用着没什么感知，可一旦你意识到“这个存储格式只有这个软件能读懂”，那种不安全感就会在心里扎下根来。我后来花了两周时间，走完了一条从私有格式到纯 Markdown 的完整迁移路线。这篇博客把整个过程拆开来讲，包括为什么是 Markdown、迁移前如何盘点数据、如何从 NAS 笔记导出并清洗成标准 Markdown、图片和内部链接怎么处理，以及迁移后的目录组织与备份策略。我尽量写得细一点，因为我踩坑踩得足够多，很多细节是文档里查不到的。

1. 为什么最终选定 Markdown：格式性质与长期可用性

先聊一个基础但关键的问题：Markdown 到底是什么？它其实既不是编程语言，也不是什么高科技协议，它只是一套极简的纯文本标记约定。用 # 表示标题，用 - 表示列表，用 ![](链接) 表示图片，仅此而已。这套约定最大的优势是：它不依赖任何特定厂商、特定软件、特定数据库。任何能打开纯文本文件的设备——Windows 记事本、手机上的任意编辑器、Linux 终端，甚至路由器里那个 busybox 环境——都能读取 Markdown 文件的原始内容。

这个特性对我这种把笔记当资产的人来说，是决定性的。我在 NAS 上用的笔记套件，内部数据存储在一个私有数据库里，数据文件既不能直接预览，也很难通过外部工具批量读取。就算我想换个软件挂载同一份数据，也几乎不可能。而 Markdown 恰好解决了这个问题：内容与展示彻底分离，格式只是标记，内容本身就是可以被人类阅读的文本。这意味着哪怕未来所有 Markdown 编辑器都不维护了，我依然可以随时从纯文本中恢复核心信息。

1.1 私有格式与标准文本的核心差异

我原来的笔记数据，通常存在 SQLite 数据库或者某种私有结构的文件里。这种存储结构带来了几个隐性代价。第一，文件无法直接预览，想用文件管理器看一眼内部内容完全做不到。第二，备份复杂，如果直接复制数据库文件，一旦备份过程中发生写入，可能得到一个不可用的副本。第三，迁移困难，离开发行商的数据格式就基本作废。相比之下，Markdown 每一个文件就是一篇独立的笔记，复制、移动、压缩、同步都非常顺手。

用文件系统直接管理笔记还有一个额外好处：可以用 Git 做版本管理。纯文本文件最适合 Git 这类工具，因为差异对比非常清晰。某次修改改了什么内容，哪一行发生了变动，全部有迹可循。私有格式笔记应用即便内置了版本历史，也往往只支持应用内查看，一旦数据损坏就全没了。

另外一个非常实际的好处是全文检索。Markdown 文件可以直接被 grep、ripgrep 这类命令行工具索引和搜索，也可以在 NAS 上启用文件内容索引。我原来的笔记套件搜索只能搜自己的数据库，索引一旦坏掉，搜索功能就完全瘫痪。迁移成 Markdown 后，我直接在终端里输入一句话，一秒就能定位到所有包含该句子的笔记，这种自由度是私有格式给不了的。

当然，Markdown 也有短板。排版能力肯定不如专业文档工具，复杂表格写起来尤其痛苦，数学公式也需要额外插件支持。但我的判断是：排版需求可以留给展示层解决，存储层只需要保证内容完整、格式可读。只要把“存储与维护”和“输出渲染”这两件事分开，Markdown 的局限就变得完全可以接受。

1.2 Markdown 生态在 NAS 场景中的适配性

在 NAS 上选择 Markdown 笔记，有天然的技术契合点。首先是存储位置，Markdown 文件可以直接放在 NAS 的共享文件夹里，不需要任何数据库服务。共享文件夹本身就可以被挂载到局域网内任意设备上，也就意味着笔记可以被随意备份或读取。其次是编辑工具非常多，NAS 上可以通过 Docker 部署各种支持 Markdown 的编辑器或知识库工具，比如 Outline、AppFlowy、Memos 等等，都不绑定特定厂商。

多端同步也是我很看重的一点。Markdown 纯文本格式非常适合用 rsync、rclone 或 Syncthing 这类通用工具做同步，而不是依赖某个笔记厂商的云端接口。我后来的方案是：NAS 作为中心存储，Syncthing 用来同步到手机和笔记本电脑，再通过 rclone 定时备份到云盘。整个数据链路没有一家厂商可以绑架我的历史内容。

2. 迁移前奏：盘点NAS笔记数据与明确迁移范围

迁移看着不复杂，其实风险藏在细节里。开始动手之前，你一定要搞清楚自己手上有多少数据、哪些数据值得保留、哪些可以丢弃，以及原系统到底提供了什么样的导出能力。这一步做得越扎实，后面脚本清洗就越省力。

2.1 盘点笔记结构：标题、正文、标签、附件与笔记间链接

登录 NAS 后台，把笔记应用的数据目录打开，通常会看到这几类组成部分：

• 正文数据：每条笔记的标题、正文、创建时间、修改时间、标签等元数据
• 附件与图片：插入到笔记里的本地图片、PDF 或其他文件，通常存放在专门的资源文件夹
• 笔记间链接：一篇笔记中引用另一篇笔记的内部链接，在私有格式里往往以特殊协议为前缀
• 回收站残留：已经删除但是还没彻底清理的旧内容

我当时的处理方式是先把笔记分成三个层级。第一类是个人知识库，长期有效，必须完整保留；第二类是项目过程记录，留存核心节点，过滤掉重复草稿；第三类是随手片段，比如临时灵感、会议随手记录，统一转换成纯文本备份后不再作为活跃笔记维护。这个分类很重要，因为如果你把所有废稿都一股脑导出来，清洗脚本要处理的数据量会大很多，出错概率也跟着上升。

2.2 确认导出能力：脚本、导出接口与格式限制

不同 NAS 笔记套件的导出能力差距很大。有的支持批量导出 Markdown，有的只支持单篇导出 HTML，有的提供了数据库直接读取的可能性，有的则完全没有导出功能。我建议先到应用设置和帮助文档里确认三件事：

• 是否支持批量导出？导出的格式是 Markdown、HTML 还是纯文本？
• 导出内容是否保留标签、创建时间和修改时间？
• 附件（尤其是图片）是放到统一目录，还是散落在每篇笔记的文件夹里？

我自己的情况比较尴尬：套件支持批量导出 Markdown，但导出的图片路径完全错乱，内部链接全部变成不可用的协议前缀，标签信息也丢失了。这说明不能百分百依赖官方导出，必须自己写脚本二次处理。所以第二步的盘点中，我额外检查了导出的文件结构，记录下这些字段：

列出这张表后，我心里就有数了：官方批量导出只能作为半成品，真正高质量的 Markdown 必须从底层数据自己生成。

2.3 迁移范围与风险控制：先备份，再测试导出

无论你用什么方法迁移，第一件事永远是完整备份。我在迁移前的当天晚上，先给 NAS 上的笔记应用数据目录做了磁盘快照。如果你用的 NAS 支持 Btrfs 快照，可以直接对共享文件夹做快照；否则就用 rsync 把整个笔记数据目录同步到另一块硬盘上。这一步虽然耗时，但它能保证后面折腾失败后可以随时回退。

备份完成后，我挑了五篇覆盖不同复杂度的笔记做导出测试：纯文本笔记、含图片笔记、含表格笔记、含内部链接笔记、含代码块笔记。测试结果让我意识到，同一个套件导出的内容也极度不一致。所以强烈建议你也先跑一个小样本，千万不要一上来就全量导出。我在这个环节还顺手记录了哪个类型的笔记清洗工作量最大，后面写脚本时就能区分优先级，重要的事情优先处理。

3. 核心环节：从 NAS 笔记批量导出为 Markdown 的实操路径

一切准备工作完毕，正式开始迁移。这一步的核心思路是：不依赖官方导出，直接从数据源头读取内容，转换成结构化 Markdown，再解决图片路径和链接问题。

3.1 准备迁移脚本：从 NAS 数据目录读取并转换

不同笔记套件的底层存储差异较大，但常见的情况是 SQLite 数据库配合一个资源文件夹。如果你确认数据库是 SQLite，那么迁移脚本就清晰了：用 Python 的 sqlite3 模块读取笔记表，把每一条记录转换成独立的 Markdown 文件。

我先用一个简化版的示例来讲清楚核心逻辑。假设数据库里有一张表 notes，字段包含 id, title, content, created_at, updated_at, tags，迁移脚本可以这样写：

python复制import sqlite3
import os
import re
from datetime import datetime

db_path = "/volume1/notes_app/note.db"
output_dir = "/volume1/notes_export"

conn = sqlite3.connect(db_path)
cur = conn.cursor()

cur.execute("SELECT id, title, content, created_at, updated_at, tags FROM notes")
rows = cur.fetchall()

os.makedirs(output_dir, exist_ok=True)

for row in rows:
    note_id, title, content, created_at, updated_at, tags = row

    # 清洗非法文件名字符
    safe_title = re.sub(r'[\\/:*?"<>|]', "_", title).strip()
    if not safe_title:
        safe_title = f"note_{note_id}"

    # 组装 YAML front matter 和正文内容
    tag_str = ", ".join(tags.split(",")) if tags else ""
    md_content = f"""---
title: "{title}"
date: {created_at}
updated: {updated_at}
tags: [{tag_str}]
---

{content.strip()}
"""
    md_path = os.path.join(output_dir, f"{safe_title}.md")
    with open(md_path, "w", encoding="utf-8") as f:
        f.write(md_content)

conn.close()
print("导出完成，共处理", len(rows), "篇笔记")

这里有几个细节容易踩坑。第一，文件名里的非法字符必须替换，尤其是 Windows 和 SMB 协议下不允许出现的 : * ? " < > | 等字符。第二，数据库中的 content 字段可能不是纯文本，而是包含 HTML 标签。如果你发现正文里出现 <div> 或 <p> 之类的标签，就需要用 pandoc 或 Python 的 html2text 库做一次预处理。第三，FRONT MATTER 里的标签字段最好做标准化，否则后文处理内部链接时容易出现大小写不一致的问题。

3.2 批量处理图片与附件：路径映射与复制

图片处理是我在迁移过程中最头疼的部分。原笔记套件把所有图片都塞进一个 resource 文件夹，但在正文引用里用私有协议标记引用。官方导出时虽然把图片复制出来了，却把文件名改写成了无规则的哈希值，导致我完全无法从 Markdown 正文反推图片属于哪篇笔记。

解决思路是建立一个映射表，核心流程分三步：

1. 扫描原资源文件夹，获取每个文件的原始文件名和对应路径
2. 读取每篇笔记的正文，找到图片引用中的原文件名
3. 将原资源文件复制到新的 Markdown 附件目录，并替换正文中的引用路径

python复制import shutil
import glob

src_resource_dir = "/volume1/notes_app/resources"
dst_resource_dir = "/volume1/notes_export/images"

# 复制所有资源文件到导出目录
os.makedirs(dst_resource_dir, exist_ok=True)
for img_path in glob.glob(os.path.join(src_resource_dir, "*")):
    if os.path.isfile(img_path):
        shutil.copy2(img_path, dst_resource_dir)

# 替换 Markdown 文件中的图片路径
for md_file in glob.glob(os.path.join(output_dir, "*.md")):
    with open(md_file, "r", encoding="utf-8") as f:
        content = f.read()
    # 假设原引用为 /volume1/notes_app/resources/xxx.png
    content = content.replace("/volume1/notes_app/resources/", "images/")
    with open(md_file, "w", encoding="utf-8") as f:
        f.write(content)

请注意，在真实项目里，我强烈建议把“复制图片”和“替换路径”分开执行。如果你先替换路径再复制文件，一旦复制过程失败，Markdown 里的引用就会指向不存在的图片文件，排查时会非常被动。分步执行、分步验证，这是所有数据迁移操作里最通用的原则。

还有一个细节：原笔记里的图片可能是各种格式混合的，比如 .png、.jpg、.webp。复制时要注意大小写和扩展名。Linux 文件系统对大小写敏感，如果原引用是 .PNG 而实际文件是 .png，转换后图片就无法正常显示。我建议在脚本里统一文件扩展名为小写，并同步修改 Markdown 引用。

3.3 处理笔记间内部链接：把私有链接转为文件相对路径

如果你的笔记存在相互引用，内部链接在导出后大概率会变成形如 note://xxx 的协议格式。这种链接在 Markdown 编辑器中当然无法点击跳转。我的处理方法是维护一个“标题到新文件名”的映射表，然后把所有的 note:// 链接替换成相对路径链接。

python复制def build_path_map(output_dir):
    path_map = {}
    for root, dirs, files in os.walk(output_dir):
        for f in files:
            if f.endswith(".md"):
                title_key = os.path.splitext(f)[0]
                path_map[title_key] = os.path.relpath(os.path.join(root, f), output_dir)
    return path_map

path_map = build_path_map(output_dir)

for md_file in glob.glob(os.path.join(output_dir, "*.md")):
    with open(md_file, "r", encoding="utf-8") as f:
        content = f.read()

    def replace_link(match):
        note_title = match.group(1)
        target = path_map.get(note_title)
        if target:
            return f"[{note_title}](./{target})"
        return match.group(0)

    content = re.sub(r"\]\(note://([^)]+)\)", replace_link, content)
    with open(md_file, "w", encoding="utf-8") as f:
        f.write(content)

第一次跑脚本时，我把所有没有匹配到文件的 note:// 链接打印到日志中，结果发现大约有 5% 的链接失效。原因不复杂：原笔记中被链接的标题含有英文括号，而导出脚本在生成文件名时会把括号替换掉，导致映射表找不到目标。后来我额外做了一份“别名映射表”，手动记录这些特殊情况，才把所有链接修好。

建议各位在写链接替换脚本时，一定要保留日志输出，把转换失败的链接单独列出来人工处理。链接修复不追求一次性百分百通过，但一定要知道失败在哪里。

3.4 统一的换行与编码处理：中文场景的关键细节

中文内容迁移时还有一个隐蔽的大坑：换行符不一致。有的笔记原来在 Windows 下用 \r\n 换行，有的在 Linux 下用 \n 换行。直接在数据库中读取内容并写入文件时，如果保持原样，很容易生成混合换行符的文件。Markdown 编辑器通常能容忍这个问题，但一旦你用 Git 做版本管理，就会看到大量明明没改动内容却显示“全文被修改”的 diff，非常痛苦。

我在迁移脚本里统一做了两件事：把所有文本的换行符规范成 \n，并把文件统一保存为 UTF-8 编码（不带 BOM）。Python 里写文件时最好指定 newline="\n"，避免在 Windows 系统上被自动改成 \r\n。另外要注意，UTF-8 BOM 头在某些 Markdown 渲染器里会导致首行标题识别错误，虽然不影响阅读，但在生成静态站点时很容易踩雷。

中文文件名本身也是个问题。中文名在 macOS 上会使用 NFD 形式的 Unicode 标准化，在 Linux 上则可能是 NFC 形式，两者在 Git 和文件系统间很容易产生“看起来一样但实际不是同一个文件”的差异。我的处理方法是为每篇笔记增加一个日期前缀加 ID 的形式，比如 2024-10-01-三个关键词.md，既能保留可读性，还能让文件名在跨平台同步时更稳定。

4. 不同 NAS 环境下的导出方案对比：群晖、绿联、飞牛与自组设备

迁移方法虽然有一致性，但不同 NAS 系统的实际数据位置、权限管理和可选工具差异很大。我分别介绍一下我在不同环境下的处理思路。

4.1 群晖 NAS：利用 Docker 与官方套件导出能力

群晖是最常见的 NAS 品牌之一。如果你用的是群晖自带的 Note Station，它支持将笔记导出为 HTML 压缩包。解压后会得到一个包含 HTML 文件和资源的文件夹。直接用 pandoc 批量转换 HTML 为 Markdown：

bash复制pandoc input.html -t markdown -o output.md

不过 Note Station 导出的 HTML 里会包含大量无意义的语义标签，转换后容易留下空行和多余引用。我的建议是先用 html2text 做一次基础清洗，再用正则把残留的 <div>、<span> 标签删除。群晖上可以用 Container Manager 挂载一个包含 Python 或 Pandoc 的容器，避免在宿主机上折腾环境。

4.2 绿联 UGREEN NAS：检查内置应用与数据库位置

绿联 NAS 使用的 UGOS 系统自带笔记应用，数据一般存放在 /volume1/UGREEN/ 或 /appdata/ 下。你如果觉得找不到，就直接 SSH 登录系统，搜索 .db 文件：

bash复制find / -name "*.db" 2>/dev/null | grep -i note

找到数据库后，先不要急着写脚本，建议用 DBeaver 或 SQLite Browser 打开数据库，查看表结构，确认 content 字段是纯文本还是 HTML。绿联 NAS 有一个常见权限问题：Docker 容器内无法读取宿主机目录。原因是宿主目录权限是 700，只允许 owner 访问，容器用户进不去。你可以临时把目录权限调整为 755，或者将容器以指定用户 ID 运行：

bash复制docker run -v /volume1/notes_data:/data -u $(id -u):$(id -g) my-image

4.3 飞牛 OS 与自组 NAS：直接面向文件系统操作

飞牛 OS 这类自组系统灵活性更高，笔记数据通常就是简单的文件目录，不一定有数据库。如果是这样，迁移就更简单了，直接把目录复制下来，然后用文本处理工具批量操作。

对于已经使用纯 Markdown 的用户来说，甚至可以跳过格式转换步骤，直接用 rclone 或 rsync 同步整个文件夹。我就在飞牛 OS 上试过用 Syncthing 把笔记文件夹同步到手机和电脑，速度很快，而且完全不依赖某个具体应用。自组 NAS 的另一个好处是，你可以随时随地 SSH 登录，用命令行检查和修改文件，这让批量操作变得非常顺手。

4.4 各类 NAS 迁移方案对比与适用人群

不要迷信某一种方案。我的原则是先用小样本测试，算出清洗成本。如果某个方案的损坏率超过 5%，基本就不建议采用，因为后面的返工成本远高于前期多花的那点调试时间。

5. 迁移后整理与验证：文件组织、链接检查与备份策略

导出并清洗完成，不等于迁移结束。把几百个 Markdown 文件堆在一个目录里，只会让你从一个坑跳进另一个坑。我迁移完毕后，非常认真地梳理了目录结构，并做了一整套链接和备份验证。

5.1 目录结构设计：从扁平导出到分级知识库

我最终采用的目录结构是这样的：

text复制notes/
├── 00-Inbox/            # 临时笔记，每天整理一次
├── 10-技术/              # 技术笔记
│   ├── NAS/             # NAS 相关
│   └── 编程/             # 编程语言、框架
├── 20-生活/             # 生活记录、想法
├── 30-项目管理/          # 项目过程记录
├── _assets/             # 共享图片附件目录
└── README.md            # 总索引

数字前缀是刻意加上的。中文目录名按字典序排列时会有很多不可预测的结果，而数字前缀可以保证目录顺序稳定。在每个主题目录下，我还维护了一个 MOC.md 文件，把所有相关笔记的链接汇总成一个“内容地图”。比如在 10-技术/NAS/MOC.md 中，我可以放上所有 NAS 相关笔记的链接和简述。

这种做法对后期知识管理帮助很大：你不是在死板地保存一堆文件，而是建立了一个可以生长的知识网络。每当你需要回顾某个主题，只要打开对应的 MOC 文件，就能看到所有相关内容，不用到文件夹里乱翻。

5.2 链接与图片资源批量核查

迁移后的验证非常关键。我写了一个几十行的 Python 脚本，遍历所有 Markdown 文件，提取里面的本地图片引用和内部链接，然后检查目标文件是否存在。这种检查很难全部手动完成，必须交给脚本。

第一次运行后，我发现大概有 70 个图片引用失效。排查后发现原因很统一：原笔记资源文件夹中，图片文件名有的带空格，有的带中文括号，在导出和复制过程中，空格被替换成了下划线，而引用路径没有同步更新。这给我一个教训：在处理文件名清洗时，必须把“引用路径的替换”和“文件名的替换”放在同一个映射表里维护，不能各做各的。

还有一个实用小技巧：如果图片文件数量不多，你可以直接在 NAS 的文件管理器里开启缩略图预览模式，快速浏览所有图片是否正常显示。Markdown 文件本身无法预览，但图片文件可以，所以你只要扫一眼缩略图，就能发现大批文件是否损坏或丢失。

5.3 备份策略：多副本 + 版本管理 + 定时同步

迁移完成后的备份策略，我严格按照“3-2-1 原则”来执行：至少 3 份数据副本，2 种不同存储介质，1 份异地备份。具体落地是这样的：

• 第 1 份：NAS 共享文件夹里的主数据副本
• 第 2 份：外置 USB 硬盘或第二块 NAS 硬盘，通过 rsync 定时同步
• 第 3 份：云存储（比如 Backblaze B2、阿里云盘、S3），通过 rclone 定时同步

除了文件级备份，我还为 Markdown 目录启用了 Git 仓库。在 NAS 上初始化一个 git 仓库后，每次修改完笔记就提交一次。Git 对文本文件的版本追踪非常高效，误删、误改都可以通过 git log 和 git diff 找回。针对几千篇笔记的规模，Git 性能完全不是问题。

我的定时任务这样安排：每天凌晨 3 点，rsync 将 notes/ 目录同步到 NAS 的第二块硬盘；每周日凌晨 2 点，rclone 将增量同步到云端对象存储。两条命令都用系统自带的任务计划执行，不依赖任何第三方软件或笔记应用。只要目录结构保持不变，哪怕未来换一台 NAS，迁移成本也几乎为零。

6. 迁移过程中的典型问题与排查经验

整个迁移过程中我踩了不少坑，这里挑选最典型的五个问题做记录，希望能帮你缩短调试时间。

6.1 导出的文件标题出现乱码或空白

原因通常是笔记标题里含有全角空格、首尾空格、全角冒号等特殊字符。这些字符在文件系统里要么不可见，要么导致文件复制时被截断。我的处理办法是在脚本里强制规范化标题：去除首尾空格，将全角符号替换为半角符号，非法字符统一替换成下划线。如果清洗后标题重复（比如两篇笔记都叫“新建笔记”），就在文件名末尾追加序号数字避免覆盖。

6.2 Docker 容器内无法读取 NAS 数据目录

群晖和绿联上都很常见。大多数情况是容器用户 ID 与宿主目录的 owner 不一致。执行命令时加上 -u $(id -u):$(id -g) 就能覆盖掉这个权限问题。如果还不行，先在宿主机上执行 ls -ld 看目录权限，确认是不是 700。必要时临时调整为 755，迁移完成后再改回来。不建议直接 chmod 777，暴露风险太大。

6.3 Markdown 表格转换后格式错乱

原笔记软件的表格一般用 HTML 标签保存，导出成 Markdown 后经常出现行列错乱、竖线缺失。我尝试过用 pandoc 强转，但效果不稳定。对于复杂表格，我最后选择直接在 Markdown 文件里保留 HTML 表格代码。虽然不够“纯 Markdown”，但至少渲染效果稳定：

html复制<table>
  <thead>
    <tr><th>字段</th><th>值</th></tr>
  </thead>
  <tbody>
    <tr><td>示例</td><td>内容</td></tr>
  </tbody>
</table>

Github 风格的 Markdown 编辑器基本都能正常渲染这种嵌入式 HTML 表格。

6.4 迁移后搜索失效

迁移成 Markdown 后，搜索不再依赖笔记应用的内部索引，而取决于文件系统层面。群晖的 Universal Search 需要提前启用文件内容索引，否则只能搜文件名。macOS 通过 SMB 挂载 NAS 后，Spotlight 一般搜索不到文件内容，这是正常的，建议直接在 NAS 端搜索，或者使用命令行 rg 在挂载目录内搜索。

这个转变一开始会有点不适，但用习惯以后你会觉得特别高效。直接在终端输入：

bash复制rg -l "关键词" /path/to/notes/

比打开任何笔记应用搜索都快。

6.5 迁移过程中的时间与修改信息丢失

导出工具往往不保留笔记的创建时间或修改时间，导致所有文件变成同一天生成。如果你在意历史脉络，必须在脚本中读取数据库的 created_at 和 updated_at 字段，并写入 Markdown 文件的 front matter。Git 只能跟踪迁移之后的变动，迁移前的原始修改时间只能靠这些元数据来保留。

结尾

我现在已经用这套方案跑了四个多月，最大的体会是“心理负担变小了”。以前总担心笔记软件倒闭怎么办、数据库损坏怎么办、以后换 NAS 品牌数据迁移会不会很麻烦，现在这些担忧基本没有了。日常使用中，我开始把很多零散想法直接丢进 00-Inbox/ 目录，周末再整理到对应主题目录里。手机端临时记录用支持 WebDAV 或本地文件同步的笔记工具，回家后用编辑器打开改，整个流程非常轻量。

如果说有什么建议想留给正在筹划迁移的朋友，那就是不要急于求成。先把备份做扎实，再用少量笔记跑通测试，最后才做全量清洗。我第一次全量导出时正是因为太着急，导致后期大量图片链接失效，花了整整两天返工。与其那样，不如提前把每一环节都验证清楚再动手。等到你的笔记目录变成一棵结构清晰的树，而不是一堆散乱的文件时，你会觉得这两周折腾得值得。