Goアプリケーションを作成する際によくあることですが、またはを使用する[]byteかどうかを選択できますstring。の明らかな可変性とは別に、[]byteどちらを使用するかをどのように決定しますか？
例としていくつかのユースケースがあります。
[]byte。スライス容量が固定されているので、文字列を返さない理由は何ですか？[]byteデフォルトほどうまく印刷されないので、ロギングの目的でstringキャストすることがよくあります。stringそれは常にあるべきでしたstringか？[]byteすると、常に新しい基になる配列が作成されます。付加するデータが一定である場合、なぜこれはそうではないのstringですか？私のアドバイスは、テキストを操作するときはデフォルトで文字列を使用することです。ただし、次のいずれかの条件が当てはまる場合は、代わりに[]byteを使用してください。
[]バイトの可変性により、必要な割り当ての数が大幅に削減されます。
[] byteを使用するAPIを扱っているので、文字列への変換を避けるとコードが単純化されます。
Goでは、他のどの非MLスタイルの言語よりも、タイプが意味と使用目的を伝えるために使用されていると感じました。したがって、使用するタイプを判断する最良の方法は、データが何であるかを自問することです。
文字列はテキストを表します。ただのテキスト。エンコーディングは心配する必要はなく、「文字」が実際にそうであるかどうかに関係なく、すべての操作は文字ごとに機能します。
配列は、バイナリデータまたはそのデータの特定のエンコーディングを表します。[]byteこれは、データが単なるバイトストリームまたはシングルバイト文字のストリームのいずれかであることを意味します。[]int16整数ストリームまたは2バイト文字のストリームを表します。
バイトを処理するほとんどすべてに文字列を処理する機能もあり、その逆もあるという事実を考えると、データを処理する必要があるかどうかを尋ねる代わりに、そのデータが何を表すかを尋ねることをお勧めします。そして、ボトルネックを見つけたら、物事を最適化します。
編集：この投稿は、型変換を使用して文字列を分割する理由を得た場所です。
1つの違いは、返さ[]byteれたデータを別の/新しいデータ（新しいメモリ割り当てなし）を保持するために再利用できる可能性がある一方で、
stringできないことです。もう1つは、少なくともgcの実装でstringは、。よりも1ワード小さいエンティティであるということです[]byte。そのようなアイテムがたくさんあるときに、メモリを節約するために使用できます。
ロギングのため[]byteにtoをキャストする必要はありません。stringのような典型的な「テキスト」動詞は%s、表現と表現に等しく%q機能します。他の方向では、同じことが例えばまたはに当てはまります。string[]byte%x% 02x
連結が実行される理由と、結果が後で何か/他の場所と再び結合されるかどうかによって異なります。その場合は、[]byteパフォーマンスが向上する可能性があります。