Go标准库不支持动态获取或管理POSIX ACL和Windows DACL；Linux需用xattr（如djherbis/acl库）读取，Windows必须用cgo调用WinAPI；Web服务应避免依赖文件系统ACL，而采用应用层校验和路径净化。
Go 标准库无法动态获取或管理 POSIX ACL（如 Linux 的 user:alice:rwx）或 Windows DACL，os.Stat 和 os.Chmod 对它们完全无感知。 你看到的 Mode() 值永远只是传统 rwx 位，ACL 条目可能依然生效但被彻底忽略——这不是 bug，是设计如此。
Linux 下读取 POSIX ACL 必须用 xattr，不能靠 os.Stat
调用 os.Stat 返回的 Mode() 永远不包含 ACL 信息。即使你用 setfacl -m u:alice:rwx /tmp/file 设置了规则，fileInfo.Mode().String() 仍显示 -rw-r--r--，且不报错。
- ACL 存储在扩展属性中，路径为
"system.posix_acl_access"，需用unix.Getxattr（或封装库）显式读取 - 直接调用 syscall 或
golang.org/x/sys/unix是可行的，但要处理内核版本差异和字节序解析（ACL 二进制格式） - 推荐用
github.com/djherbis/acl：它封装了 get/setxattr，返回结构化[]acl.Entry，避免手撕二进制 - 注意：该库只支持 Linux，且每次读 ACL 触发两次系统调用，比
os.Stat慢一个数量级
Windows 上设置 DACL 必须用 cgo，Go 原生无解
Go 官方明确说明（截至 2026 年 3 月）：不提供对 Windows ACL 的直接支持。想限制“仅 Administrators 组可读”，必须写 cgo 代码调用 WinAPI。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 核心函数是
SetNamedSecurityInfo，需配合LookupAccountName、InitializeSecurityDescriptor等 - 所有调用都依赖
golang.org/x/sys/windows，且只能在 Windows 构建环境下编译运行 - 没有跨平台抽象层；Linux 的
setxattr和 Windows 的SetNamedSecurityInfo在语义、参数、错误码上完全不同，无法统一接口 - 若需兼容多平台，只能兜底为外部命令（如
icacls或setfacl），但会丧失原子性和错误粒度控制
Web 服务中别依赖文件系统 ACL 做访问控制
HTTP handler 暴露文件时，靠 os.Chmod 或 Linux ACL 控制谁能看到 /uploads/report.pdf 是危险且不可靠的。
立即学习“go语言免费学习笔记（深入）”；
- 路径遍历攻击（如
../../etc/passwd）会绕过文件权限，只要 Web 进程有读权限就可泄露 Windows 管理员或文件所有者仍可通过资源管理器直接修改权限，ACL 不构成强制访问控制
- 真正起效的是应用层校验：解析请求上下文（用户身份、JWT）、提取资源标识（如
user_id=123）、查数据库/缓存判断是否允许访问该资源 - 静态文件服务务必做两件事：
path.Clean后检查是否含".."，再用strings.HasPrefix确认拼接后路径未逃逸出白名单根目录
ACL 管理最易被忽略的点是：它不是权限的“最终裁决者”，而是文件系统的“附加注释”。一旦你 mix up 传统权限位和 ACL 条目（比如以为 os.Chmod(path, 0600) 能禁掉所有 ACL 用户），生产环境就会出现静默越权。跨平台场景下，优先放弃 ACL，改用应用层策略引擎（如 Casbin）或对象存储自带 ACL（如 OSS 的 oss.ACLPrivate）更可控。
