go接口中不能定义变长参数方法，因接口只支持固定签名，…t与[]t是不同函数类型，必须显式声明为[]t；实现时可用…t但调用需传切片或展开。
Go 接口里不能直接定义变长参数方法
Go 的接口只声明方法签名，而 func(...T) 这种变长参数语法是函数实现层面的特性，接口本身不支持在方法签名中写 ...T。你写 Do(args ...String) 到接口里，编译会报错：invalid use of '...' —— 因为接口方法签名不允许省略号语法。
真正能用的只有固定参数形式，比如 Do(args []string) 或 Do(arg1 string, arg2 string)。想“模拟”变参，得靠切片传入。
- 接口方法必须显式声明为接收
[]T，不是...T - 实现该接口的结构体方法可以写成
func (s *S) Do(args ...string)，但这是实现细节，和接口声明无关 - 调用方仍需传切片（如
s.Do([]string{"a", "b"})），或用...展开：s.Do(args...)
为什么不能在接口里写 ...T？
Go 接口的底层机制依赖方法签名的精确匹配。而 func(...T) 和 func([]T) 在类型系统里是两个完全不同的函数类型 —— 前者是变参函数类型，后者是普通切片参数函数类型。接口要求所有实现必须有**完全一致的签名**，没法兼容两种语义。
举个反例：如果允许接口写 Do(...string)，那实现时写 Do([]string) 就该算满足，但 Go 明确禁止这种隐式转换，避免调用歧义和反射混乱。
立即学习“go语言免费学习笔记（深入）”；
-
func f(...string)和func f([]string)互不赋值，reflect.Type也不同 - 接口方法签名一旦定下，所有实现必须字面级一致（包括参数名可忽略，但类型、数量、顺序、是否变参都算）
- 这不是设计疏漏，而是 Go 类型系统“显式优于隐式”的体现
实际怎么写才能既灵活又符合接口约束
最常用且无坑的做法：接口声明用 []T，具体实现用 ...T，调用时按需展开。这样既保持接口干净，又保留调用便利性。
// 接口只能这么写 type Runner interface { Run(args []string) } <p>// 实现可以这么写（更友好） type Cmd struct{} func (c Cmd) Run(args ...string) { // 内部直接用 args，它就是 []string fmt.Println("running with:", args) }</p><p>// 但注意：上面这个实现 <em>不满足</em> Runner 接口！ // 因为 Run(...string) ≠ Run([]string)正确实现：
func (c Cmd) Run(args []string) { // 必须匹配接口签名 fmt.Println("running with:", args) } // 调用方想传多个值？手动转切片或展开： c.Run([]string{"ls", "-l"}) c.Run(append([]string{"cp"}, src, dst)...)- 别试图让一个方法同时满足
Run(...string)和Run([]string)接口 —— 不可能 - 如果真需要多种调用风格，加一个辅助函数封装，比如
RunE(cmd string, args ...string)，但它不属于接口一部分 - 性能上没区别：
...T在调用侧只是语法糖，底层仍是切片传递
容易被忽略的兼容性陷阱
很多人以为把 args ...string 改成 args []string 是“等价替换”，其实会在边界场景出问题。
- 空参数调用：
f()在变参函数里合法，但f([]string{})或f(nil)需要明确区分 —— 后者可能触发 nil panic - 反射调用时，
reflect.Value.Call()传参必须严格匹配接口声明类型，[]string不能自动转成...string - 第三方库（比如
testify/mock）生成 mock 时，会按接口签名生成方法，不会给你加...，所以 mock 调用也必须传切片
最稳妥的方式，是从一开始就把“变长”理解为“切片可变”，而不是语法上的省略号 —— Go 的哲学里，... 是给调用方省事的，不是给接口设计留后门的。