計算機 1byte=8bit
utf8 格式 1個英文本元是1byte，1個數字是1byte（0-9）
這個是相對於字元編碼來說的
而**裡的資料型別不同
go資料型別：
int=int64 =用64位bit表示乙個int也就是8個位元組byte，int的取值範圍為-2的31次方到2的31次方（-21 4748 3648 ~ 21 4748 3647 ）
rune的底層是uint32，所以rune佔4個位元組，用4個位元組表示乙個字元，所以它可以表示的字元更多，比如中文。
byte底層是uint8，所以byte佔1個位元組，byte代表的是ascii碼裡的字元
string的是有多個byte切片組成的
//type stringstruct struct切片的底層是slice的底層乙個struct，具有cap, length, ptr三個屬性
//type slice struct結構體存在記憶體對齊
unsafe.sizeof 是變數的型別的所占用的記憶體，而不是變數本身的記憶體
比如變數 a 是string型別，string型別是 乙個stringstruct結構體 佔16位元組，而string變數本身
切片是一種引用型別，乙個切片是由指標 ，長度，容量表示，引用的是陣列索引指標指向 陣列的乙個位址，而len只是這個切片的長度，所以切片變數本身的記憶體大小就是sizeof的值。只是在記憶體中還有個陣列
字串本身是多個byte組成的，本身也是一種引用，stringstruct由乙個指標位址和長度組成，string宣告好了就是乙個固定的數值，不能修改，如果要修改 要轉換成byte修改
總結 資料
標準Go專案布局
了解 standard go project layout，順便了解下 k8s 的 layout。平時工作也會看k8s 但是說實話對了k8s的目錄設計不是很明白，不是特別明白每個目錄檔案下面存放什麼內容，最近看了kubernetes原始碼剖析，才了解到 standard go project lay...
GO 記憶體對齊
之前遇到過這樣乙個情況 發現問題的結構體並不長這樣,不過為了引出問題,改了一下 type test structfunc main fmt.printf d unsafe.sizeof t 建立乙個結構體,檢視一下其記憶體占用.看結果前先簡單算一下 這麼算下來的話,test結構體占用應該是 1 4 ...
go 記憶體分配
二者都是在堆上分配記憶體，但是它們的行為不同，適用於不同的型別 new 函式分配記憶體，make 函式初始化 new t 為型別t分配一塊記憶體，並返回指向這塊記憶體位址的指標，它適用於值型別如陣列和結構體 make t 初始化內建的資料結構，返回乙個型別為 t 的空值，它只適用於3種內建的引用型別...