Go中数组长度是类型的一部分，[3]int与[4]int是不同类型，不可互赋；数组为值类型，赋值即拷贝全部元素；长度必须编译期确定，不能为变量；传大数组性能差，应优先用切片或指针。
数组长度是类型的一部分，声明时就得写死
Go 里 [3]int 和 [4]int 是两种完全不同的类型，不能互相赋值，也不能用在同一个函数参数位置。这不是语法限制，而是类型系统设计决定的——编译期就确定内存布局，没法做隐式转换。
- 声明必须带长度：
var a [5]int合法，var a []int是切片，不是数组 - 初始化时如果用字面量省略长度，Go 会自动推导：
a := [3]int{1,2,3}等价于[3]int；但a := [...]int{1,2,3}的[...]是语法糖，实际类型仍是[3]int - 传参时注意：函数接收
[5]int，你传[5]int可以，传[4]int或[]int直接编译失败
数组是值类型，赋值=拷贝全部元素
和 C 不同，Go 数组变量本身包含所有元素数据，不是指针。所以 a := [3]int{1,2,3}; b := a 这行之后，b 是独立副本，改 b[0] 不影响 a。这对小数组没问题，但传大数组进函数会明显拖慢性能。
- 常见误判：以为
func f(a [1000]int)是“传引用”，其实是在栈上复制 1000 个 int（8KB） - 真实场景中，除非明确要值语义（比如校验 hash 前的原始数据快照），否则该用
[]int或指针：func f(a *[1000]int或func f(a []int) - 用
fmt.Printf("%p", &a)能看到每次赋值后地址不同，证实是拷贝
数组长度不能为变量，常量表达式也不行
const n = 5; var a [n]int 合法，但 var size = 5; var a [size]int 编译报错：invalid array bound size。因为数组长度必须在编译期确定，而运行时变量值不可知。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误现象：
undefined: cannot use variable as array bound - 替代方案只有两个：用切片（
make([]int, size)），或者把 size 提成 const（仅当它真能静态确定） - 注意：
const n = len("hello")合法（字符串字面量长度是编译期常量），但const n = len(someVar)不合法
遍历数组时，len() 返回固定值，但别和切片混淆
len(a) 对数组返回声明长度，永远不变；对切片才可能动态变。这个差异直接影响边界判断和循环逻辑，尤其在封装通用工具函数时容易出错。
立即学习“go语言免费学习笔记（深入）”；
- 写循环别硬编码数字：
for i := 0; i → 改成 <code>for i := 0; i ，哪怕 a 是数组 - 函数签名若接收
[5]int，内部调用len(a)永远是 5，但若改成接收[]int，同一段代码行为就变了 - 反射里
reflect.ValueOf(a).Len()对数组也返回固定长度，但reflect.ValueOf(a[:]).Len()返回的是底层数组长度——这种细节容易在序列化/反序列化时埋坑
数组看着简单，但类型绑定、值拷贝、长度约束这三点叠在一起，很容易在接口定义、函数传参、性能优化时漏掉某个前提。最常被忽略的是：你以为在操作一个“类似切片”的东西，结果它早就在传参那一刻完整复制了一份。
