Go afero 怎么把可写文件系统包装成只读接口

如果一段 Go 代码需要读取真实文件系统，却不希望后续模块误删、改名或覆盖文件，可以在依赖注入边界使用 afero.NewReadOnlyFs(source)。它返回的仍然是 afero.Fs，所以读取方通常不需要改接口；创建、删除、重命名、权限修改以及带写入标志的 OpenFile 会被拒绝，并返回 syscall.EPERM。

官方资料：https://github.com/spf13/afero

把可写的 afero.Fs 包在只读视图里，再把只读视图传给不可信或只负责读取的代码。这样保护的是这次接口访问路径，不是操作系统权限，也不会替代容器、用户权限或沙箱。

先识别触发信号：读取路径里混入了写操作

常见现场是：配置解析器、模板渲染器或插件代码只需要打开文件，但它收到的是一个完整可写的 OsFs。只要下游调用了 afero.WriteFile、Remove 或用写入标志打开文件，源目录就可能被改变。

这时先看调用边界，而不是在每个业务函数里手写“禁止删除”判断。上层仍然保留一个可写实例用于真正需要落盘的流程；把只读视图只传给读取流程，责任更清楚，回滚也只需要切换注入对象。

处理步骤：在依赖注入边界创建只读视图

安装依赖后，让业务函数接收 afero.Fs，在组装阶段完成包装。包装器不需要知道调用方具体是磁盘、内存还是其他 afero 后端。

package main

import (
	"fmt"
	"os"
	"syscall"

	"github.com/spf13/afero"
)

// listConfig 只读取目录和文件，不持有修改文件系统的职责。
func listConfig(fs afero.Fs, path string) error {
	entries, err := afero.ReadDir(fs, path)
	if err != nil {
		return fmt.Errorf("读取目录失败: %w", err)
	}

	for _, entry := range entries {
		fmt.Println(entry.Name())
	}
	return nil
}

func main() {
	// sourceFs 可以是 OsFs、MemMapFs 或其他 afero.Fs 实现。
	sourceFs := afero.NewOsFs()
	readOnlyFs := afero.NewReadOnlyFs(sourceFs)

	// 读取路径使用只读视图，源文件系统仍由上层保留。
	if err := listConfig(readOnlyFs, "/etc"); err != nil {
		fmt.Println(err)
	}

	// 写入标志会被只读包装器拒绝，错误应按权限错误处理。
	_, err := readOnlyFs.OpenFile("/tmp/report.txt", os.O_WRONLY|os.O_CREATE, 0o644)
	if err != syscall.EPERM {
		fmt.Printf("预期得到 EPERM，实际得到 %v\n", err)
	}
}

关键点是 NewReadOnlyFs 的返回类型仍满足 afero.Fs。读取函数无需知道它背后是否是真实磁盘；而写入尝试在包装层就结束，不会落到 sourceFs。

快速判断：哪些操作放行，哪些操作返回 EPERM

可以把现场判断分成两组。读取类操作透传到源文件系统；修改类操作直接由只读包装层拒绝。MkdirAll 是一个容易忽略的边界：如果目标已经是目录，它可以返回成功；如果需要创建新目录，仍然会返回 EPERM。

回滚路径：需要写入时切回原始 source

只读视图本身没有“临时解锁”开关。若同一业务既有预览阶段又有保存阶段，应把两个阶段的文件系统依赖显式分开，而不是把 ReadOnlyFs 强行转换回具体类型。

type Store struct {
	fs afero.Fs
}

// NewPreviewStore 只给预览流程暴露读取边界。
func NewPreviewStore(source afero.Fs) *Store {
	return &Store{fs: afero.NewReadOnlyFs(source)}
}

// NewWriteStore 给保存流程保留原始写入能力。
func NewWriteStore(source afero.Fs) *Store {
	return &Store{fs: source}
}

func (s *Store) Save(name string, data []byte) error {
	// 保存流程必须使用可写实例；只读实例会返回 EPERM。
	return afero.WriteFile(s.fs, name, data, 0o644)
}

部署或排障时，先记录当前构造函数注入的是哪一个实例，再决定是否回退。回退到 source 只表示业务恢复写入能力，不能绕过操作系统文件权限。

告警确认与常见误区

如果日志中出现 operation not permitted 或错误值等于 syscall.EPERM，先确认这是预期保护还是误把预览实例传给了保存流程。不要看到错误就直接换回 NewOsFs；先检查调用意图、实例注入位置和操作标志。

• 它不是系统级只读权限。 拿到原始 sourceFs 的其他代码仍可写入。
• 它不是数据快照。 只读视图仍读取源文件系统当前可见内容，源发生外部变化时，读取结果也会变化。
• 它不是所有后端行为的统一承诺。 读取是否成功仍取决于底层 afero 实现、路径和系统权限。
• 错误判断要留出包装。 业务层可用 errors.Is 或直接比较已知错误，但应同时保留操作名和路径上下文。

复盘清单

1. 读取模块是否只拿到了 afero.Fs，而不是全局可写对象？
2. 只读包装是否在依赖注入边界创建，而不是散落在每个文件操作前？
3. 出现 EPERM 时，能否区分恶意或误调用与正常保存流程？
4. 保存流程是否明确注入原始 sourceFs，并记录权限与路径错误？
5. 是否知道只读包装不能替代操作系统权限、容器隔离和用户授权？

常见问题

只读包装能阻止其他 goroutine 写入同一个目录吗？

不能。它只约束通过这个包装视图发出的操作；其他 goroutine 如果持有原始可写文件系统，仍可修改同一资源。

为什么调用 MkdirAll 有时没有报错？

当目标已经是目录时，afero 的只读实现允许把它视为已满足条件；需要真正创建新目录时才会拒绝。不要把这个结果当成目录可写。

OpenFile 使用 O_APPEND 会怎样？

只读包装会把 O_APPEND 视为写入意图并拒绝。只读打开应避免所有写入、创建、追加和截断标志。

什么时候应该改用 io/fs？

如果业务只需要标准库定义的只读文件访问接口，可以考虑 io/fs；如果还要组合 afero 后端、测试写入流程或在不同后端之间切换，保留 afero.Fs 更直接。

小结：在需要保护源数据的读取边界使用 afero.NewReadOnlyFs，让读取能力保留，让修改操作集中返回 EPERM。把原始可写实例和只读视图分开注入，既能快速回滚，也能避免把一次接口保护误认为完整安全边界。