Go变参函数必须将...置于参数列表末尾且仅能有一个，否则编译失败；应避免interface{}导致类型擦除，推荐用具体类型切片或Option函数实现类型安全、可校验的API。
Go里用...写变参函数本身不难，但真要靠它构建易用、难误用的API，必须配合类型约束和调用约定——否则很容易掉进“参数顺序模糊”“类型擦除后无法校验”“默认值逻辑散落各处”的坑里。
变参函数必须是最后一个参数，且只能有一个
这是语法硬限制，不是风格建议。Go编译器会直接报错：invalid use of '...'。一旦违反，连编译都过不去。
- 正确写法：
func DoSomething(name string, opts ...Option) - 错误写法：
func DoSomething(opts ...Option, timeout time.Duration)（编译失败） - 错误写法：
func DoSomething(a ...int, b ...string)（只允许一个...）
这个限制倒逼你把可选配置放在最后，天然符合“必填在前、可选在后”的直觉，但也会让某些场景（比如想先传一组标签再传配置）不得不绕路——这时候该考虑改用函数选项模式，而不是硬塞...。
避免用interface{}接收任意类型变参
虽然func PrintAll(v ...interface{})看着灵活，但它抹掉了所有类型信息，调用时无法静态检查，运行时容易panic，也丧失IDE自动补全和重构支持。
立即学习“go语言免费学习笔记（深入）”；
- 典型问题：
PrintAll("hello", 42, nil)——nil到底代表什么？字符串空值？还是故意跳过某个字段？没人知道 - 更糟的是：
PrintAll(user.Name, user.Age, user.Email)，如果user.Email是string指针且为nil，就会触发fmt包的nil pointer dereference - 替代方案：用具体类型切片，或封装成
Option函数（如WithTimeout(...)），让每个参数含义明确、类型安全
变参 + 函数选项组合使用才是生产级API的常见形态
纯变参适合日志、调试、批量操作这类“参数语义一致”的场景；而配置类API几乎都用...Option——因为每个选项含义不同，且需要默认值、校验、组合逻辑。
-
log.Printf用...interface{}没问题：所有参数都是待格式化的值，语义统一 -
http.ListenAndServe不用变参，而是两个固定参数：addr和handler，因为核心契约就这两个 -
sql.Open之后的连接配置（超时、最大连接数等）全靠...Option实现，例如sql.WithTimeout(...)，每个选项独立、可复用、可测试
真正容易被忽略的是：变参函数内部若要支持“零配置默认行为”，必须显式处理len(opts) == 0分支，而不是假设调用方一定会传至少一个Option——很多bug就出在这里。
