再正经地说一下：如果你目前的技能水平足以应付日常工作，而你想提升自我但不知道方法 /方向，也许你需要找个人带一带（不论是对方带你还是你带对方），或者换个更有挑战性的工作。

根据马斯洛需求层次理论，当你需要通过前端技能谋求生存时、可以通过前端技能获得认同时、可以通过前端技能获得快乐或成就感时，你自然就有动力了。

Filco 87 红 + Logi MX Anywhere 2s

@dk1070 #87
其实我觉得 Magic Keyboard 还是挺好用的，虽然按键手感跟机械键盘明显不同（谈不上优劣），但大多数机械键盘的键位布局是面向 Windows 的，用快捷键时略难受，这时 Magic Keyboard 就显得舒服多了。

以前是太粗糙了，缺少设计感。现在是抽象过头了，看着像少儿编程界面……

@zazalu #108 同不理解为什么把这里 if 掉还不给个提示，父节点发生变化不应当是个常见场景啊

@leemove #88 不认为是 insertBefore，因为元素本身并没有被从 DOM 树中移除，如果 insertBefore 了应当还可以渲染出来（只是不在正确的位置）

@zazalu #84
如果没有前端知识基础，我建议不要挖掘框架源码，容易事倍功半还打击积极性。

我尝试简单地解释一下情况：

一个页面可以看做是由节点组成的树，更新页面内容就是在对一个或多个节点做属性更新。Vue 这类框架提供的功能是，你提供内容数据的定义（状态）和节点结构的描述（模板），它来自动更新节点属性。这个功能能够正常发挥作用的前提是，你不要替它更新节点属性，否则当它需要「在第 3 和第 4 个节点之间插入一个新节点」时，发现预期的第 4 个节点不存在了，它就迷茫了。你遇到的问题就是，组件模板的一部分在 Vue 掌控之外发生了变化，因此导致 Vue 产生了错误的视图更新结果。

@azh7138m #81
那好歹打个 warning 啊，DOM update 失败应该是挺值得关注的情况啊（

@shintendo #79
Directive 提供了直接访问 DOM 的能力，但在「数据驱动视图」的思路下，直接修改 DOM 的做法应该是不被建议的（否则为了保证渲染结果符合预期就得全面比对 DOM 树，性能不行）。这次这个锅不能算 iView 的，应该是恰好碰到了 Vue 视图机制的雷区。

AntD 分布表单是哪个？

楼主如果想保留组件模板的相对结构，可以把 v-for 部分或者 Drawer 部分包裹一个元素，或者在二者之间放一个 v-if="false" 的元素，总之就是不要让不稳定的 DOM 节点紧跟在 v-for 后面，这样就能让 v-for 效果正常。

问题出在 iView 的 v-transfer-dom 上，源码第 27 行通过 Node.replaceChild( ) 将原本是组件根元素的元素替换为一个注释节点（实际上替换成任意节点都可以复现问题）。v-for 的逻辑其实正常执行了，新的元素也生成了（可以通过 $refs 访问），但没有正确 attach 到 DOM 树中。怀疑这个过程紧挨着 v-for 后面发生会影响 VDOM Diff ？不确定这算不算 Vue 的 bug，等 dalao 进一步解析。
/cc @liximomo @sodatea

@lxmfly123 #63 @Sendya #64
Not personal，但我也是建议别用 iView，bug 目前看起来还是有点多。

@liximomo #47 Mac + Chrome 复现问题了。尝试移除里面用到的 iView Drawer 组件就可以解决问题，初步怀疑是 iView 做了什么。

表示不能复现问题。

现在用 Tailwind CSS，自带了 Tailwind Preflight （基于 Normalize.css ）

在上车 Setapp 之前一直用的 AppCleaner，虽然没上 MAS，但是挺好用的