讨论一下 可否在fromStore这个方法中 做一些优化呢

[wwt1995]

现状：当前如果存储HighlightSource的父级节点结构发生变化的话 会直接报错（目前应该是直接去匹配落点标签的） 预期：是否可以做一个缓冲的逻辑 在一定匹配次数内 优先匹配附近的几个节点再对比内容 如果一致则生成高亮 否则就不生成

[wwt1995]

我们的场景比较复杂 有一个动态的服务端高亮 可能每次高亮结果不同 就导致了页面结构的不确定性 如果划段时正好断在高亮的标签里 下次服务端高亮换词了 就导致了存储和页面结构无法对应上

[alienzhou]

确实，页面结构变动目前很容易导致上次做的高亮区域无法还原。 前面提到的缓冲逻辑是否能很好解决这个问题可能有待商榷：

• 一个是，页面结构变化可能导致根据标记找到的dom节点和原本位置相差极大。
• 另一个是，担心一些探测方法会在高亮还原出错时，还原结果与使用方预期不符，造成使用上的困惑。

---

此外，一种可能的解决方式是放弃目前的还原方法，通过纯文本内容匹配来决定高亮的位置。

[wwt1995]

确实，页面结构变动目前很容易导致上次做的高亮区域无法还原。 前面提到的缓冲逻辑是否能很好解决这个问题可能有待商榷：

• 一个是，页面结构变化可能导致根据标记找到的dom节点和原本位置相差极大。
• 另一个是，担心一些探测方法会在高亮还原出错时，还原结果与使用方预期不符，造成使用上的困惑。

此外，一种可能的解决方式是放弃目前的还原方法，通过纯文本内容匹配来决定高亮的位置。

确实，页面结构变动目前很容易导致上次做的高亮区域无法还原。 前面提到的缓冲逻辑是否能很好解决这个问题可能有待商榷：

• 一个是，页面结构变化可能导致根据标记找到的dom节点和原本位置相差极大。
• 另一个是，担心一些探测方法会在高亮还原出错时，还原结果与使用方预期不符，造成使用上的困惑。

此外，一种可能的解决方式是放弃目前的还原方法，通过纯文本内容匹配来决定高亮的位置。

实现起来确实比较繁琐 目前我的解决方案是在实例化的时候 添加一个忽略特定tag的callback（看到源码本来就有判断如果是高亮标签则找上一层父级）不过这只能解决可控的动态标签