Go文件IO基准测试：file.Sync()能否用于关文件及保证删除？

创建、读取、打开操作的正确性验证 #

你的直觉大部分正确，但有一个关键细节需要注意：

• 创建/打开文件：os.Create/os.Open返回成功时，操作系统已完成文件条目创建或文件句柄分配，不存在异步延迟，操作完成即代表磁盘层面的元数据操作已完成。
• 读取文件：默认的Read操作会走操作系统的页缓存，即使返回成功，也不代表数据是刚从磁盘读取的。如果要完全规避缓存做基准测试，需要在打开文件时通过os.OpenFile指定syscall.O_DIRECT标志（需注意该标志的平台兼容性），这样读取会直接跳过页缓存，操作完成即对应实际磁盘IO的完成。

文件关闭与Sync()的关系 #

如果你的写入操作已经调用过file.Sync()，那么关闭时不需要额外调用Sync()：

• file.Sync()已经强制将所有已写入的数据从内核缓存刷到磁盘，确保数据持久化。
• file.Close()会释放文件句柄，同时刷新用户态的缓存到内核，但不会触发磁盘同步——不过因为之前已经Sync()过，内核中没有未刷盘的待写入数据，所以Close()返回成功就代表文件关闭操作已完成，不存在异步磁盘操作。

如果写入时没做Sync()，仅调用Close()的话，内核可能会异步刷盘，这时候才需要在关闭前额外Sync()，但你的场景里已经处理了写入的同步，所以不需要。

文件删除的可靠性保证 #

os.Remove()返回成功时，已经完成了文件系统目录条目的移除：

• 如果当前程序已经关闭了该文件的所有句柄，且没有其他进程持有该文件的句柄，那么文件的目录条目已不可访问，后续无法通过原文件名找到它。
• 磁盘空间的回收是操作系统后台的异步操作，这个过程不属于你要测试的“删除操作”范畴——基准测试只需要关心删除操作本身的完成（即目录条目移除），不需要等待磁盘空间回收。

如果一定要确认文件完全无法访问，循环检查文件是否存在是最直接的方式，但确实有性能开销。不过对于基准测试场景，os.Remove()返回成功就足够代表删除操作已完成，满足测试需求。

内容的提问来源于stack exchange，提问作者Amit