Go函数签名中参数顺序不可调换，因顺序是类型的一部分；空参数或返回列表必须保留括号；error虽非语法强制置末位，但属关键约定，影响工具链、泛型匹配与第三方库兼容性。
Go 函数签名里参数顺序不能随便调换
Go 语言函数签名中，参数类型和顺序是签名的一部分，哪怕两个函数只有参数顺序不同，它们就是完全不同的类型。这直接影响赋值、接口实现、类型断言等场景。
常见错误现象：cannot use func(x int, y string) as func(y string, x int) —— 编译器直接报错，不给你任何商量余地。
- 接口方法签名必须严格匹配：比如
io.Reader要求Read([]byte) (int, error)，你写成Read([]byte) (error, int)就不算实现 - 函数变量赋值时，左右两边的签名必须字面一致，包括每个参数名（虽不参与类型比较，但位置和类型必须对齐）
- 使用泛型约束时，
func(T) bool和func(bool) T是两个毫无关系的类型
返回值命名会影响可读性，但不改变签名
命名返回值（如 func() (err error)）只是语法糖，编译后和未命名的 func() error 类型相同；但它会改变函数体内的作用域和 return 行为。
容易踩的坑：defer 中读取命名返回值，可能拿到的是零值或被覆盖后的值，尤其在有多个 return 语句时逻辑易混淆。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 命名返回值会让函数体自动声明同名变量，
return无参数时会返回这些变量的当前值 - 未命名返回值更显式、更可控，适合逻辑分支多或需提前计算返回值的场景
- 导出函数建议少用命名返回值，除非能显著提升调用方理解成本（比如
func ParseTime(s string) (time.Time, error)比(t time.Time, err error)更清晰）
空参数列表和空返回列表的写法不能省略括号
func() int 是合法签名，但 func int 是语法错误；同样，无参无返回也必须写成 func()，而不是 func。
常见错误现象：syntax error: unexpected newline, expecting { 或 missing function body，往往是因为漏写了括号。
- 参数列表为空时，必须保留
()，哪怕后面跟着返回类型，如func() (string, error) - 返回值为空时，括号也不能省，即
func() {}，不是func {} - 这种设计让 Go 的函数声明语法统一，避免歧义（比如和变量声明
var f func()对齐）
多返回值的类型组合构成唯一签名，error 放最后不是语法强制，而是约定
Go 不强制 error 必须是最后一个返回值，但所有标准库、主流项目都这么写。一旦打破，不仅违反直觉，还会导致工具链误判（比如 go vet 检查错误处理路径）。
性能影响很小，但兼容性代价很高：比如一个期望 (int, error) 的泛型约束，传入 (error, int) 就无法匹配。
- 函数签名是否匹配，只看类型序列，不看变量名，所以
(int, error)≠(error, int) - 第三方库（如
github.com/pkg/errors）的包装函数默认假设error在末尾，乱序会导致Wrap失效 - IDE 自动补全、gopls 类型推导也依赖这个惯例，偏离后提示质量明显下降
函数签名是 Go 类型系统的锚点，它不靠文档解释，只靠字面一致。参数顺序、括号存在、返回值位置——这些看似琐碎的细节，一旦写错，编译器不会帮你“猜意图”，只会立刻拒绝。
