> # 切片非線程安全，并發操作為啥不會像map一樣報錯 > # 切片的底層   > # 切片與 map 的底層結構差異 * **切片**：切片的底層是一個包含三個元素的數據結構：指向底層數組的指針、切片的長度以及切片的容量。切片本身是對底層數組的一個“視圖”。當你對切片進行操作時，主要是對這個底層數組的訪問。即使多個 goroutine 訪問同一個切片，Go 運行時不會進行額外的檢查。 * **map**：`map` 是一個復雜的哈希表結構，內部包含哈希桶、哈希沖突解決機制等。當多個 goroutine 并發地對同一個 map 進行讀寫時，由于 map 需要對內部哈希桶進行管理（如擴容、rehash 等操作），一旦多個 goroutine 同時修改這些共享的哈希桶，Go 運行時會檢測到數據競爭和一致性問題，因此直接拋出致命錯誤并終止程序運行。這也是為什么我們會看到類似 `fatal error: concurrent map writes` 的錯誤。 # 切片并發操作的行為 在切片的并發讀寫中，常見的行為有： * **數據競爭**：多個 goroutine 對切片進行并發讀寫操作時，Go 并不會進行額外的檢查，所以即使發生了數據競爭，也不會拋出類似 `map` 的錯誤。數據競爭可能會導致切片的數據不一致，但不會直接導致程序崩潰。 * **擴容引發的問題**：切片在追加元素時，可能觸發底層數組的擴容（即重新分配更大的內存空間，并復制原有數據）。在并發環境中，多個 goroutine 可能同時觸發擴容，這可能導致數據丟失或出現未定義行為，但通常不會觸發程序崩潰。 # Go 運行時錯誤檢查機制的差異 Go 運行時對 `map` 的并發操作有明確的檢查機制，因為 `map` 是一個更復雜的結構，并且在并發情況下更容易引發致命的不一致問題。Go 選擇在運行時拋出錯誤，以提醒開發者這個并發問題。 相比之下，切片的并發訪問沒有類似的檢查機制。雖然切片的并發操作也會引發數據不一致的問題，但這些問題不一定會導致程序立即崩潰，而是表現為數據錯亂或不符合預期的結果。這也是為什么并發讀寫切片不會像 `map` 那樣直接報錯終止程序。