Go中...T是独立类型修饰符而非语法糖，表示接收零个或多个T值并打包为[]T切片，必须位于参数列表末尾且唯一，传切片时需显式展开，接口方法不可声明...T参数。
Go 里 ...T 不是语法糖，是独立类型修饰符
Go 的可变参数不是“让函数多接收几个值”这么简单，... 是作用在类型前的修饰符，表示“接受零个或多个 T 类型值，并把它们打包成一个 []T 切片传入”。它和普通参数共存时有严格位置限制：必须是最后一个参数，且只能有一个。
- 错误写法：
func f(x int, args ...string, y bool)—— 编译报错：cannot use ... with non-final parameter - 正确写法：
func f(x int, args ...string)，调用时f(42)、f(42, "a")、f(42, "a", "b", "c")都合法 - 传切片进去要显式展开：
ss := []string{"x", "y"}; f(42, ss...)，漏掉...会类型不匹配
如何区分「传多个值」和「传一个切片」
这是最常混淆的点。Go 不允许自动将切片“当可变参数用”，必须手动加 ... 展开。否则编译器会认为你试图把一个 []string 当作单个 string 传给 ...string 参数——类型根本对不上。
- 现象：
func printAll(msgs ...string) { fmt.Println(msgs) }，若写printAll([]string{"a","b"})，报错：cannot use []string literal (type []string) as type string in argument to printAll - 正确做法：
printAll([]string{"a","b"}...)，此时...告诉编译器：“把这个切片拆开，每个元素当一个string传进去” - 如果函数签名是
func printSlice(msgs []string)，那才直接传[]string；两者语义完全不同，不能混用
性能注意：...T 每次调用都新建底层数组（除非逃逸分析优化）
虽然 args ...string 在函数内表现为 []string，但每次调用时，Go 会为传入的每个参数分配新空间并拷贝（小数据可能栈上分配，大数据逃逸到堆）。频繁调用且参数多时，GC 压力会上升。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 高频场景（如日志、调试打印）建议预分配切片再展开：
buf := make([]string, 0, 8); buf = append(buf, a, b, c); log(buf...) - 避免在循环里反复写
f("x", "y", "z")—— 看似简洁，但每次都在栈/堆上构造新切片 - 如果确定只传固定少量值（比如最多 3 个），考虑重载函数而非硬套
...，比如f1(a string)、f2(a, b string)，零分配
接口方法不能声明 ...T 参数
Go 接口定义方法时，签名必须完全可实现。而 ... 是语法层面的特殊处理，不是类型系统的一部分，所以接口里不允许出现。
立即学习“go语言免费学习笔记（深入）”；
- 错误：
type Logger interface { Println(v ...interface{}) }—— 合法，因为标准库就这么干？等等，不对：这是特例，fmt包的接口是io.Writer，Println是具体类型的导出方法，不是接口方法 - 真正限制是：你自定义接口时，
func Do(...string)会导致实现该接口的结构体无法满足——因为实现方法签名必须字面匹配，而...无法被普通函数签名实现 - 替代方案：接口方法用
Do(args []string)，调用方自己做args...展开；或者干脆不抽象，用函数类型type Handler func(...string)
... 看似灵活，但 Go 把它的边界划得很死：不自动转换、不支持重载、不进接口、不省内存。用之前先想清楚，是不是真需要“调用侧自由”，还是只是图省事写了三个点。 
