Go macho.OpenFat 返回 ErrNotFat 为什么不代表文件已经损坏

调用 macho.OpenFat 读取一个 macOS 二进制时，如果得到 macho.ErrNotFat，先不要把文件标记为损坏。这个错误的含义更窄：文件头的魔数不像 universal binary，但看起来可能是只包含一个架构的普通 Mach-O。真正稳妥的处理是只针对这个错误尝试 macho.Open，其它 I/O 或格式错误继续向上返回。

一、先把 ErrNotFat 放回魔数判定

Go 官方文档把 ErrNotFat 定义为：文件不是 universal binary，但根据魔数可能是 thin binary。源码中的判断顺序也很关键：NewFatFile 先按 Fat 头读取魔数；如果不是 MagicFat，再把同一组字节按另一种字节序解释，只有匹配普通 Mach-O 的 32 位或 64 位魔数时才返回 ErrNotFat，否则返回 invalid magic number。

因此，这个错误表达的是“格式入口不属于 Fat 分支”，不是“文件已经通过完整解析”。后续的 macho.Open 仍会读取普通 Mach-O 的文件头和 load command；若数据被截断，仍可能返回读取错误或 FormatError。

二、用错误边界区分可回退和不可回退

实际代码里最容易出现的误判，是写成“OpenFat 失败就尝试 Open”。这样会把路径不存在、权限不足、短文件、未知魔数等问题全部伪装成普通 Mach-O 探测。回退条件应该锁定在 macho.ErrNotFat：

package main

import (
	"errors"
	"fmt"
	"debug/macho"
)

// openOneMachO 只把“不是 Fat、可能是 thin”的结果交给普通 Mach-O 解析。
func openOneMachO(path string) (any, func() error, error) {
	fat, err := macho.OpenFat(path)
	if err == nil {
		// FatFile 持有由 OpenFat 打开的文件，调用方必须负责关闭。
		return fat, fat.Close, nil
	}
	if !errors.Is(err, macho.ErrNotFat) {
		// 路径、权限、未知魔数等错误没有 thin 回退语义，原样保留上下文。
		return nil, nil, fmt.Errorf("打开 universal Mach-O: %w", err)
	}

	thin, thinErr := macho.Open(path)
	if thinErr != nil {
		// ErrNotFat 只是入口提示，普通 Mach-O 仍可能在后续结构处失败。
		return nil, nil, fmt.Errorf("按 thin Mach-O 解析: %w", thinErr)
	}
	return thin, thin.Close, nil
}

这里把关闭函数和对象一起返回，是为了让调用方不需要猜测当前分支持有的是 *macho.FatFile 还是 *macho.File。如果项目更强调类型安全，也可以把两条分支拆成两个函数；核心原则不变：错误分类先于回退动作。

三、把普通 Mach-O 解析写成明确的资源模型

拿到对象后，下一步通常是读取头部的 CPU 类型、文件类型或段信息。Fat 文件和 thin 文件的对象类型不同，但都应该在创建成功后立刻安排清理。下面的示例只展示资源生命周期和读取边界，不把“能打开”夸大成“内容可信”：

func printMachOHeader(path string) error {
	obj, closeObj, err := openOneMachO(path)
	if err != nil {
		return err
	}
	defer func() {
		// 关闭错误也要留给真实项目的日志或错误聚合策略处理。
		_ = closeObj()
	}()

	switch file := obj.(type) {
	case *macho.FatFile:
		// FatFile 的 Arches 表示容器中各个架构对应的普通 Mach-O 文件。
		fmt.Printf("universal binary: %d architectures\n", len(file.Arches))
	case *macho.File:
		// thin 文件只有一个 FileHeader，不能用 Arches 的思路读取。
		fmt.Printf("thin Mach-O: cpu=%s type=%s\n", file.Cpu, file.Type)
	default:
		return fmt.Errorf("未知 Mach-O 对象类型 %T", obj)
	}
	return nil
}

这里的 defer 只负责资源收尾，不负责掩盖解析错误。生产代码若必须报告关闭失败，可以在命名返回值中合并错误；如果只是读取元数据，至少不要忘记关闭由 OpenFat 或 Open 创建的文件句柄。

四、哪些情况不能把 ErrNotFat 当成修复结论

第一，ErrNotFat 不等于“这是一个可用的 thin Mach-O”。它只是普通 Mach-O 魔数匹配成功，后面的文件头、命令块和段数据仍可能损坏。第二，未知魔数会得到格式错误，不应该强行调用 macho.Open；这通常意味着输入不是该包能识别的 Mach-O，或者文件头已被破坏。第三，macho 官方文档明确提醒它只做基础校验，不是针对恶意输入加固的解析器，因此不可信文件仍要放在资源、超时和进程隔离边界内。

可以把处理策略压缩成下面这张表：

相关问题

为什么同一个路径会被 OpenFat 和 Open 各打开一次？

两个 API 都负责从路径创建自己的文件句柄；简单回退逻辑最清楚，但高频扫描器可以先自行读取少量头部字节，再决定调用哪个 API，不过要保持错误语义和资源关闭责任一致。

ErrNotFat 能证明文件没有被截断吗？

不能。它只说明起始魔数落入“可能是普通 Mach-O”的范围，完整性仍要由后续解析结果和更高层的文件来源可信度共同判断。