[]byte不能直接转[N]byte，因Go将数组长度视为类型一部分，二者类型不兼容；编译器禁止赋值，copy(arr[:], src)是唯一安全通用解法。
Go 语言中，[]byte 转 [N]byte 不是零拷贝操作，必须显式复制；而 [N]byte 转 []byte 才是真正的零开销，只需用 arr[:]。
为什么 []byte 不能直接转 [N]byte？
因为 Go 的类型系统把数组长度当作类型的一部分：[32]byte 和 [16]byte 是完全不同的类型，[]byte 更是运行时长度可变的引用类型。编译器会直接拒绝 var arr [32]byte = mySlice 这类赋值——报错 cannot convert mySlice (type []byte) to type [32]byte。
这不是语法限制，而是设计使然：数组值必须在编译期确定大小，而切片长度只在运行时可知。
- 即使
len(mySlice) == 32，也不能绕过类型检查 -
unsafe强转虽技术上可行（如*[32]byte(unsafe.Pointer(&mySlice[0]))），但要求cap(mySlice) >= 32且底层数组未被复用，极易引发 panic 或静默错误 - 标准库和主流项目一律回避这种写法，
copy()是唯一安全通用解
用 copy() 安全构造 [N]byte
这是绝大多数场景该选的路：你要把 []byte 前 N 字节塞进一个固定大小的数组变量里（比如传给 crypto/sha256.Sum256 或硬件驱动接口），就得老老实实拷贝。
立即学习“go语言免费学习笔记（深入）”；
关键点在于：目标必须是数组的切片视图，即 arr[:]，而不是数组本身：
src := []byte("hello world")
var arr [5]byte
copy(arr[:], src) // ✅ 正确：dst 是 arr[:]，类型为 []byte
// arr 现在是 [104 101 108 108 111]（"hello" 的 UTF-8 字节）
- 如果
len(src) < 5，copy只拷前len(src)个字节，arr后半段保持零值，不 panic —— 这容易被忽略 - 别写
copy(arr, src)：编译失败，因为copy第一个参数必须是 slice - 别用
append([]byte{}, src...)拼：结果是[]byte，不是[N]byte
什么时候能用 unsafe.Slice 零开销取地址？
Go 1.17+ 提供了 unsafe.Slice，但它返回的是指针 *[N]byte，不是值；且仅在极少数前提下才真正“零拷贝”：
- 你**确定**
src的底层数组长度恰好是 N（即len(src) == cap(src) == N） -
src是从某个固定大小数组（如[32]byte）用[:]得来，从未被append扩容过 - 你只需要一个指向该内存的视图，而不是要赋值给一个独立的
[N]byte变量
示例（仅限底层库或极端性能场景）：
src := make([]byte, 32) // ... 填充 32 字节 p := unsafe.Slice((*byte)(unsafe.Pointer(&src[0])), 32) arr := *p // ✅ 此时才得到 [32]byte 值，但前提是 src 底层没扩容
日常业务代码中，这条路径风险远大于收益，copy(arr[:], src) 更直白、可读、安全。
常见误用和坑点
这几个地方最容易出错，而且错误不报编译期问题，只在运行时或逻辑上暴露：
-
Bar(Foo()[:])编译失败：因为Foo()返回的是临时值（unaddressable），无法取地址做切片 —— 必须先赋给局部变量再调[:] - 把
[]byte当字符串传给fmt.Printf("%s", b)没问题，但若其中含非法 UTF-8 字节（如 GBK 编码片段），输出会显示，这不是转换问题，而是格式化逻辑 - 对
[N]byte做arr[:] = append(arr[:], newByte)是危险操作：可能触发底层数组扩容，导致新元素写到新分配的内存，原数组不变 - 自定义类型如
type MyBytes []byte和[]byte可以互相强制转换（因底层结构一致），但type MyByte byte的切片[]MyByte和[]byte之间必须用copy或unsafe，无隐式转换
最常被忽略的一点：数组转切片是轻量的，但反向操作永远涉及数据移动或严格前提约束；别指望“一次转换，双向通行”。
