Go中string与[]byte如何高效互转
前言当我们使用go进行数据序列化或反序列化操作时，可能经常涉及到字符串和字节数组的转换。例如：ifstr,err:=json.Marshal(from);err!=nil{panic(err)}else{returnstring(str)}json序列化后为[]byte类型，需要将其转换为字符串类型。当数据量小时，类型间转换的开销可以忽略不计，但当数据量增大后，可能成为性能瓶颈，使用高效的转换方法能减少这方面的开销数据结构在了解其如何转换前，需要了解其底层数据结构本文基于go1.13.12string：typestringStructstruct{strunsafe.Pointerlenint}slice：typeslicestruct{arrayunsafe.Pointerlenintcapint}与slice的结构相比，string缺少一个表示容量的cap字段，因此不能对string遍历使用内置的cap()函数那为什么string不需要cap字段呢？因为go中string被设计为不可变类型（当然在很多其他语言中也是）,由于其不可像slice一样追加元素，也就不需要cap字段判断是否超出底层数组的容量，来决定是否扩容只有len属性不影响for-range等读取操作，因为for-range操作只根据len决定是否跳出循环那为什么字符串要设定为不可变呢？因为这样能保证字符串的底层数组不发生改变举个例子，map中以string为键，如果底层字符数组改变，则计算出的哈希值也会发生变化，这样再从map中定位时就找不到之前的value，因此其不可变特性能避免这种情况发生，string也适合作为map的键
go语言string之Buffer与Builder
操作字符串离不开字符串的拼接，但是Go中string是只读类型，大量字符串的拼接会造成性能问题。 拼接字符串，无外乎四种方式，采用“+”，“fmt.Sprintf()”,"bytes.Buffer","strings.Builder" 上面我们创建10万字符串拼接的测试，可以发现"bytes.Buffer","strings.Builder"的性能最好，约是“+”的1000倍级别。 这是由于string是不可修改的，所以在使用“+”进行拼接字符串，每次都会产生申请空间，拼接，复制等操作，数据量大的情况下非常消耗资源和性能。而采用Buffer等方式，都是预先计算拼接字符串数组的总长度（如果可以知道长度），申请空间，底层是slice数组，可以以append的形式向后进行追加。最后在转换为字符串。这申请了不断申请空间的操作，也减少了空间的使用和拷贝的次数，自然性能也高不少。 bytes
go的byte跟string有什么区别
go是前往，byte是8位无符号整数，string是字符串。 去，数据，字符。