go中应使用os.isnotexist(err)判断文件不存在错误，它通过errors.is(err, fs.errnotexist)穿透错误包装链，比字符串匹配更安全可靠。
os.IsNotExist() 判断文件不存在错误
Go 中没有“异常捕获”概念，os.Open()、os.Stat() 等函数失败时返回 error 值，而不是抛出异常。最常踩的坑是直接用 err == nil 或字符串匹配判断错误类型——这不可靠，且无法兼容未来可能的错误包装。
正确做法是使用标准库提供的类型判断函数：
-
os.IsNotExist(err)专用于识别“文件或目录不存在”这类系统级错误，内部调用errors.Is(err, fs.ErrNotExist) - 它能穿透
fmt.Errorf("xxx: %w", err)包装的错误链，比strings.Contains(err.Error(), "no such file")安全得多 - 注意：仅对 syscall 层面返回的 ENOENT 生效；自定义错误（如
errors.New("not found")）不被识别
errors.Is() 与 errors.As() 处理多层错误包装
当错误经过多次 %w 包装（比如 fmt.Errorf("read config: %w", os.Open(...))），原始错误可能深埋在链中。此时不能用 == 比较，必须用 errors.Is() 或 errors.As()。
-
errors.Is(err, fs.ErrNotExist)判断是否“最终源于”某个底层错误，适用于通用条件分支 -
errors.As(err, &target)尝试提取具体错误类型，例如提取*os.PathError获取Op（操作名）、Path（路径）、Err（原始 errno） - 若错误链中存在多个同类型错误，
errors.As()只取最内层的一个；需确保target是指针类型
defer file.Close() 必须检查 close 错误
很多开发者只检查 os.Open() 的错误，却忽略 file.Close() 可能失败。尤其在写入场景下，Close() 才真正触发磁盘刷写，失败意味着数据可能未落盘。
-
defer不等于“安全”，它只是延迟执行；仍需显式检查err := file.Close() - 常见错误模式：
defer file.Close()后不再处理其错误 → 隐蔽的数据一致性风险 - 推荐写法：用
if err := file.Close(); err != nil { /* 记录或返回 */ }，并在函数末尾统一处理 - 注意：如果
Open已失败，file为nil，直接调用Close()会 panic —— 务必先判空
panic() 不该用于文件系统错误
文件操作失败（如找不到配置文件、权限不足、磁盘满）全部属于可预期、可恢复的错误，应走 error 返回路径。滥用 panic() 会导致服务不可控崩溃，且无法被上层统一拦截。
-
panic()仅适用于程序无法继续的致命状态，例如初始化阶段关键配置彻底缺失且无默认值 - HTTP handler 中触发
panic会导致整个 goroutine 终止，若未配recover，连接直接断开，客户端收不到任何响应 - 真正需要“终止流程”的地方，应该返回
error并由调用方决定是重试、降级还是返回 HTTP 500
实际中最容易被忽略的是错误包装后的类型提取逻辑——你以为 errors.As(err, &e) 能拿到 *os.PathError，但若中间某层用了 errors.New() 而非 %w，链就断了，As 直接失败。务必统一用 %w 包装，且只对真正需要透传底层细节的场景才提取。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
