Go fitsio 关闭FITS对象是否也会关闭底层文件

会。Go fitsio 的 FITS 对象关闭，不等于底层文件关闭。在 v0.3.0 的实现里，(*fitsio.File).Close() 会释放 fitsio 自己的编码器、解码器和 HDU 列表，但明确不会关闭传给 fitsio.Open 或 fitsio.Create 的 io.Reader、io.Writer。

官方地址：https://pkg.go.dev/github.com/astrogo/fitsio

因此，使用 os.File 时要同时安排 fits.Close() 和 file.Close()。读取行时产生的 Rows 也有自己的关闭职责，不能把三个对象当成一个资源。

先看 File.Close 到底关闭了什么

这个问题最容易被方法名误导。fitsio 的 File 表示已经解析出来的 FITS 文件结构，而 os.File 表示操作系统文件描述符。两者可以协作，但所有权没有自动转移。

官方源码中的 File.Close 会把内部 encoder、decoder 和 HDU 列表置空，然后返回 nil。它的注释还直接说明：不会关闭底层的 io.Reader 或 io.Writer。所以这段代码只关闭了 fitsio 层：

fits, err := fitsio.Open(file)
if err != nil {
	return err
}
defer fits.Close() // 只释放 fitsio.File 自己的内部状态

// file 仍然由调用方持有，仍需单独调用 file.Close()

如果 file 是 *os.File，它仍然占用文件描述符。短命命令行程序可能不容易立刻暴露问题，但服务端反复打开 FITS 文件时，最终会出现打开失败、描述符数量上涨或无法删除临时文件等现象。

文件、FITS 对象和 Rows 要分别负责

一段典型的读取链路至少有三层对象：

官方示例也采用这种分层方式：先关闭底层 reader，再关闭 FITS 对象，并在读取表格后关闭 rows。这里的关键不是机械记住 defer 的数量，而是确认每个对象由谁创建、谁拥有它。

只读打开时，推荐把两个 Close 都写出来

读取本地 FITS 文件时，可以在两个打开动作成功后分别登记关闭。为了让资源释放顺序更直观，通常先登记底层文件，再登记 fitsio 对象；函数返回时后登记的 defer 先执行。

package main

import (
	"fmt"
	"os"

	"github.com/astrogo/fitsio"
)

func readFITS(path string) error {
	file, err := os.Open(path)
	if err != nil {
		return fmt.Errorf("打开 FITS 文件: %w", err)
	}
	defer func() {
		// 底层文件由本函数打开，因此必须由本函数关闭。
		_ = file.Close()
	}()

	fits, err := fitsio.Open(file)
	if err != nil {
		return fmt.Errorf("解析 FITS 文件: %w", err)
	}
	defer func() {
		// fitsio.Close 不会替我们关闭 file。
		_ = fits.Close()
	}()

	for index, hdu := range fits.HDUs() {
		fmt.Printf("HDU %d: %s\\n", index, hdu.Type())
	}
	return nil
}

这里即使 fitsio.Open 失败，底层文件也会被关闭，因为文件的 defer 已经登记，而 FITS 对象的 defer 还没有登记。这种顺序能覆盖解析失败路径。

读取表格时，Rows 也不能省略

当目标是表格 HDU 时，table.Read 返回的 rows 是另一层读取对象。它不因为 fits.Close() 被调用就自动完成调用方的关闭意图，因此应该在成功拿到 rows 后立即登记 rows.Close()，并在循环结束后检查 rows.Err()。

func dumpTable(file *os.File, fits *fitsio.File) error {
	table, ok := fits.HDU(1).(*fitsio.Table)
	if !ok {
		return fmt.Errorf("HDU 1 不是表格")
	}

	rows, err := table.Read(0, table.NumRows())
	if err != nil {
		return fmt.Errorf("读取表格: %w", err)
	}
	defer func() {
		// rows 是独立的行读取对象，结束后及时释放它。
		_ = rows.Close()
	}()

	for rows.Next() {
		var id int64
		var value float64
		// Scan 把当前行写入变量，失败时立即返回具体错误。
		if err := rows.Scan(&id, &value); err != nil {
			return fmt.Errorf("扫描第 %d 行: %w", id, err)
		}
		fmt.Printf("%d %.3f\\n", id, value)
	}
	if err := rows.Err(); err != nil {
		return fmt.Errorf("遍历表格: %w", err)
	}
	return nil
}

示例中的 file 参数没有在函数内关闭，是刻意的：它不是由 dumpTable 创建的，关闭权应由拥有它的上层函数决定。若一个函数接收借来的 reader，又擅自关闭它，就可能破坏调用方后续操作。

创建新 FITS 文件时也要保留两层关闭

写入路径的规则完全相同，只是 fitsio.Create 接收的是 writer。使用 os.Create 时，最终文件落盘与底层文件关闭仍然由 *os.File 负责。

func createFITS(path string) error {
	file, err := os.Create(path)
	if err != nil {
		return fmt.Errorf("创建输出文件: %w", err)
	}
	defer func() {
		// 写入完成后关闭操作系统文件，并保留真实错误供上层记录。
		_ = file.Close()
	}()

	fits, err := fitsio.Create(file)
	if err != nil {
		return fmt.Errorf("创建 FITS 对象: %w", err)
	}
	defer func() {
		// 先结束 FITS 编码器，再由上一层关闭底层 writer。
		_ = fits.Close()
	}()

	image := fitsio.NewImage(-64, []int{2, 2})
	if err := fits.Write(image); err != nil {
		return fmt.Errorf("写入主 HDU: %w", err)
	}
	return nil
}

生产代码如果必须区分“写入失败”和“关闭失败”，可以把匿名 defer 改为命名返回值并合并错误。无论采用哪种写法，都不要把 fits.Close() 当成 file.Close() 的替代品。

封装函数里先确认资源归属

可以用一个简单规则判断是否需要关闭：谁创建，谁负责关闭；谁借用，谁不要擅自关闭。例如，函数内部调用 os.Open，就应该在内部安排 file.Close；函数参数接收 io.Reader，通常只关闭 fitsio 对象，不应该假定这个 reader 可以被关闭。

如果参数类型确实实现了 io.Closer，是否关闭仍取决于 API 契约。最好在函数注释中明确“本函数接管所有权”还是“调用方保留所有权”，避免调用方和被调用方重复关闭同一个共享资源。

最后用这张清单排查文件描述符问题

• 调用 os.Open 或 os.Create 后，是否有对应的 file.Close？
• 调用 fitsio.Open 或 fitsio.Create 后，是否有对应的 fits.Close？
• 调用 table.Read 后，是否有对应的 rows.Close？
• 解析失败、扫描失败和正常返回三条路径是否都能执行关闭逻辑？
• 封装函数是否写清楚底层 reader 或 writer 的所有权？

结论可以压缩成一句话：fitsio.File.Close 负责结束 FITS 层，os.File.Close 负责结束操作系统文件层，Rows.Close 负责结束行读取层。三者各自关闭，才是不会留下资源的写法。

相关问题

fitsio.Open 会不会把整个文件读完？官方 v0.3.0 的 Open 实现会持续解码 HDU，直到读到 EOF；但这不改变底层 reader 的关闭责任。

可以只调用 file.Close 吗？不建议。这样可能释放文件描述符，却没有明确结束 fitsio 内部对象；两层都应按所有权关闭。

defer 的顺序重要吗？重要。多个 defer 按后进先出执行，建议让 fitsio 层先结束，再让底层 writer 或 reader 结束，并在代码注释中写明原因。