Go中设文件权限须创建时指定而非依赖os.Chmod，因后者跨平台失效（Windows忽略执行位与组/其他权限），且需预检os.Stat、处理符号链接、注意umask影响；细粒度ACL需系统调用，Web服务权限控制应落于应用层而非文件系统。
Go 里设文件权限不能只靠 os.Chmod，尤其跨平台时它在 Windows 上几乎不生效——你传 0755 和 0644 效果一样，执行位被忽略，组/其他人权限也无效。
创建文件时就该定死权限，别等写完再改
敏感文件（如密钥、配置）一旦落盘，就得立刻锁死权限。用 os.WriteFile 或 os.OpenFile 一步到位，避免中间窗口被其他进程读取。
-
os.WriteFile("token.txt", data, 0600)：所有者可读写，其余人完全无权访问 -
os.OpenFile("log.txt", os.O_CREATE|os.O_APPEND, 0644)：日志类文件常用，所有者可读写，组和其他人只读 - 注意：
0644是八进制，不是十进制644；写成644会被解释为八进制1204，结果不可控 - 实际生效权限还受系统
umask影响（如umask=0022时，0666变成0644），生产环境必须显式指定所需值
修改已有文件权限前，必须先 os.Stat 预检
os.Chmod 不检查文件是否存在、是否普通文件、当前用户是否有权操作，出错只返回泛化错误（如 operation not permitted），很难定位真实原因。
- 先调用
os.Stat确认文件存在且可访问 - 用
fi.Mode().IsRegular()排除目录、符号链接、设备文件等非普通文件 - 用
fi.Mode().Perm() & 0200 == 0判断所有者是否具备写权限，比字符串匹配fi.Mode().String()更可靠、跨平台一致 - 若目标是符号链接，
os.Chmod默认操作的是链接本身而非目标文件；需先os.Lstat判断，再os.Readlink+os.Chmod组合处理
Linux 和 Windows 权限行为差异极大，不能混用逻辑
Go 标准库的权限模型本质是 Unix 风格模拟，在 Windows 上只是个薄层：只读/可写两个状态，其余全丢弃。
立即学习“go语言免费学习笔记（深入）”；
- Linux/macOS：
os.Chmod(path, 0444)真正使文件只读（所有者/组/其他人均不可写） - Windows：
os.Chmod仅尝试设置FILE_ATTRIBUTE_READONLY，0755、0644、0500全部等效于“可写”，执行位x完全无效 - 想在 Windows 实现细粒度控制（如“仅 Administrator 可读”），必须用
cgo调用SetNamedSecurityInfo，标准库做不到 - 跨平台服务中，真正起效的权限控制必须落在应用层：HTTP handler 显式校验身份、路径白名单、JWT 解析、数据库查授权记录
需要 ACL 时，Go 标准库完全不支持
os.Chmod 和 os.Stat 永远只读写传统 POSIX 权限位，对 Linux 的 setfacl 规则或 Windows DACL 完全无感。
- Linux 上用
setfacl -m u:alice:rwx /tmp/test加了 ACL，os.Stat返回的Mode()仍是0755，且不会报错 - Linux 下读写 POSIX ACL 必须用
syscall.Getxattr/unix.Setxattr操作system.posix_acl_access，推荐轻量库github.com/djherbis/acl - Windows 下设 DACL 必须写
cgo，调用 WinAPI，无纯 Go 方案 - ACL 操作触发两次系统调用，性能比
os.Chmod慢一个数量级，频繁操作建议批量或缓存
最常被忽略的一点：文件系统权限从来不该是 Web 服务的访问控制第一道防线。路径遍历、越权下载、ACL 绕过——这些都发生在权限位之外。真正的控制点永远在 handler 里，而不是 Chmod 的参数上。
