Go os.File.Truncate 后当前文件偏移为什么不自动改变

如果你把一个打开的文件截短，却发现下一次 Read 或 Write 仍从原来的位置开始，这不是 Go 没有刷新状态，而是因为文件长度和文件句柄的 I/O 偏移本来就是两个独立概念。os.File.Truncate 只改变文件大小，不会自动修改下一次读写使用的偏移。

官方文档：https://pkg.go.dev/os#File.Truncate

截断负责改变“文件有多长”，Seek 负责改变“下一次顺序读写从哪里开始”。如果截断后还要从新位置继续操作，就显式调用 Seek；如果写入位置本来就是固定偏移，直接使用 WriteAt。

先把文件长度和 I/O 偏移分开看

在这个问题里最容易混淆的是两个“位置”。文件长度是文件元数据的一部分，例如把 100 字节的文件截成 40 字节；I/O 偏移则属于当前打开的 *os.File，决定下一次 Read 或 Write 的起点。

File.Truncate(size) 的文档明确说明：它改变文件大小，但不改变 I/O offset。调用的是同一个文件句柄，也不代表这两个状态会被绑定修改。截断成功后，如果当前偏移原来是 60，而新长度是 40，偏移仍然是 60；此时顺序读取自然已经位于文件末尾之外。

截断后为什么看起来像是“偏移没有变化”

下面的例子先写入一段内容，再把文件截到 5 字节，然后从当前句柄继续读取。代码没有假设 Truncate 会把偏移拉回文件尾，而是主动打印截断前后的偏移和长度。

package main

import (
	"fmt"
	"io"
	"os"
)

func main() {
	file, err := os.CreateTemp("", "truncate-demo-*")
	if err != nil {
		panic(err)
	}
	defer os.Remove(file.Name())
	defer file.Close()

	// 先写入 10 个字节，让当前 I/O 偏移来到文件末尾。
	if _, err := file.WriteString("0123456789"); err != nil {
		panic(err)
	}
	before, err := file.Seek(0, io.SeekCurrent)
	if err != nil {
		panic(err)
	}

	// 截断只改变长度，不负责重置当前 I/O 偏移。
	if err := file.Truncate(5); err != nil {
		panic(err)
	}
	after, err := file.Seek(0, io.SeekCurrent)
	if err != nil {
		panic(err)
	}
	info, err := file.Stat()
	if err != nil {
		panic(err)
	}
	fmt.Printf("truncate 前偏移=%d，truncate 后偏移=%d，长度=%d\n", before, after, info.Size())

	// 偏移仍为 10，继续顺序读取会直接得到文件尾。
	buf := make([]byte, 1)
	n, err := file.Read(buf)
	fmt.Printf("继续读取 n=%d，err=%v\n", n, err)
}

这个场景中，写入完成后偏移是 10；截断到 5 字节后，偏移仍是 10。下一次 Read 从偏移 10 开始，返回 n=0 和 io.EOF。这里的 EOF 不是截断失败，而是当前偏移已经在新的文件长度之外。

如果原来的偏移位于截断后的范围内，例如偏移为 3、长度截成 5，那么后续读取仍会从偏移 3 继续。反过来，如果把文件从 5 字节扩展到 12 字节，新增区域的内容由底层文件系统语义决定，偏移也仍保持原值，不能把扩展误解成自动跳到 12。

需要移动下一次读写位置时，用 Seek 明确表达

如果业务意图是“截断后从新文件尾继续写”，就先用 Seek(0, io.SeekEnd)；如果意图是“从文件开头重读”，就用 Seek(0, io.SeekStart)。Seek 返回新的偏移和错误，不能只调用而忽略返回值。

// truncateAndAppend 把文件缩短后，把顺序写入位置放到新的文件尾。
func truncateAndAppend(file *os.File, size int64, data []byte) error {
	if err := file.Truncate(size); err != nil {
		return fmt.Errorf("截断文件失败: %w", err)
	}

	// Truncate 不改变 offset，所以这里显式定位到截断后的文件尾。
	if _, err := file.Seek(0, io.SeekEnd); err != nil {
		return fmt.Errorf("定位到文件尾失败: %w", err)
	}
	if _, err := file.Write(data); err != nil {
		return fmt.Errorf("追加数据失败: %w", err)
	}
	return nil
}

这段写法把两个动作分开：Truncate 负责长度，Seek 负责顺序 I/O 位置。若 size 小于原长度，Seek 会落在新的尾部；若 size 大于原长度，也仍然会以当前文件尾作为追加起点，意图更清楚。

固定位置写入时，别把 Write 和 WriteAt 混在一起

Write 使用当前 I/O 偏移，并会随着写入推进；WriteAt 则从传入的字节偏移写入，不依赖当前偏移。截断后如果你只想覆盖文件头的一段记录，WriteAt 往往比“先 Seek 再 Write”更直接。

// replaceHeader 在固定偏移写入新头部，不改变调用方对当前偏移的判断。
func replaceHeader(file *os.File, header []byte) error {
	const headerOffset int64 = 0
	if n, err := file.WriteAt(header, headerOffset); err != nil {
		return fmt.Errorf("写入头部失败，已写入 %d 字节: %w", n, err)
	} else if n != len(header) {
		return fmt.Errorf("头部写入不完整: %d/%d", n, len(header))
	}
	return nil
}

需要注意，WriteAt 的偏移是这一次调用的参数，和 Seek 设置的当前偏移不是同一条控制路径。官方文档还说明，用 O_APPEND 打开文件时，WriteAt 会返回错误；如果业务真的是追加，应选择与打开标志和写入方式匹配的方案。

用一张表排查截断后的行为

遇到“截断后读不到”时，优先记录三项：Stat().Size() 得到的文件长度、Seek(0, io.SeekCurrent) 得到的当前偏移，以及本次操作究竟调用了 Read/Write 还是 ReadAt/WriteAt。这三项足以区分长度问题、偏移问题和固定位置 I/O 问题。

相关问题

Truncate 会把文件内容清零吗？

缩短时，超出新长度的尾部内容不再属于文件；扩展时，新增区域通常表现为零填充，但不要把它当成写入了业务数据，真正需要的内容仍应显式写入。

Truncate 之后需要重新打开文件吗？

不需要。只要句柄仍然有效，可以继续使用同一个 *os.File；需要改变下一次顺序 I/O 的起点时，显式调用 Seek 即可。

读取固定区间应该用什么？

如果不希望改变当前偏移，可以优先考虑 ReadAt；它使用调用参数中的字节偏移读取，更适合文件头、索引区和固定记录。

结论很简单：Truncate 改的是文件长度，Seek 改的是顺序读写偏移，WriteAt 直接指定一次写入的目标位置。把这三个职责分开，截断后的 EOF、覆盖位置和追加位置就不会再互相干扰。