自定义Vue指令修改Element DOM与v-show冲突，能否通过修改vnode解决？

问题结论 #

直接修改vnode合并v-show逻辑技术上可行，但不推荐在生产环境大范围使用。

可行性说明 #

v-show本质是Vue内置指令，它的逻辑最终会将计算得到的显隐结果同步到vnode的样式属性中。你在自定义指令的beforeMount钩子中获取vnode时，确实可以读取vnode上绑定的v-show判断条件，将其和你的自定义显隐逻辑做与/或运算后，把最终结果更新到vnode的样式属性里，就能避免后续直接操作DOM被原生v-show覆盖的问题。

不推荐的原因 #

• 这部分属于Vue未公开的内部实现细节，Vue2和Vue3的vnode结构差异极大，即使同一大版本的不同小版本也可能调整vnode的属性存储规则，官方没有提供稳定API保证这部分结构长期不变，后续框架升级时大概率会出现兼容性问题，维护成本极高。
• 会导致显隐逻辑散落在模板v-show和自定义指令两处，后续维护代码的开发者很难第一时间定位到显隐异常的原因，代码可维护性大幅下降。

更稳妥的替代方案 #

• 方案1：逻辑抽成公共方法统一收口
  把自定义指令的显隐判断逻辑抽成全局公共方法checkShouldShow(组件标识, 运行时参数)，将原有模板的v-show修改为v-show="原有判断条件 && checkShouldShow(xxx, 运行时参数)"即可，虽然需要修改多处模板，但逻辑完全透明，没有黑盒操作，后续维护成本最低。
• 方案2：无侵入式优先级覆盖
  如果不想修改大量模板，可以将自定义指令的执行优先级设置为高于v-show，在指令的updated钩子中监听显隐状态变化，同时绑定MutationObserver监听元素的style属性变更，一旦检测到v-show修改了display/visibility值，就结合自定义指令的逻辑重新计算后覆盖样式。该方案属于轻量hack，有轻微性能损耗，但不需要侵入原有模板代码，也不依赖Vue内部vnode结构。
• 方案3（Vue3环境优先）：封装统一控制组件
  自定义一个<VisibilityWrapper>全局组件，接收原有v-show的判断条件作为prop，组件内部结合全局显隐逻辑计算最终的显隐状态，内部用原生v-show控制插槽内容的显隐。所有需要控制的组件只要外层套上该组件即可，逻辑聚合，符合Vue的组件化设计规范。

内容的提问来源于stack exchange，提问作者orange