写一点我关于这个功能的看法：

这个功能的核心并不是把两个文档的正文进行合并，因为这个完全可以手动完成，而且也不算麻烦，核心在于把一个文档块的反链转移到另一个文档块上，这个是在思源软件本体中目前做不到的，而且在思源的架构之下，完全不用局限在文档块，任何类型的块的反链都可以转移，因此我认为这个功能更准确的叫法应该是“反链转移”，可以在两个文档块之间转移，可以在文档块和非文档块之间转移，可以在两个非文档块之间转移，在思源里实现这个功能可以比roam更加灵活。

目前可以直接操作底层文件来实现这个功能，比如我想把块A的反链转移到块B上，只需全局搜索块A的id，然后替换除了定义块A之外的搜索结果为块B的id。但操作底层文件有风险，而且必须要关掉软件后操作，还要等待很长时间的从零开始的重建索引，因此需要思源软件本体给出这个功能。roam里面实现合并文档时其实也是类似的做法，不过它们合并page时没有id的概念，直接全局替换[[page1]]为[[page2]]即可，和全局替换id是类似的。

我认为这个功能最终实现起来是这样的：首先用户给出两个块：块A与块B，用户想要把块A的反链转移到块B上，然后软件自动将所有引用块A的地方改成引用块B，最后，如果引用处是静态锚文本则锚文本不变，如果是动态锚文本则锚文本随之改变。

反链转移之后，如果识别到是文档块和文档块之间的转移，可以考虑再多一步，也就是把文档块A的正文移动到文档块B中，此时可以给出弹窗，例如“识别到是文档块之间的反链转移，是否要移动正文？”，如果用户点击确定，则转移，否则不转移。roam里面必须转移其实是因为roam里面不能有同名文档，而思源里面可以存在同名文档，且思源里面还可以直接实现非同名文档之间的反链转移，没有必要一定要转移正文。

其实之前实现的标题块和文档块互转、列表项块转化为文档块，是“反链转移”功能的应用，可以视为“反链转移”对于特定场景下转移时的便捷交互形式。例如，我想把标题块“ABC”变成文档块《ABC》，我可以先创建文档块《ABC》，然后把标题块“ABC”下的内容移动到文档块《ABC》中，然后把标题块“ABC”的反链转移到文档块《ABC》中，之前实现的“标题块转文档块”是把上面这个步骤打包成一个拖拽动作（当然，本质上反链转移是改变引用块处的id，而标题转文档改变的是定义块处的id，但最终效果是一样的，毕竟id对用户来说是透明的）