使用字节包而不是字符串有什么好处？答案

【问题标题】：What's the benefit of using bytes package over strings?使用字节包而不是字符串有什么好处？
【发布时间】：2016-10-29 16:49:21
【问题描述】：

http://play.golang.org/p/CZTmhNepkM

有人可以解释为什么我们需要字节吗？例如在 go playgound 上，我正在做同样的事情，但字符串包比字节更容易使用。为什么我们有字符串包时，有人需要字节包来实现 HasSuffix 功能？

 strings.HasSuffix(word, "ed")
 bytes.HasSuffix(word_byte, []byte("ed"))

【问题讨论】：

标签： go

【解决方案1】：

一个重要的答案是性能。在进行this bioinformatics task（最快的Go代码here）等海量字符串处理时，字节切片API是必须的。

【讨论】：

【解决方案2】：

在 Go v1.0 之前，没有 rune 类型。这就是为什么标准库中处理部分字符串或迭代“字符”的某些方法会采用字节切片（而不是符文切片）。

由于许多方法采用字节切片并避免不断转换为字符串并返回 - 两种类型都存在一些基本功能。

【讨论】：

值得注意的是，从string 到[]byte 的转换总是O(n)，因为它需要一个完整的副本（字符串是不可变的，而[]byte 是可变的）。由于这很昂贵，因此仅提供用于操作 []byte 而不转换为 string 的函数是合乎逻辑的。
添加到@nemo — 通常你会想用[]byte 完成所有繁重的工作，然后在最后使用string 以尽量减少复制。
还有一个问题，由于大多数文本处理以字符串格式获取原始数据，将字符串格式的原始数据转换为字节格式并进行处理并将其转换回输出字符串？应该没问题吧？

【解决方案3】：

Go 1.8 通过优化其对 ASCII 集的使用进一步改进了字节包。

见commit 9a8c695 Joe Tsai (dsnet)

> `bytes`, `strings`：针对 ASCII 集进行优化

在 Google 的大型代码库中，有数千种用途：

ContainsAny|IndexAny|LastIndexAny|Trim|TrimLeft|TrimRight

对其用法的分析表明，超过 97% 的人只使用字符仅由 ASCII 符号组成的集合。

Uses of ContainsAny|IndexAny|LastIndexAny:
     6% are 1   character  (e.g., "\n" or " ")
    58% are 2-4 characters (e.g., "<>" or "\r\n\t ")
    24% are 5-9 characters (e.g., "()[]*^$")
    10% are 10+ characters (e.g., "+-=&|><!(){}[]^\"~*?:\\/ ")

我们针对 ASCII 集进行了优化，这些集通常用于在某些字符串中搜索“控制”字符。我们不针对单字符场景进行优化，因为可以使用 IndexRune 或 IndexByte

【讨论】：

> bytes, strings：针对 ASCII 集进行优化

> `bytes`, `strings`：针对 ASCII 集进行优化