Go函数返回错误必须显式声明error类型，nil表示无错，非nil需检查；自定义错误需实现Error()方法且推荐指针接收者；多值返回中error必须在最后；errors.Is/As仅对用%w包装的错误有效。
Go函数返回错误必须用error类型，不是errors.New或fmt.Errorf本身
Go里错误不是异常，而是普通值。函数签名里声明error类型返回值，调用方才能按约定接收并判断——这和Python的raise、Java的throw完全不同。
常见错误是把errors.New("xxx")直接当返回值写进函数体，却忘了在签名里加error；或者误以为只要用了fmt.Errorf就自动“抛出”错误，结果编译失败或静默忽略。
- 函数定义必须显式包含
error作为最后一个返回类型：func doSomething() (string, error) -
nil代表无错误，非nil才表示出错，不能用== nil以外的方式判空（比如err != ""） - 不要在函数内部
panic代替返回error，除非是真正不可恢复的程序级故障
自定义错误类型要实现Error()方法，不是继承或泛型约束
Go没有继承，也不靠泛型约束来“实现接口”。只要一个类型有签名匹配的Error() string方法，它就满足error接口。这是隐式实现，不需implements关键字。
自定义错误常用于携带上下文（如HTTP状态码、数据库错误码），但容易踩坑：方法名拼错成error()（小写）、返回值类型不是string、或漏了指针接收者导致值拷贝后丢失字段。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 推荐用结构体+指针接收者：
func (e *MyError) Error() string { return e.Msg } - 如果错误需要比较（如
errors.Is），记得实现Unwrap() error方法 - 避免在
Error()里做耗时操作（如日志打印、网络请求），它可能被频繁调用
多值返回中error必须放在最后，且调用方必须显式检查
Go强制要求error作为多值返回的最后一个元素，不是语法糖，而是编译器级约定。工具链（如go vet）和linter都依赖这个位置做静态分析。
最常被忽略的是“忽略错误”：用_, _ := foo()丢弃error，或只检查err != nil却不处理——这会导致上游逻辑继续执行，掩盖真实问题。
- 标准写法是：
val, err := doSomething(); if err != nil { return err } - 不要用
if err := doSomething(); err != nil { ... }这种单行写法嵌套太深，可读性差 - 多个连续调用时，别重复写
if err != nil，可用defer func() { if err != nil { ... } }()集中处理，但注意err作用域
errors.Is和errors.As只对包装错误有效，原始errors.New不支持
从Go 1.13开始，errors.Is用于判断是否为某个特定错误（比如os.IsNotExist），errors.As用于提取底层错误类型。但它们依赖错误被“包装”过——即通过fmt.Errorf("xxx: %w", err)中的%w动词。
如果直接用errors.New或fmt.Errorf("xxx")（没%w），这些函数永远返回false或nil，调试时容易误判。
- 需要可追溯的错误链时，务必用
%w包裹原始错误：fmt.Errorf("failed to open file: %w", os.ErrNotExist) -
errors.Is(err, os.ErrNotExist)只对带%w的错误链生效，否则得用err == os.ErrNotExist - 自定义错误若想参与
Is/As，除了Error()，还得实现Unwrap() error返回被包装的错误
真正难的不是怎么写return errors.New("xxx")，而是决定什么时候该返回新错误、什么时候该包装、什么时候该透传，以及调用链上每一层是否真的需要知道这个错误的细节。这没法靠语法检查，得靠对业务边界的判断。
