go中…t是独立类型而非语法糖，与[]t不等价，必须用slice…展开；…t参数须位于参数列表末尾且唯一；类型安全选…String，灵活通用选…interface{}。
Go 里 ...T 不是语法糖，是独立类型
Go 的变长参数不是“自动转成切片”再传进去，而是函数签名里明确声明的 ...T 类型——它和 []T 并不等价，不能直接互换。你写 func f(args ...string)，调用时传 f([]string{"a", "b"}) 会报错：cannot use []string as type string in argument to f。
常见错误现象：把切片直接塞进变参函数，以为能自动展开；或者在封装函数时试图“转发”变参但漏掉 ...。
- 正确展开切片：用
f(slice...)，末尾三个点是必须的 - 接收变参后想当切片用？可以，
args在函数体内就是[]T类型 - 如果函数只接受
...Interface{}，传int或string没问题；但传[]int就得写成[]int{1,2}...才算展开
什么时候该用 ...interface{}，什么时候用 ...string
选哪个取决于你是否需要类型安全或运行时灵活性。...string 编译期就检查类型，性能好、意图清晰；...interface{} 灵活但要经历接口装箱，且取值时得断言。
使用场景举例：
立即学习“go语言免费学习笔记（深入）”；
- 日志函数如
log.printf必须用...interface{}，因为格式化字符串后面可能是任意类型 - 拼接路径函数
filepath.Join用...string，天然拒绝非字符串输入，也不需要运行时判断 - 如果只是做“收集参数然后统一处理”，又不确定类型，别硬套
...interface{}——先想清楚要不要类型检查，再决定
...T 参数必须放在参数列表最后，且只能有一个
这是 Go 语法硬性限制。你没法写 func f(x int, args ...string, y bool)，编译直接报错：cannot use ...string after int。
容易踩的坑：
- 想“中间插一个变参”？不行。要么全放最后，要么拆成两个函数
- 多个变参？比如
...string, ...int？语法不允许，Go 不支持重载，也没必要 - 如果确实需要混合参数（比如配置项 + 可变数据），用结构体封装前导参数，变参仍放最后：
func f(cfg Config, items ...Item)
性能敏感场景下，避免无谓的切片分配
每次调用变参函数，Go 都会为 ...T 分配一个新切片（哪怕只传一个元素）。对高频调用函数（比如循环内打日志），这会产生额外 GC 压力。
实操建议：
- 如果确定最多就 1–3 个参数，考虑重载函数，比如
add(a, b int)和add3(a, b, c int)，绕过变参开销 - 如果必须用变参，且调用方常传固定长度切片，可复用底层数组（如用
sync.Pool管理临时切片），但要注意别逃逸到堆上 - 用
go tool compile -gcflags="-m"看变量是否逃逸，确认变参是否真引起分配
变长参数看着简单，但类型边界、内存分配、语法位置这几个点一旦搞混，轻则编译失败，重则运行时 panic 或性能毛刺——尤其在封装底层库或写工具函数时，多看一眼函数签名里的 ... 到底落在哪、类型是什么，比查文档还管用。