是的，[3]int和[4]int是完全不同的类型，长度是go数组类型签名的一部分，影响赋值、传参、结构体字段、泛型约束及const表达式等所有场景。
数组长度是否参与类型构成
是的，[3]int 和 [4]int 是完全不同的类型，不能互相赋值或传参。Go 把长度当作类型签名的一部分，不是“元信息”或运行时属性。
常见错误现象：cannot use arr (type [3]int) as type [4]int in assignment —— 看似只是多一个元素，但编译器直接拒绝。
- 声明时必须写明长度，
[0]int、[1]byte、[100]struct{}都是独立类型 - 函数参数若接收
[5]string，你传[5]string可以，传[]string（切片）不行，传[4]string更不行 - 结构体字段用数组时，长度也固化类型：
type Packet struct { header [4]byte; data [64]byte }中两个字段类型互不兼容
什么时候该用 [N]T 而不是 []T
用固定长度数组的核心场景是：需要编译期确定内存布局、避免分配、或与 C 交互；绝大多数业务逻辑应优先用切片。
典型使用场景：
立即学习“go语言免费学习笔记（深入）”；
- Cgo 导出/导入结构体，如
struct{ id [16]byte }对应 C 的uint8_t id[16] - 哈希计算中固定大小缓冲区：
var buf [32]byte配合sha256.Sum256 - 小且确定的查找表，比如
[7]string{"Sun", "Mon", ..., "Sat"}，避免切片头开销
性能影响：数组值传递是整体拷贝，[1024]int 传参会复制 8KB；而 []int 传参只传 24 字节头。别下意识把大数组当参数传。
len() 对数组和切片的行为差异
len() 对数组返回编译期常量，对切片返回运行时字段值——这导致它们在泛型约束、const 表达式中的可用性完全不同。
- 你可以写
const n = len([5]int{})，但不能写const n = len([]int{1,2,3})（报错：invalid const expression） - 泛型约束中，
type T interface{ ~[5]int }是合法的；但~[]int无法约束长度，只能约束底层类型 -
switch len(arr)编译期就能优化掉；switch len(slice)是运行时分支
容易踩的坑：以为 len(x) 总是“安全”，但在 const 或泛型上下文中，数组长度可推导，切片长度不可。
数组字面量和比较的隐含规则
数组支持直接比较（前提是元素类型可比较），且字面量语法会自动推导长度，但仅限顶层声明或初始化时。
-
a := [3]int{1,2,3}→ 推导出[3]int；但b := [3]int{1,2}编译失败（缺少元素） -
c := [...]int{1,2,3}→ 自动算出长度为 3，类型是[3]int；这种写法只在初始化时有效 -
[2]int{1,2} == [2]int{1,2}返回true；但[2]int{1,2} == [3]int{1,2,0}编译不通过（类型不同） - 注意：指针数组如
[2]*int可比较，但比较的是指针值，不是所指内容
最易忽略的一点：数组相等性比较是深度逐元素比，没有短路；如果元素是结构体且含不可比较字段（如 map），整个数组就不可比较——这点比切片更严格。
