fixed all _xx_ into *xx* (#727)

Author: Jinjiang

src/v2/cookbook/adding-instance-properties.md

@@ -157,7 +157,7 @@ Uncaught TypeError: Cannot read property 'split' of undefined
 
 ### 当没有使用模块系统时
 
-在**没有**模块系统 (比如 webpack 或 Browserify) 的应用中，存在一种_任何_重 JS 前端应用都常用的模式：一个全局的 `App` 对象。
+在**没有**模块系统 (比如 webpack 或 Browserify) 的应用中，存在一种*任何*重 JS 前端应用都常用的模式：一个全局的 `App` 对象。
 
 如果你想要添加的东西跟 Vue 本身没有太多关系，那么这是一个不错的替代方案。举个例子：
 

src/v2/cookbook/creating-custom-scroll-directives.md

@@ -101,7 +101,7 @@ Vue 为指令提供了丰富的选项，覆盖了绝大多数的常见用例，
 
 ## 真实的示例：为级联动画使用一个自定义滚动指令
 
-在创建一个风格统一的网站的过程中，你可能会发现你在很多区域复用了相同类型的动画逻辑。看起来我们创建一个非常特殊的自定义指令很简单对吧？好，通常情况下如果你想复用它，那么你_只需_在每次使用的时候对其进行一些小的改动即可。
+在创建一个风格统一的网站的过程中，你可能会发现你在很多区域复用了相同类型的动画逻辑。看起来我们创建一个非常特殊的自定义指令很简单对吧？好，通常情况下如果你想复用它，那么你*只需*在每次使用的时候对其进行一些小的改动即可。
 
 为了保持代码的精炼和易读，我们会传递一些预设参数，诸如我们向下滚动页面时动画的起始点和终止点。
 

src/v2/guide/instance.md

@@ -77,7 +77,7 @@ data: {
 }
 ```
 
-这里唯一的例外是使用 `Object.freeze()`，这会阻止修改现有的属性，也意味着响应系统无法再_追踪_变化。
+这里唯一的例外是使用 `Object.freeze()`，这会阻止修改现有的属性，也意味着响应系统无法再*追踪*变化。
 
 ```js
 var obj = {

src/v2/guide/migration.md

@@ -1084,7 +1084,7 @@ function pluralizeKnife (count) {
 
 ### 双向过滤器 <sup>替换</sup>
 
-有些用户已经乐于通过 `v-model` 使用双向过滤器，以很少的代码创建有趣的输入。尽管表面上很_简单_，双向过滤器也会暗藏一些巨大的复杂性——甚至促使状态更新变得迟钝影响用户体验。推荐用包裹一个输入的组件取而代之，这样以更显性且功能更丰富的方式创建自定义的输入。
+有些用户已经乐于通过 `v-model` 使用双向过滤器，以很少的代码创建有趣的输入。尽管表面上很*简单*，双向过滤器也会暗藏一些巨大的复杂性——甚至促使状态更新变得迟钝影响用户体验。推荐用包裹一个输入的组件取而代之，这样以更显性且功能更丰富的方式创建自定义的输入。
 
 我们现在做一次双向汇率过滤器的迁移作为示范：
 

src/v2/style-guide/index.md

@@ -238,7 +238,7 @@ props: {
 
 **总是用 `key` 配合 `v-for`。**
 
-在组件上_总是_必须用 `key` 配合 `v-for`，以便维护内部组件及其子树的状态。甚至在元素上维护可预测的行为，比如动画中的[对象固化 (object constancy)](https://bost.ocks.org/mike/constancy/)，也是一种好的做法。
+在组件上*总是*必须用 `key` 配合 `v-for`，以便维护内部组件及其子树的状态。甚至在元素上维护可预测的行为，比如动画中的[对象固化 (object constancy)](https://bost.ocks.org/mike/constancy/)，也是一种好的做法。
 
 {% raw %}
 <details>
@@ -270,7 +270,7 @@ data: function () {
 
 这里的问题在于，不要删除仍然会留在 DOM 中的元素。比如你想使用 `<transition-group>` 给列表加过渡动画，或想在被渲染元素是 `<input>` 时保持聚焦。在这些情况下，为每一个项目添加一个唯一的键值 (比如 `:key="todo.id"`) 将会让 Vue 知道如何使行为更容易预测。
 
-根据我们的经验，最好_始终_添加一个唯一的键值，以便你和你的团队永远不必担心这些极端情况。也在少数对性能有严格要求的情况下，为了避免对象固化，你可以刻意做一些非常规的处理。
+根据我们的经验，最好*始终*添加一个唯一的键值，以便你和你的团队永远不必担心这些极端情况。也在少数对性能有严格要求的情况下，为了避免对象固化，你可以刻意做一些非常规的处理。
 
 {% raw %}</details>{% endraw %}
 
@@ -371,8 +371,8 @@ computed: {
 
 我们将会获得如下好处：
 
-- 过滤后的列表_只_会在 `users` 数组发生相关变化时才被重新运算，过滤更高效。
-- 使用 `v-for="user in activeUsers"` 之后，我们在渲染的时候_只_遍历活跃用户，渲染更高效。
+- 过滤后的列表*只*会在 `users` 数组发生相关变化时才被重新运算，过滤更高效。
+- 使用 `v-for="user in activeUsers"` 之后，我们在渲染的时候*只*遍历活跃用户，渲染更高效。
 - 解藕渲染层的逻辑，可维护性 (对逻辑的更改和扩展) 更强。
 
 为了获得同样的好处，我们也可以把：
@@ -402,7 +402,7 @@ computed: {
 </ul>
 ```
 
-通过将 `v-if` 移动到容器元素，我们不会再对列表中的_每个_用户检查 `shouldShowUsers`。取而代之的是，我们只检查它一次，且不会在 `shouldShowUsers` 为否的时候运算 `v-for`。
+通过将 `v-if` 移动到容器元素，我们不会再对列表中的*每个*用户检查 `shouldShowUsers`。取而代之的是，我们只检查它一次，且不会在 `shouldShowUsers` 为否的时候运算 `v-for`。
 
 {% raw %}</details>{% endraw %}
 
@@ -575,7 +575,7 @@ computed: {
 
 Vue 使用 `_` 前缀来定义其自身的私有属性，所以使用相同的前缀 (比如 `_update`) 有覆写实例属性的风险。即便你检查确认 Vue 当前版本没有用到这个属性名，也不能保证和将来的版本没有冲突。
 
-对于 `$` 前缀来说，其在 Vue 生态系统中的目的是暴露给用户的一个特殊的实例属性，所以把它用于_私有_属性并不合适。
+对于 `$` 前缀来说，其在 Vue 生态系统中的目的是暴露给用户的一个特殊的实例属性，所以把它用于*私有*属性并不合适。
 
 不过，我们推荐把这两个前缀结合为 `$_`，作为一个用户定义的私有属性的约定，以确保不会和 Vue 自身相冲突。
 
@@ -1798,7 +1798,7 @@ button {
 
 一个理想的 Vue 应用是 prop 向下传递，事件向上传递的。遵循这一约定会让你的组件更易于理解。然而，在一些边界情况下 prop 的变更或 `this.$parent` 能够简化两个深度耦合的组件。
 
-问题在于，这种做法在很多_简单_的场景下可能会更方便。但请当心，不要为了一时方便 (少写代码) 而牺牲数据流向的简洁性 (易于理解)。
+问题在于，这种做法在很多*简单*的场景下可能会更方便。但请当心，不要为了一时方便 (少写代码) 而牺牲数据流向的简洁性 (易于理解)。
 
 {% raw %}<div class="style-example example-bad">{% endraw %}
 #### 反例