Go 怎样在读取配置文件前处理权限错误

用 Go 读取配置文件时，最不应该做的事情是直接比较错误字符串。os.ReadFile 返回的错误通常带有路径和系统调用信息，应用应当沿着错误链判断 fs.ErrPermission、fs.ErrNotExist 等原因，再把底层错误包装成调用方能理解的提示。

处理权限错误的核心是“先保留错误链，再分类提示”：权限不足提示检查运行用户和文件权限；路径不存在提示确认工作目录和挂载；其他错误继续携带原始原因上抛。

先确定 os.ReadFile 的接口目标

os.ReadFile(name) 一次性读取文件并返回字节切片和 error。它适合体积可控的配置文件，但它不会替应用决定“权限错误应该怎么处理”。这个决定应放在项目自己的加载函数中，避免每个调用点各写一套字符串匹配。

设计这个加载函数时有两个接口目标：

• 返回值保留原始错误链，方便日志、测试和上层分类。
• 面对常见错误时给出下一步动作，而不是只返回“读取失败”。

官方文档入口：https://pkg.go.dev/os#ReadFile

用 errors.Is 区分权限、缺失和其他失败

不要依赖 permission denied、no such file or directory 这类文本，因为它们是面向人的错误描述，平台和包装层都可能改变文字。更稳定的做法是用 errors.Is 判断标准错误，再用 errors.As 取出路径上下文。

package config

import (
	"errors"
	"fmt"
	"io/fs"
	"os"
)

// ReadBytes 统一读取配置文件，并把常见系统错误转换成可行动提示。
func ReadBytes(path string) ([]byte, error) {
	data, err := os.ReadFile(path)
	if err == nil {
		return data, nil
	}

	// 先保留原始错误链，调用方仍可用 errors.Is/As 继续判断。
	var pathErr *fs.PathError
	if errors.As(err, &pathErr) {
		if errors.Is(err, fs.ErrPermission) {
			return nil, fmt.Errorf("配置文件没有读取权限，请检查运行用户和文件权限: %w", err)
		}
		if errors.Is(err, fs.ErrNotExist) {
			return nil, fmt.Errorf("配置文件不存在，请检查路径或工作目录: %w", err)
		}

		// PathError 的 Op 和 Path 有助于日志定位，Err 保留底层原因。
		return nil, fmt.Errorf("读取配置文件失败（操作=%s，路径=%s）: %w", pathErr.Op, pathErr.Path, err)
	}

	// 非 PathError 仍然原样包装，避免把未知故障误归类成权限问题。
	return nil, fmt.Errorf("读取配置文件失败: %w", err)
}

这里的 errors.As 不是权限判断本身，而是为了确认错误带有文件操作上下文；真正的分类仍由 errors.Is 完成。这样即使中间多了一层 fmt.Errorf("...: %w", err)，上层也不会失去判断能力。

错误提示应该对应下一步动作

面向调用方的提示不需要暴露所有系统细节，但必须告诉维护者下一步检查什么。可以把常见情况收敛成下面三类：

权限错误不等于“文件不存在”。在某些目录权限受限的环境中，进程甚至无法穿过父目录；因此不要先用一次 os.Stat 再假设后续 ReadFile 一定成功。最终读取动作本身才是权限判断的边界。

让上层只依赖稳定的加载函数

应用入口不应该到处判断底层字符串。可以让加载函数负责分类，入口只记录上下文并决定是否终止启动：

func loadConfig(path string) ([]byte, error) {
	data, err := ReadBytes(path)
	if err != nil {
		// 使用 %w 继续传递原因，日志可以保留完整错误链。
		return nil, fmt.Errorf("加载配置 %q: %w", path, err)
	}
	return data, nil
}

func start(path string) error {
	data, err := loadConfig(path)
	if err != nil {
		// 启动阶段无法使用默认配置时，返回错误让进程管理器接管重启策略。
		return err
	}
	_ = data // 这里接入 JSON、YAML 或其他配置解析器。
	return nil
}

如果业务确实需要降级，也应该只对明确的错误做降级，例如允许“配置文件不存在”时使用内置默认值；权限错误通常不应静默忽略，否则很容易把部署权限问题伪装成默认配置生效。

几个容易踩到的边界

• 不要只判断 os.IsPermission(err) 后丢弃原错误；它可以作为兼容判断，但返回值仍应使用 %w 保留链。
• 不要把相对路径当成相对源码文件；它通常相对于进程当前工作目录，服务管理器和容器启动方式可能改变这个目录。
• 不要为了“提前检查权限”把 os.Stat 当作最终保证；真正的打开和读取仍可能因为运行用户、挂载或父目录权限失败。

常见问题

为什么不直接比较 err.Error()？因为错误文本是描述，不是稳定协议；应优先用 errors.Is 和 errors.As。

包装错误后还能判断权限吗？可以，只要包装时使用 %w，错误链仍能被 errors.Is 遍历。

权限错误能否自动 chmod 修复？通常不建议。应用运行时擅自改变配置权限会扩大风险，应该让部署脚本或运维配置负责修复。