用 NAS 的人，十有八九都动过“自带笔记应用”的念头。群晖叫 Note Station，威联通叫 Notes Station，这两年流行的绿联、飞牛也都有类似套件。我也是从 Note Station 用起的，身边还有朋友为了笔记功能专门选了某个品牌的 NAS。但用了两年后，我把所有笔记一篇不剩地迁了出去，彻底转成了 Markdown 文件，连待办清单都写进 .md 里。
这篇不是劝你删掉自带笔记，而是把我踩过的坑、迁移的步骤、换完以后又遇到的新问题，完整说一遍。如果你正在 NAS 自带笔记和 Markdown 之间犹豫，或者已经攒了不少笔记正发愁怎么搬，这篇应该对你有用。
1. 自带笔记最劝退我的三个地方，越用越扎心
1.1 私有格式是个黑盒，看得见却摸不着
NAS 自带的笔记应用，看起来是把笔记“存”在了家里，但实际存的是一套私有格式。群晖 Note Station 的数据在后台是数据库和打包文件，威联通、绿联的情况也差不多。你通过 SSH 登上 NAS，能看到一堆数据库文件，就是没法像打开普通文档一样直接读出一篇笔记的内容。
这个问题的杀伤力要到迁移时才爆发。我当时想把几篇老笔记导出来分享给同事，系统只支持一篇篇导出 HTML，导出的文件里还有一堆样式标签，附件被压缩成一块块的，根本没法直接给别人用。后来套件升级过一次，部分老笔记里的图片附件直接打不开了，界面里只留下一个裂图占位符。那一刻我彻底明白了：这些笔记数据从来都不是“我的文件”，我只是被允许在一个黑盒里查看它们，至于数据怎么组织、将来怎么带走，全由厂商说了算。
对比一下 Markdown 就是另一回事了：一个 md 文件放在共享文件夹里，你想看就用任何文本编辑器打开，想备份就复制走，想整体迁移就直接把文件夹拷到新 NAS。文件系统本身就是最老实、最透明的存储方案，不需要任何厂商的“导出功能”来施舍数据。
1.2 说好的多端同步，实际是“单点依赖”
自带笔记的同步逻辑很简单粗暴：所有设备都连回你家里那台 NAS，NAS 一不在线，笔记就跟着“失联”。
我印象很深的一次是在客户会议室。手机开着自带笔记 App，现场网不好，翻一篇前几天写的笔记，转圈转了快半分钟才加载出来。还有一次我给 NAS 升级系统，全家设备在那半个多小时里都没法看笔记。至于户外用官方远程服务时的速度，那就更随缘了。笔记这个场景最忌讳的恰恰是“网络不稳定就不可用”，因为灵感出现的时候往往环境最不可控。
换到 Markdown 方案以后，每台设备本地都有一份文件副本。手机用同步工具把目录拉下来，就算 NAS 断电、断网，本地照样能打开、编辑，等网络恢复再把改动同步回去。这个体验差异是本质性的：自带笔记的可靠中心是那台 NAS，Markdown 的可靠中心是“文件本身”，NAS 只是一个同步中转站而已。
1.3 编辑器停留在“能用”，谈不上“好用”
客观说，自带笔记用来记流水账、备忘录是够的。但一旦你开始认真用笔记，需求马上就超出了它的能力范围。
我写技术笔记要贴代码、画表格，时不时还要写一段数学公式。自带笔记的富文本编辑器在这方面非常吃力：代码块没有高亮，公式基本没法处理，长一点的文档滚动起来有明显卡顿。更难受的是整理能力，没有标签体系、没有双向链接、不能按目录批量操作，想给一批笔记统一加个关键词，只能在界面上逐篇点开改。
还有一点很容易被忽略：自带笔记的搜索只能在应用界面里搜。如果你和我一样偶尔会用 SSH 登录 NAS，想用 Linux 命令直接在笔记内容里 grep 一个关键词，自带笔记给不了这个能力。这种“编辑体验跟不上、检索路径单一”的问题，对知识型使用者来说才是真正的天花板。
2. 我为什么选 Markdown，以及它对 NAS 用户好在哪
2.1 纯文本意味着“格式永不过期”
Markdown 的本质是带极轻量标记的纯文本。纯文本最大的优势不是炫，而是长寿。你可以想想：1997 年用 Word 97 存的文档，今天未必还能用原软件打开；但 1980 年代存下来的 .txt 文件，现在任何系统都能读。Markdown 就是在纯文本基础上加了几个符号约定：井号是标题、星号是加粗、减号是列表。就算二十年以后所有的 Markdown 编辑器都消失了，用系统自带的记事本也能打开，内容一个字节都不会丢。
我有个很朴素的标准：一个笔记系统值不值得长期投入，取决于“十年后我要不要还读得懂它”。私有格式十年后大概率变成需要旧版本软件才能解析的遗留物，而 Markdown 文件十年后依然可以原样打开。这个确定性，是任何“生态”“功能”都换不来的。
2.2 文件直接交给 NAS 的底层能力接管
当笔记变成一个个文件，NAS 本身那些成熟的能力就全部派上用场了。
首先是版本回滚。群晖这类 NAS 一般都支持 Btrfs 文件系统快照，笔记目录的快照可以按小时、按天自动打。以前用自带笔记，误删一篇笔记只能靠应用里的回收站，很多时候根本翻不回来；现在误删了、改坏了，直接回到快照里把文件捞出来，比任何笔记软件的“历史版本”都可靠。
其次是权限管理。共享文件夹里可以按用户设置访问权限，家里每个人的笔记子目录互不干扰，比在同一个笔记应用里分账户更符合文件管理的直觉。
再就是检索自由。笔记文件就在磁盘上，Linux 的 grep、ripgrep，Windows 的 Everything，NAS 自身的全文索引，全都能检索。我一度在 NAS 的 SSH 里直接用rg -l "NAS迁移" /volume1/notes扫出所有相关笔记，这种在文件层面直接操作的快感，是封闭应用给不了的。
2.3 生态工具链太丰富，转换和发布都比想象方便
Markdown 背后是一整条成熟生态，这也是我最终下决心的临门一脚。
编辑器方面：Obsidian、Typora、VS Code、Joplin，每一个都能直接打开同一个 md 文件，随取随用。转换方面：pandoc 可以一条命令把 Markdown 转成 Word、PDF、HTML；市面上还有工具把 Markdown 表格转成 Excel、把网页一键保存成 Markdown 文件。内容发布方面，写公众号文章可以直接用格式化工具渲染好再粘贴，写博客可以直接对接静态站点，写技术文档可以直接进知识库系统。
我常跟朋友说，自带笔记是“给你一个房间，所有家具都固定在墙上”；Markdown 是“给你一堆积木，想搭成什么随你”。这两种自由度，决定了后续所有的玩法空间。
3. 迁移实操：我这一周都做了什么
3.1 从旧笔记体系导出的两种路径
迁移第一步当然是先导出。我的做法是先走官方导出：在自带的笔记 Web 界面里，把笔记逐篇另存为 HTML。笔记数量不多还好，只有几百篇的话这个操作会非常枯燥。有精力折腾的话，也可以找社区脚本去批量抓取，原理就是模拟 Web 端接口，把每篇笔记的内容和附件批量拉下来，但脚本的稳定性和版本适配要碰运气。
拿到 HTML 之后，我用 pandoc 做格式转换：
pandoc -f html -t gfm note.html -o note.mdgfm 是 GitHub 风格的 Markdown，表格、代码块的兼容性比较好。转换出来的结果当然不是尽善尽美，列表、缩进会有少量偏差，但这不重要，迁移第一阶段的核心目标只是“内容不丢、结构可读”。格式细节留在日常使用时随手修正就好。
提示：迁移时先别追求完美格式化。我给自己定了原则——先保内容，再保版式。等文件全部落地，再按重要程度分批清理格式，这样迁移不会被洁癖拖死。
3.2 目录结构和命名规范，决定了三年后好不好找
文件落地之后的第一个问题是：目录怎么建？
我采用的是 PARAx 变体，本质是“按行动场景区分，而不是按内容主题区分”：
笔记/ ├── 00-收件箱/ # 快速记录，还没来得及分类 ├── 01-项目/ # 有明确截止时间和目标的任务 ├── 02-领域/ # 长期关注的领域，比如网络设备、做饭、理财 ├── 03-资源/ # 需要存下来的参考资料和素材 ├── 04-归档/ # 已经完结或不再活跃的内容 ├── 99-模板/ # 日记模板、会议记录模板、会议纪要模板 └── assets/ # 所有笔记共享的图片和附件命名规则我当时定了两条：文件名用YYYYMMDD-标题.md，方便按时间排序；文件名里不出现空格和特殊字符，中文没问题，但半角括号、斜杠这类能免则免。项目笔记则用项目名/日期-内容.md的结构，把同一项目的材料收拢在一个文件夹里。
附件统一放assets/根目录，配合“相对路径”引用。这样的好处是去重：很多工具默认会把图片存到每篇笔记自带的附件文件夹，时间长了会产生大量重复图片，同步和备份都很吃亏。统一附件目录后，同一个图片只需要一份副本。
3.3 同步方案：让 Markdown 文件夹在 NAS 和所有设备上“活”起来
文件建立好之后，就要解决多端访问的问题。我试过几种方案，各有取舍，直接放在一起对比：
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| SMB 挂载 | 局域网内的电脑 | 简单直接，像本地磁盘一样操作 | 离开局域网就没法用 |
| 官方 Drive 套件同步 | 全平台通用 | 厂商维护，冲突处理相对完善 | 依赖品牌生态，迁移品牌时要换工具 |
| Syncthing 容器同步 | 多设备跨平台点对点 | 文件实时双向同步，离线可用 | 初次配置略复杂，同步冲突需要自己梳理 |
| WebDAV 挂载 | 移动端和电脑远程访问 | 兼容性好，App 支持多 | 编辑体验取决于挂载稳定性 |
我自己最终采用的是“局域网设备走 SMB，手机走 Syncthing 双向同步”。在 NAS 上用 Docker 跑一个 Syncthing 容器，和手机、平板、家里那台旧笔记本组成同步网络，文件改动秒级同步到各个设备。Syncthing 的好处是点对点传输，哪怕临时没有互联网，只要设备在同一局域网里也能同步，这正好补上了自带笔记“必须依赖 NAS 在线”的短板。
远程访问的话，我用的是 NAS 厂商自带的远程文件服务，手机上直接打开文件目录，和普通文件管理器体验差不多。这个层面的方案很多，只要能让你的文件目录在多端可见就算合格，不用过度纠结。
3.4 编辑器配置：把 Obsidian 的附件路径和同步目录对齐
编辑器我主力用 Obsidian，辅助用 Typora。Obsidian 负责日常管理和知识连接，Typora 负责写长文时那种沉浸式输入体验，需要批量处理时再开 VS Code。
配置时最容易忽略的是附件路径设置。Obsidian 的默认附件路径取决于每个库的设置，我用的是“相对路径到 assets”，打开设置把“附件默认存放路径”改成assets/，同时开启“使用相对路径嵌入图片”。Typora 那边也一样，在“图片→插入图片时”选择“复制图片到相对路径”，这样同一篇 md 文件拷到任何位置，配图都不容易裂。
这里还有个小细节：不同编辑器对 Markdown 语法的支持存在差异。我会统一使用兼容性最好的解析方式，比如表格尽量接近 GitHub 风格，引用块用>加空格，注意页签不要用编辑器私有的扩展语法。这样文件放到任何编辑器里都基本不变形。
4. 换完 Markdown 之后，又是另一轮踩坑
4.1 图片路径与附件同步：最经典的翻车点
迁移完的前两周，我在地铁上用手机打开一篇笔记，里面全是裂图。查了半天，原因是之前 Typora 默认把截图存到了电脑上的本地目录，而同步工具只同步了笔记目录，没有把图片目录纳入进来。
这个问题的解法是双管齐下：第一，把附件目录和笔记目录放进同一个同步根目录里，确保图片永远跟着笔记走；第二，在源码层面强制使用相对路径，而不是D:\xxx\...这样的绝对路径。Windows 下 Markdown 解析器对反斜杠的兼容很差，所以路径分隔符我一律用/。
如果你已经写了不少包含绝对路径的笔记，可以用一条简单的 Python 脚本批量替换，把http://之外的本地绝对路径统统改成相对于笔记根目录的assets/路径。这种脚本我只写过一次，但它是那段时间里性价比最高的一次投资。
4.2 换行和渲染差异：同一个文件，不同编辑器长得不一样
Markdown 有个很经典的坑：换行在不同解析器里的表现不一致。标准 Markdown 里，段落要靠“空行”分隔；在部分编辑器里，你敲一次回车就显示换行，但同一个文件放到另一个编辑器里，两个句子会粘连在一起。
我踩过的是：在 Typora 里写的笔记，回车很直观，但拿到 Obsidian 或公网站点的解析器里，段落全变成了一段。后来我强制自己遵循一条规则：段落之间一定要用空行分隔，不要依赖单个回车来排版；需要强制断行的地方，宁可用<br>，至少所有解析器都会认。
再就是编码问题。NAS 上的文件一般用 UTF-8 保存，但如果你的旧笔记是从 Windows 导出的，偶尔会有 BOM 头或 GBK 编码残留，在 Linux 端 grep 时会出现乱码。批量转换时顺手统一成 UTF-8 无 BOM，能省掉后面很多麻烦。
4.3 多端并发修改和快照回滚
多设备同步文件，最怕的是同一篇笔记在两台设备上同时改动。Syncthing 会生成“conflicted copy”冲突副本，但两个版本到底留哪个，还是你自己来定。我的经验是：尽量形成一个使用习惯——同一时间段只在一台设备上编辑写，其他设备只读；如果确实要改，先刷新拿到最新版本再动笔。
更重要的防线是 NAS 快照。我定期给笔记目录打快照，有一次在 SSH 里误执行了一条批量移动命令，导致一批笔记被移动到错误目录，当时我的第一反应不是慌张，而是打开快照找回原状。这个体验和自带笔记完全不同：自带笔记的“恢复”功能覆盖范围永远有限，而文件系统快照是整份数据、全量回滚。
4.4 别把“分散”理解为“混乱”，用搜索和索引重建秩序
没有了自带笔记应用内置的那个搜索框，一开始确实会不习惯。但要清楚，那不是“搜索功能没了”，而是“搜索管道变多了”。现在我找笔记有四五条路：
第一种是用支持全文检索的编辑器，比如 Obsidian 自带的快速搜索就很强；第二种是在 NAS 的 SSH 里用rg -l "关键词" /volume1/notes，秒级扫全部文件；第三种是 Windows 上用 Everything 按文件名定位；第四种是给每一类笔记建一个索引文件，比如01-项目/README.md，把当前项目的活跃笔记链接列出来，相当于自己做了个动态目录。
我还给每篇笔记加了简单的 YAML front matter，记录标题、标签、创建时间：
--- title: NAS 笔记迁移记录 tags: [nas, markdown] created: 2025-01-15 ---标签索引加上 front matter 管理后，我已经基本不再怀念那个应用内搜索框了。搜索变得更底层、更可定制，代价只是需要自己花点时间维护，但换来的是所有工具都能搜到的自由。
5. 给准备动手的人一份可复制的检查清单
5.1 先问自己三个问题，再决定要不要搬
不是所有人都需要迁移，搬之前先坦诚回答三个问题：
- 你在乎数据的长期可访问性吗？如果答案是“在乎到愿意自己维护格式”，Markdown 值得搬。
- 你的笔记里有没有大量代码、公式、表格、复杂排版？有的话，自带笔记的编辑体验会让你越来越难受。
- 你能不能接受“自己建立目录、自己定义标签、自己处理同步”这件事？能接受，迁移才会顺畅；不能接受，那说明自带笔记的“傻瓜式”对你更友好，也不用硬搬。
我当时三项全中，所以搬得很坚决。如果你只中一两条，可以先做小范围验证再决定。
5.2 一周试水方案
正式迁移前，我先做了一个低成本实验：从最近一个月的笔记里挑出 10 篇，转成 Markdown 放进一个叫测试库/的文件夹，然后用 Markdown 编辑器读写这 10 篇整整一周，期间不打开自带笔记应用。
这一周里我重点验证四件事：手机能不能流畅看、电脑上编辑方不方便、图片能不能正常显示、同步会不会丢内容。一周结束，我没有遇到无法忍受的问题，才决定把全量笔记搬过来。这个试水成本很低，强烈建议在动手全量迁移前先做一次。
5.3 我的最终迁移清单（直接抄）
最后把完整流程整理成一份清单，照着执行即可：
- N 在自带笔记 Web 端将笔记逐篇导出为 HTML。
- 用 pandoc 批量将 HTML 转成 Markdown 文件。
- 建立笔记根目录，按“收件箱/项目/领域/资源/归档/模板”分好子目录。
- 统一文件名格式为
YYYYMMDD-标题.md，清理特殊字符。 - 把附件统一放
assets/，全局改用相对路径引用。 - 在 NAS 上用 Docker 部署 Syncthing，手机、电脑加入同步网络。
- 局域网电脑用 SMB 挂载，远程用厂商自带的文件服务。
- 配置 Obsidian 和 Typora，设置附件路径为相对路径。
- 给笔记目录开启 NAS 快照，保留一份每日自动快照策略。
- 重要内容再复制一份到移动硬盘或另一台存储设备，做好异地备份。
最后一条尤其想多说一句：搬到 Markdown 不代表 NAS 就不会坏了。任何存储都会故障，笔记文件也要纳入备份体系。我自己是“NAS 快照 + 移动硬盘冷备”双份，一份交给自动化，一份靠手动习惯。数据所有权是靠冗余堆出来的，这一点比选什么格式更重要。
现在用 Markdown 已经大半年，我没有再怀念过自带笔记。虽然丢掉了厂商自带的日历视图和卡片展示，但换来的是任何一个终端都能打开、任何脚本都能处理、任何工具都能读出的确定性。这种“文件在我手里”的踏实感，是任何私有格式都给不了的。
