本文选自付费会员通讯「iPad Power User」，如果你对 iPad Pro 以及 iPadOS 相关的生产力探索感兴趣，欢迎订阅这份邮件通讯。
可以毫不夸张地说，我几乎见证了笔记应用 Bear 过去近四年的发展历程，在这近四年的时间里，我在这款笔记应用里「堆积」了 1400 多条笔记，涵盖了从 2017 年年初到 2020 年 7 月这段时间的所思所想、所做所为。
但在 2020 这个特殊的时间点，我开始发觉 Bear 越来越无法满足我的需求，当我开始构建新的工作流程，特别是针对笔记工具的流程时，Bear 已然没有了位置。
1.Bear 的特点
从一开始，Bear 就瞄准了移动端的笔记处理需求，这是一个非常精准的产品定位，在功能层面，Bear 将标签作为笔记管理的唯一方式，用户在书写的过程里可以快速将「#标签」填入到笔记中，将笔记书写与笔记管理完美整合在一起。
更进一步，Bear 对于多标签的支持，又进一步凸显出笔记管理的灵活性，我在过去几年一直实践的「每日一记」笔记方法，充分利用了多标签的机制，从而可以更好地区分每天笔记里的不同内容类型。
这是我觉得 Bear 最打动我的地方，它从小屏幕的手机（iPhone）入手，并完美适配了 iPad 各个屏幕尺寸以及不同的输入方式，在此基础上，通过拓展（比如更多层级的标签支持）、创新（比如丰富的拖拽手势、类 Wiki 的链接机制）等，形成了一个真正属于移动平台的笔记应用。
2.Bear 的不足
从产品定位上看，Bear 要解决的是笔记记录与管理需求，但 Bear 的笔记管理功能有诸多不足，至少在我看来，无法满足我的需求。
比如没有目录功能，这个功能看起来并不重要，但一旦笔记长度变长，缺乏目录的笔记在阅读、修改起来就变得非常痛苦。
再比如缺乏版本备份/管理，这又是一个似乎没有多少作用的功能，然而对于任何一个笔记产品来说，误删笔记后的紧急恢复可以让用户更好地信任这款产品。
另外还需指出的是，Bear 独特的 Markdown 编辑器机制，纵然支持 TextBundle 这样格式的文档导出，但是当我希望将图片以 markdown 图片格式粘贴到笔记里以备不时之需的时候，我只能看到如下图这样的样式。
是的，Bear 并不支持 Markdown 格式的图片渲染，当我要查看这张图的时候，我还需要点击跳转到图片链接，这与网页超链接的形式完全一样。
当然，我可以直接把这张图「复制粘贴到 Bear」，这样我就可以快速看到图片，但如果我以后要把该图片上传到图床，我需要先从 Bear 保存图片到本地，然后在上传到图床，再获得 Markdown 链接复制到 Drafts 等写作工具里…….这个过程让我非常崩溃。
3.我的决定
事实上，当我开始思考自己 2020 年笔记流程的时候也在不断思考如何将 Bear 「改造」成更符合需求的应用。举个例子来说，基于「原子化」的原则，我让每一则笔记的内容足够细颗粒，然后通过类 Wiki 的形式联系起来，不过实践过后我还是发现，这个方法无法解决我的对于笔记流程的需求。最大的问题是，Bear 里的链接构建只是单向链接，我可以实现从 A 到 B，但无法让 B 自动返回 A，这极大限制了笔记 A 与笔记 B 之间「产生关系」的可能性。
另一方面，一旦开始「原子化」笔记，Bear 缺乏有效自动「发现」原子化笔记的机制，换句话说，这些零碎、原子化的笔记很可能没有和其他任何笔记链接在一起，而是散落在各处，需要用户一个个去寻找去确认。
上述这些问题以及我对笔记工具需求的变化，促使我最终决定告别 Bear，Bear 支持 Textbundle 格式的数据导出，这意味着，我可以把笔记图片、笔记链接等一并导出，我选择使用 FSnotes 作为 Bear 笔记导出后的存储工具。
FSnotes 是一款开源的笔记应用，源代码在 Github，同时还提供 macOS 与 iOS/iPadOS 两大平台的应用，其中 iOS/iPadOS 的售价为 2.99 美元，利用 Textbundle 格式的导入，可以把 Bear 里的内容整体迁移到 Fsnotes。
另外值得一提的是，相比于 Bear 采用的 CloudKit 同步机制，FSnotes 的笔记数据通过 iCloud 同步，两种机制并没有好与坏的区别，但从我的角度去看，将笔记数据放在用户可以感知的 iCloud 上，可以实现更灵活的笔记处理，比如，我可以通过其他工具编辑 iCloud 里的这些文件。
在把 Bear 里的数据迁移到 FSnotes 后，我取消了 Bear 的年度订阅，我开始在 Tiddlywiki 里构建更符合当下需求的笔记流程，而当我需要查找之前的记录时，可以随时打开 FSNotes 查找，至此，我正式向 Bear 告别了。
