看到里有不少水文…那…我也就有胆子来灌水了[不是]

然后…本文没啥实际用途，而且弄得比较仓促，有些为德不卒；加之我比较水，就…

其实不过是一个依据 commit 、 社区讨论进程了解源码的的一个碎片化记录，面试等情况是不会考这些的。

在咱们看源码的时分，有时会惊讶于：作者是怎么想到这个问题的？其实若盯梢其提交记录、讨论记录，也许能够协助咱们了解问题的发现与解决，见证作者的生长[doge]。

以上为本篇正文，感谢各位看官观摩，现在能够 Alt + F4 了[划掉]

咳…其实是某群里有位小伙伴问了一个问题，截图对应的代码如下：

  if ((key in vm) && isReserved(key)) {
    warn(
      `Method "${key}" conflicts with an existing Vue instance method. ` +
      `Avoid defining component methods that start with _ or $.`
    )
  }
}
vm[key] = typeof methods[key] !== 'function' ? noop : bind(methods[key], vm)

问道：

请问一下，isReserved是判别什么的

这显着是 Vue 的提示，所以去 Vue 的仓库（v2.6) 搜了一下这段代码所在的位置：

src\core\instance\state.js

function initMethods (vm: Component, methods: Object) {
  const props = vm.$options.props
  for (const key in methods) {
    if (process.env.NODE_ENV !== 'production') {
      if (typeof methods[key] !== 'function') {
        warn(
          `Method "${key}" has type "${typeof methods[key]}" in the component definition. ` +
          `Did you reference the function correctly?`,
          vm
        )
      }
      if (props && hasOwn(props, key)) {
        warn(
          `Method "${key}" has already been defined as a prop.`,
          vm
        )
      }
      if ((key in vm) && isReserved(key)) {
        warn(
          `Method "${key}" conflicts with an existing Vue instance method. ` +
          `Avoid defining component methods that start with _ or $.`
        )
      }
    }
    vm[key] = typeof methods[key] !== 'function' ? noop : bind(methods[key], vm)
  }
}

这个办法仅判别最初是否为 $ 或 _

经过正告内容可知，冒犯该规则的三个条件：

  1. 当前为非生产模式，一般来说是本地开发模式才会执行这些正告。这非常简单了解：类似于这些警报提示是面向开发者的，而非面向最终用户；
  2. 新的 key 已经在 Vue 实例中存在，接下来会掩盖已有的项目；
  3. 大家定义私有办法时喜欢以 $ 或 _ 最初，但 Vue 中恰恰也是以这俩作为私有办法的最初内容的，可能会引发抵触，所以需求警示开发者尽量不要这么做，以免造成不良影响，规范后续行为。这就是 isReserved 的判别。

能够这么了解：

isReserved 的作用是，在 Vue 实例发生命名抵触时(第2点)，提供一种参阅建议，来协助开发者接下来规避与 Vue 已有办法的抵触。

插曲：
为了更好地了解其间缘由，咱们能够了解一下其提交历史。VSCode 的话，能够合作 GitLens 检查该行对应的 commit.

Vue 2 仓库中，src/core/util/lang.js 有这个 isReserved 办法
注释内容为：

Check if a string starts with $ or _

从该文件第一次创立时就有了，对应的 commit 信息为 restructure，这儿不简单找线索。

到调用途 src/core/instance/state.js 上对应的commit 为：

chore:warn methods that conflict with internals. close #6312

顺着该 commit 打开对应的 issue：

www.github.com/vuejs/vue/i…

可见是讨论命名抵触的问题，不过没有讨论出很好的成果，仅仅一个开端。

后来尤大调整了这个战略，见该比对：
github.com/vuejs/vue/c…

也就是现在的样子。

在该 issue 的最终，其他的 issue 提及了该问题，顺着里边持续看 #7070
www.github.com/vuejs/vue/i…

这讨论算是完结了。

另：
相对应的，从风格攻略中有关于 $ 和 _ 的使用约定：
cn.vuejs.org/v2/style-gu…

对于这种私有情况，约定是以 $_ 为最初，这样就必然能够规避最初的报错了。

以上就是结合多种方式了解源码的一个小栗子。没什么难度，仅仅需求多点耐性，相信大家都能搞定的~

最终，以此也能发现严格要求 commit 格式的优点：方便其他团队成员追溯。提交时一般会使用 commit lint 进行预先校验，相关文章浩如烟海，本文就不赘述了。