2024w32

附件

我不爱用图片，但并不是不喜欢用图片表达，我只是不喜欢处理附件。相较于小尺寸的文本内容，各种附件简直是巨大的麻烦。但，这个问题好像有点回避不过去。开始思考怎么管理附件。

但如果叫附件，就会默认它们是笔记的附属品，依附笔记而存在。

是么？有一部分是的，比如一些笔记的插图，就是为了说明某一个特定问题的细节而存在的；某些配置文件，就是为了指定特定的工具的状态而存在的。当然，还有一部分是可以独立存在的内容。

如果，扩大一下来理解，这些都是文件，包括笔记，也是文件。那是不是我可以用一套文件管理方法来管理这一切呢。如果能将方法论统一，意味着管理规则的简化。

道理上，如果是记录一切的笔记，整体达到几个 GB 也一点都不奇怪。但如果真的到了这个大小，就得考虑一下同步问题了。虽然从长期的角度看，未来的网络速度下，几个 GB 的数据应该也只是小问题。

常见的处理方法是将笔记和附件分开，但我觉得同属于笔记，似乎还是放在一起更加符合我的直觉。但同步肯定是个问题。我觉得也许可以将它们放在一起，但是使用不同的同步策略。这肯定是可以做到的，但复杂度是不是我愿意接受的呢？

如果将附件放入笔记同名文件夹并和笔记同目录呢？是很合理，但是附件和笔记不是一体的，排序时文件夹和文件也是分开的，而且因为附件分散于各个目录，也不利于统一管理。但是附件远离笔记也会有很多问题。

而且一篇笔记可能引用多个附件，而一个附件也可能被多个笔记引用。Obsidian 可以处理第一种关系，但是对第二种关系却比较忽视。

归根结底——是人类对于描述和理解立体网状结构的无力感，但知识（相互间的引用关系）终究不是用一维或者或者二维可以清晰描述的。

如果说，我遇到的问题应该都不是新鲜问题，那我该参考什么呢……对了，网页中资源文件的处理方式。然后我开始理解：

思考了一大圈，结果一切又回到了最普通最常见的使用方法。对外的表现是几乎什么都没变化，但是我自己对这件事情的纠结减少了许多。