Go os 怎样用 File.Chmod 维护文件权限位

Go 中维护已有文件权限，直接使用打开文件后的 File.Chmod(mode)：先用 os.OpenFile 或 os.Open 得到文件句柄，再传入明确的 os.FileMode，最后检查返回的 error。官方文档入口是 https://pkg.go.dev/os@go1.27.3#File.Chmod。例如普通私密文件可以使用 0o600，需要同组读取时可以使用 0o640。

File.Chmod 修改的是已经存在对象的模式；创建时的 perm 属于 OpenFile 的创建参数，两者不要混成一次操作。Unix 会使用权限位，Windows 目前只根据 0o200 owner-writable 位控制文件是否为只读属性。

• 权限目标先写成常量或配置，避免在业务代码里散落魔数。
• 修改前确认打开的是预期文件，并在 Chmod 后检查错误。
• 需要记录结果时，用 Stat 读取模式；不要把日志字符串当作权限依据。

规模化任务为什么不能只改创建参数

在小脚本里，创建文件和设置权限往往挨着出现；到了批量导出、归档或配置刷新场景，文件可能早已存在，旧权限也可能来自上一次发布。此时继续修改 OpenFile 的第三个参数并不会自动更新已有文件，因为 perm 只在带有 os.O_CREATE 且文件不存在时参与创建。

更稳定的分工是：打开阶段负责取得句柄，Chmod 阶段负责把已有对象收敛到目标权限，Stat 阶段负责记录当前模式。这样即使同一个文件被重复处理，调用方也能把“打开失败”“权限修改失败”和“读取结果失败”分开处理。

用 File.Chmod 把权限目标写清楚

File.Chmod 的签名是 func (f *File) Chmod(mode FileMode) error。对 Unix 文件，常用的九个低位分别表达所有者、同组用户和其他用户的读写执行权限。文件通常不需要执行位，所以私密配置可以从 0o600 开始；如果同组进程需要读取，可以考虑 0o640，但最终仍取决于部署用户和目录权限。

下面的示例把权限更新封装成一个小函数。它只接收明确的目标模式，错误使用 %w 保留原始原因；关闭文件也要检查，但关闭错误不能覆盖 Chmod 的主要错误。

package main

import (
	"errors"
	"fmt"
	"os"
)

func setPrivateMode(path string, mode os.FileMode) error {
	// 只打开已有文件，避免把权限更新误写成创建流程。
	f, err := os.OpenFile(path, os.O_WRONLY, 0)
	if err != nil {
		return fmt.Errorf("打开文件 %q: %w", path, err)
	}

	// 先记录权限修改错误，再关闭句柄，保留最有用的失败原因。
	chmodErr := f.Chmod(mode)
	closeErr := f.Close()
	if chmodErr != nil {
		return fmt.Errorf("修改文件 %q 权限为 %04o: %w", path, mode.Perm(), chmodErr)
	}
	if closeErr != nil {
		return fmt.Errorf("关闭文件 %q: %w", path, closeErr)
	}
	return nil
}

func main() {
	err := setPrivateMode("settings.json", 0o600)
	if err != nil {
		// 调用层可以按 errors.Is 或日志策略继续处理失败。
		if errors.Is(err, os.ErrPermission) {
			fmt.Println("没有修改权限")
			return
		}
		fmt.Println("权限更新失败：", err)
		return
	}
	fmt.Println("权限更新完成")
}

这里的 0o600 是 Go 的八进制字面量，表示所有者可读写、同组和其他用户没有权限。OpenFile 使用 os.O_WRONLY 是为了表达“这里只需要拿到可操作的已有文件句柄”；是否能成功修改权限仍由操作系统、文件系统和当前身份决定。

如果你的流程本身还要写入文件，可以把打开标志改为业务所需的读写组合，但不要因此把 perm 当成更新已有文件权限的开关。更新权限时，真正起作用的是 f.Chmod(mode) 的调用及其返回错误。

修改后如何确认对象和模式

需要把结果写入审计日志或交给后续任务时，可以在 Chmod 成功后调用 f.Stat()，再读取 info.Mode().Perm()。这一步的价值是确认当前句柄对应的对象和当前看到的权限位；它不是把权限更新变成事务，也不能替代对路径来源的控制。

func applyModeAndRead(path string, target os.FileMode) (os.FileMode, error) {
	// 用读写句柄完成一次明确的“修改后读取”操作。
	f, err := os.OpenFile(path, os.O_RDWR, 0)
	if err != nil {
		return 0, fmt.Errorf("打开待处理文件: %w", err)
	}
	defer f.Close() // 示例只关心模式读取，关闭错误交给更外层记录。

	if err := f.Chmod(target); err != nil {
		return 0, fmt.Errorf("应用目标权限: %w", err)
	}
	info, err := f.Stat()
	if err != nil {
		return 0, fmt.Errorf("读取修改后的模式: %w", err)
	}
	return info.Mode().Perm(), nil
}

批量处理时，不要因为一项失败就把错误吞掉。可以为每个路径记录 PathError，继续处理其余文件，并在任务末尾汇总失败项；若权限修改是发布前置条件，则应由调用方决定是否停止后续发布。

跨平台时要把权限语义收窄

官方 os.Chmod 文档说明，Unix 使用权限位以及 setuid、setgid、sticky 等相关位；Windows 只使用 0o200 owner-writable 位，它控制文件只读属性是否设置或清除，其他位目前不使用。因此，不能把在 Linux 上看到的 0o640 直接解释为 Windows 上同样的三组访问控制。

如果程序需要同时支持 Unix 和 Windows，文章标题中的“维护权限位”应在产品语义里明确：Unix 侧维护完整的权限位，Windows 侧只把目标收窄为“可写或只读”。对于跨平台配置，不要根据字符串模式推断安全结论；可按 runtime.GOOS 选择允许的策略，并把不适用的位从日志描述中排除。

还要注意符号链接：路径版 os.Chmod 修改的是链接目标，File.Chmod 同样作用于打开后的文件对象。若任务要求保护链接本身，不能只把 Chmod 换一个参数就得到不同语义，应先重新设计对象定位与系统调用边界。

常见问题

为什么给 OpenFile 传了 0o600，已有文件还是旧权限？

创建权限参数只在创建新文件时使用。已有文件需要显式调用 File.Chmod，并检查返回的错误。

File.Chmod 成功后还要 Stat 吗？

不是每次都必须。若要记录当前模式、确认处理对象或向后续流程传递结果，再调用 Stat 读取 Mode().Perm() 更清楚。

Windows 上能用 0o640 表示同组可读吗？

不能按 Unix 语义理解。Windows 当前只使用 0o200 owner-writable 位来控制只读属性，其他位没有同样的访问控制含义。

把权限维护拆成“打开对象、调用 Chmod、检查错误、按需读取结果”四个边界，批量任务才不容易把创建参数、已有文件更新和跨平台差异混在一起。最小权限目标应由业务明确给出，再由调用层决定失败是否阻断后续流程。