總而言之：為什么它們是無序的？實際值存儲在內(nèi)存中的什么位置？在深入研究運行時包后，我發(fā)現(xiàn)底層地圖結(jié)構(gòu)如下：// A header for a Go map.type hmap struct {? ? // Note: the format of the hmap is also encoded in cmd/compile/internal/gc/reflect.go.? ? // Make sure this stays in sync with the compiler's definition.? ? count? ? ?int // # live cells == size of map.? Must be first (used by len() builtin)? ? flags? ? ?uint8? ? B? ? ? ? ?uint8? // log_2 of # of buckets (can hold up to loadFactor * 2^B items)? ? noverflow uint16 // approximate number of overflow buckets; see incrnoverflow for details? ? hash0? ? ?uint32 // hash seed? ? buckets? ? unsafe.Pointer // array of 2^B Buckets. may be nil if count==0.? ? oldbuckets unsafe.Pointer // previous bucket array of half the size, non-nil only when growing? ? nevacuate? uintptr? ? ? ? // progress counter for evacuation (buckets less than this have been evacuated)? ? extra *mapextra // optional fields}buckets- 是存儲桶數(shù)組，其中索引是鍵哈希的低位位，其中存儲桶是：// A bucket for a Go map.type bmap struct {? ? // tophash generally contains the top byte of the hash value? ? // for each key in this bucket. If tophash[0] < minTopHash,? ? // tophash[0] is a bucket evacuation state instead.? ? tophash [bucketCnt]uint8? ? // Followed by bucketCnt keys and then bucketCnt elems.? ? // NOTE: packing all the keys together and then all the elems together makes the? ? // code a bit more complicated than alternating key/elem/key/elem/... but it allows? ? // us to eliminate padding which would be needed for, e.g., map[int64]int8.? ? // Followed by an overflow pointer.}..好吧，它只是一個數(shù)組，uint8其中每個項目都是密鑰散列的第一個字節(jié)。鍵值對存儲為key/key value/value（每個桶八對）。但具體在哪里呢？考慮到映射可能包含（幾乎）任何類型的值。應(yīng)該有某種指針放置在存儲值數(shù)組的內(nèi)存中，但bmap沒有此類信息。由于密鑰的哈希值位于存儲桶內(nèi)的有序數(shù)組中，為什么每次我循環(huán)遍歷地圖時它的順序都不同？