我的笔记被锁在一个 App 的数据库里整整两年。想换工具时才发现，导出功能给我的是几百个残缺的 HTML 文件，图片链接全断，双链全丢。那次之后我给自己定了一条规矩：笔记必须是硬盘上能直接打开的 .md 文件，任何一个编辑器都能读，删掉软件也不影响。这几年围着这条规矩折腾过 Syncthing 加 Typora、Obsidian 加网盘同步、自建 memos，各有各的毛病：要么只能在装了客户端的那台机器上用，要么换台设备就得重新配一遍。
SilverBullet 是我最近用得最顺的一个：它把一个普通文件夹变成能多端打开的笔记站，而文件夹里除了 Markdown 什么都没有。版本已经走到 2.12.1，我在自己的旧笔记本上把启动、内存、读写、鉴权逐项量了一遍，下面写的都是本机实测的数字。
一个 exe，把文件夹变成笔记站
Windows 包解开就是一个 silverbullet.exe，52.6MB，压缩包 15.9MB，不依赖 Node、Java、Python 或者 .NET，拷到 U 盘里也能跑。
silverbullet.exe --port 3010 --single D:\notes启动后访问 http://localhost:3010 就能用。日志里第四行明确写着「只用本机可访问；要对外请加 -L0.0.0.0，并且前面挡一层 TLS」。这个默认值我很认可——笔记这东西，多数事故都出在「先跑起来再说」的那一步。
我把数据目录 ls -a 看过：一千篇笔记就是一千个 .md，没有任何 .db、.sqlite 或者隐藏索引文件。这意味着你的「备份」就是把文件夹拷走，不需要懂什么导出格式；也意味着任何同步工具都能搬它，因为它不认识别的文件形态。
实测：一千篇笔记的启动、内存和读写
测试机是 Ryzen 5 3550H、8 线程、SATA SSD、Windows 11，测试库 1000 篇 Markdown 共 117KB，每篇带 front matter 和一条双链。
- 首次运行（系统还没缓存这个 exe）到页面能打开：331ms；之后冷启动稳定在 63～86ms，同样一千篇的库重启是 74ms
- 常驻内存：空库 13.7MB，加载完一千篇的文件清单后 14.9MB
- 拉一次全库文件清单（1000 条、133KB 的 JSON）：首次 13ms，热态 4～25ms
- 按路径读单篇：2ms
- 写一个 10MB 的附件：102ms，约 98MB/s；读回 75ms
一千篇的规模下内存只从 13.7MB 涨到 14.9MB，这个数字比什么参数表都有说服力：它说明服务端并不在内存里建全文索引，只是老老实实做文件的搬运工和目录的维护者，搜索与渲染交给浏览器。代价是每台设备第一次打开得自己把索引建起来，库大了能感觉到那一下停顿；好处是 1GB 内存的老旧小主机、甚至树莓派，跑它都不会喘。
顺手测了两个边界：中文文件名带空格（会议 纪要.md）能正常写入；用 ..%2F..%2F 拼路径想穿越到上级目录，返回 404，文件没被写出去。
同步工具塞进来的笔记会自己冒出来
这一点是我最终留下它的原因。服务跑着的时候，我直接用别的程序往数据目录里写了一个新文件，1.5 秒之内它出现在网页的文件清单里，打开就是新内容，没有缓存滞后。也就是说 Syncthing、Resilio、群晖的 Cloud Sync 把文件推进来，网页端跟着就变，不需要重启服务，也不需要点「刷新索引」。
它认目录层级。我把测试库建成了三层：根目录 100 篇、日记/ 50 篇、项目/2026/ 100 篇，索引里带相对路径（日记/d-0.md、项目/2026/p-0.md）。所以手里那个用了三年的 Obsidian 库——里面全是文件夹——可以直接指过去，不用先花一个周末把结构拍平。
最大的坑：单空间模式根本没有鉴权
这是我最想让人看到的一段。前面那条命令我写了 --single，服务默认只监听本机，看起来是安全的。但我为了给平板用加上 -L 0.0.0.0 的时候，忘了它同时也意味着「任何人都能写」：
- 从同网段的另一台机器访问首页：200
- 不带任何凭据 PUT 一个 .md 文件：200，文件直接落到了磁盘上
换句话说，单空间模式下只要这台机器暴露在局域网里，同网段的任何人都能往你的笔记库里写文件、覆盖文件、删文件。日志那句「only available locally」不是客套话，是一条真实的边界。
要真正挡住，得用 2.x 的多空间模式，先跑一次初始化：
silverbullet.exe setup D:\notes --admin 用户名:密码 --space 笔记 --at=/建完之后 users.json 里存的是 argon2id 哈希而不是明文，spaces.json 里每个空间有独立的 access、readOnly、shell 白名单和 revisions 策略。再启动、再从局域网访问，裸的 PUT 和文件清单接口都返回 401，只有登录之后才放行。家里内网自己玩，--single 够用；要映射到公网，务必走多空间模式，前面再挂一层 HTTPS 反代。
另外几个会绊人的细节
- 在 Git Bash 里敲 --at / 会被 MSYS 的路径转换悄悄改成 D:/Program Files/...PortableGit/，空间就挂到了一个不存在的 URL 前缀上。写成 --at=/ 或者命令前加 MSYS_NO_PATHCONV=1 才对。
- 直接访问 /某篇笔记.md 拿到的是 2708 字节的前端空壳，不是渲染好的正文。要原文得走 /.fs/目录/文件名.md。所以别指望它当公开站点或者被搜索引擎收录，它是给自己看的。
- 启动日志里有一行「runtime Chrome detected」：导出、生成分享图这类功能会用本机 Chrome 渲染。纯容器、没装浏览器的 NAS 环境，这部分要提前想清楚。
- 可编程性走的是 Lua 脚本那条路，写查询、改渲染都行；不想折腾就当纯笔记站用，也不亏。
谁适合用，谁别碰
如果你已经有一堆 .md，想要的是「在任何设备的浏览器里打开就能写、能搜」，而且机器很弱，那它几乎是目前最省事的选择：一个文件、一个文件夹，没有数据库，迁移成本是零。
但如果你需要团队协作里的细粒度权限、版本历史逐行对比，或者像块编辑器那样拖着排版，它给不了。它的编辑体验是「带实时预览的 Markdown」——克制，也朴素，跟它待一周你就知道自己受不受得了。
我现在是：库放在 NAS 的一个共享目录里，白天在电脑上写，晚上躺床上用平板接着改，同步交给 Syncthing。你们的笔记现在躺在某个软件的数据库里，还是躺在自己的文件夹里？换过几次工具了？