os.Chown在非root环境必然失败，Linux/macOS需root或文件owner才能改属主，Windows直接panic；跨平台测试须用runtime.GOOS隔离，且敏感文件权限应一步到位用os.WriteFile设置。
os.Chown 在非 root 环境下必然失败，别白试
想在测试里“模拟不同用户”去验证文件权限逻辑？os.Chown 在绝大多数实际场景中根本走不通。Linux/macOS 要求调用者是 root 或当前文件 owner 才能改 owner；改 group 也至少得是 owner 或 root。Docker 容器里非 root 用户、CI 流水线普通 runner、macOS 普通账户——全会 panic 或静默失败。
常见错误是写个测试硬调 os.Chown("f.txt", 1001, 1001)，本地 root 跑过就以为 OK，一上 CI 就崩。更糟的是 macOS 对 UID/GID 做存在性校验：填个不存在的数字（比如随便写的 9999），os.Chown 不报错也不生效，测试看似通过，实际逻辑没覆盖。
- 跨平台测试必须加
if runtime.GOOS != "windows"包裹，且默认跳过 - 真要测属主逻辑，得在 root 容器或专用测试机跑，不能放 CI 公共节点
- Windows 直接禁用：
os.Chown在 Windows 上必定 panic，连 fallback 都不给
用 os.Stat().Mode().Perm() 检查权限位，但 Windows 上永远不准
os.Stat 返回的 Mode() 在 Linux/macOS 可靠，在 Windows 上只映射“可写/只读”两级。比如你设了 0640，Windows 里 info.Mode().Perm() 可能返回 0644 或 0600，完全不可预测；更关键的是，info.Mode().Perm() & 0020（检查组写）在 Windows 上永远为 false —— 因为它压根不存组权限位。
所以测试里写 if info.Mode().Perm()&0020 != 0 判断组是否可写，Linux 下有效，Windows 下恒假，导致测试误判或分支漏覆盖。
立即学习“go语言免费学习笔记（深入）”；
- 跨平台测试必须用
runtime.GOOS == "windows"分支隔离权限断言 - Windows 测试只能断言“是否可写”，不能断言 user/group/other 的具体位组合
- 别用
os.IsPermission判断“为什么打不开”——它在 Windows 上常把路径不存在也报成 Permission denied
测试敏感文件权限，必须一步到位用 os.WriteFile
测试密钥、token、配置文件等敏感内容时，绝不能先 os.Create 再 os.Chmod。中间存在时间窗口：文件已创建但权限还是 0666 &^ umask（通常是 0644），其他进程可能趁机读取。正确姿势是 os.WriteFile("key.pem", data, 0600) —— 创建 + 写入 + 设权限原子完成。
注意：0600 是八进制字面量，写成 600 就是十进制 → 八进制 1130，权限变成 -w--x--x，彻底失控。
- 所有测试用临时文件都该用
os.WriteFile或os.OpenFile(..., 0600)显式设权限 - 用
os.MkdirAll创建目录时，最后一级权限按参数设，上级固定0755—— 若需全路径严格0700，得手动os.Mkdir逐级建 - 测试完记得
os.RemoveAll清理，尤其 Linux 下残留0700目录可能卡住后续测试
真正需要模拟多用户访问，得绕开文件系统走应用层
文件系统本身不提供“以某用户身份打开文件”的 API。Go 没有 sudo open() 这种东西。所谓“模拟不同用户”，实际只有两条路：
一是靠外部工具：Linux 下用 syscall.Exec 调 sudo -u otheruser cat file，但测试会变慢、难 debug、跨平台断裂；二是放弃文件权限，改测应用层逻辑——比如 Web 服务里，构造带不同 JWT 的 HTTP 请求，看 handler 是否拒绝访问 /api/secrets。
- 单元测试专注逻辑分支（如
if user.Role >= RoleAdminUser），不碰真实文件权限 - 集成测试若真需验证 OS 层行为，用最小化 Docker 镜像（含多个预建用户），并接受它只能跑在 Linux 环境
- 永远别在测试里依赖
umask—— 它由宿主环境决定，CI 和本地机器值常不同，导致os.Create结果飘移
