一樓說的很詳細(xì)了
補(bǔ)充一下個(gè)人觀點(diǎn)

使用如vuex,redux本身就是希望基于這樣一個(gè)數(shù)據(jù)結(jié)構(gòu)的約定，使得項(xiàng)目代碼更加直觀和簡單

所謂直觀和簡單是說：
每一個(gè)狀態(tài)樹對應(yīng)整個(gè)項(xiàng)目的一個(gè)狀態(tài)，而每次Mutation則代表了一次項(xiàng)目狀態(tài)的改變，為了能夠更加直觀地觀察到這樣的變化（使得我們能夠迅速追蹤或者說發(fā)現(xiàn)項(xiàng)目狀態(tài)的變化），我們使用flux這樣的框架思想去約定變化，使我們看代碼時(shí)一眼就能看出，這是一次狀態(tài)樹的變化

更貼合實(shí)際的一個(gè)例子就是
當(dāng)我們的項(xiàng)目出現(xiàn)bug時(shí)，要追蹤某一時(shí)刻查看在哪個(gè)過程中state的某個(gè)值出現(xiàn)了問題，我們可以直接去約定的mutation-type表中去找每次狀態(tài)的變化，變了什么或者說是怎么變的，方便更快速地定位問題和分析問題

個(gè)人覺得
如果不想使用這樣的約定，就不要用vuex,redux之類，直接在根入口自定義一個(gè)全局空間，其他子模塊統(tǒng)一訪問全局空間就行了

從效果上來說沒有影響但是不建議這么做.談一下我的理解.

vuex 從功能上來說就是一個(gè)前端緩存系統(tǒng).
解決了 SPA 不同組件之間數(shù)據(jù)共享的問題

那么到底如何用,為什么會存在 mutation 等概念呢?

你可以看一下官方文檔示例 shopping-cart.

這個(gè)范例模擬電商中,添加商品到購物車,并進(jìn)行結(jié)算的邏輯.
核心邏輯包括.

1. 拉取產(chǎn)品列表并顯示
2. 點(diǎn)擊添加到購物車
3. 進(jìn)行結(jié)算.

站在用戶的角度,用戶只做了兩件事

1. 將商品添加到購物車
2. 結(jié)算

在這里,添加商品會修改購物車的顯示.
最簡單的做法就把這些數(shù)據(jù)都放在父組件.

但是看一下官方示例如何實(shí)現(xiàn)的.
定義了兩個(gè)組件

• ProductList.vue 用來加載商品列表
• ShoppingCart.vue 處理結(jié)算的問題

那么組件數(shù)據(jù)呢?全部放在了 vuex 中進(jìn)行管理.
為什么要這么做,為什么不直接放在父組件里面呢?

1. 更清晰的代碼結(jié)構(gòu),每個(gè)組件都有自己的職責(zé),不必為了實(shí)現(xiàn)不同組件之間的交互而定義額外的數(shù)據(jù)總線或產(chǎn)生一個(gè)數(shù)據(jù)龐大的父組件來作為周轉(zhuǎn)
2. 可復(fù)用的邏輯,將常用的業(yè)務(wù)利用 vuex 拆分成基于狀態(tài)而非過程控制的代碼.
3. ...

我們把上面的邏輯利用狀態(tài)圖表示

可以看到這個(gè)邏輯異常清晰.

在回到問題本身直接修改有什么危害?

從功能上說沒有危害,但是從代碼構(gòu)建角度是沒有理解 vuex 這個(gè)神器怎么用!!!

不要只把 vuex 當(dāng)做一種全局修改數(shù)據(jù)的工具.它的意義在于
把跨組件的交互拆分為基于狀態(tài)管理的處理模式,是更高層的邏輯抽象

針對此提一下一些使用技巧.
下回在用 vuex 時(shí)考慮如下問題:

1. 對于用戶層暴露的邏輯事件是什么?

   看購物車可已看出就兩個(gè)事件,添加商品,和結(jié)算

2. 這個(gè)事件會影響那些數(shù)據(jù)

然后把狀態(tài)圖畫出來,利用 vuex 中的語法編寫.

回到上面問題,假設(shè)現(xiàn)在用戶的購物車添加了收藏,取消等邏輯,此時(shí)對于你而言只是單純的增加了 mutations 和相關(guān)事件的狀態(tài)處理.數(shù)據(jù)結(jié)構(gòu)并沒有變化,這就是好的設(shè)計(jì),