Go语言os.FileMode权限转换异常问题问询

咱们先直接说核心结论：Unix文件权限的八进制表示是约定俗成的，但Go的os.FileMode本质是个uint32数值，它只把最低9位用来表示用户/组/其他的读/写/执行权限，高位比特会被当作特殊文件属性（比如SetUID、粘滞位这类），这就是你遇到权限不符合预期的根本原因。

为什么传入十进制700会得到奇怪的权限？ #

先拆解一下十进制700的二进制：1010111100，一共11位。其中：

• 最低9位是010111100（对应十进制188，八进制274），理论上对应的权限应该是--w-rwxr--
• 第9位是1（对应十进制512），这个比特不属于权限位范围，属于os.FileMode的高位特殊属性区域

但你的测试结果显示实际权限是--w-r-xr--（八进制254），这是因为当FileMode包含高位特殊比特时，操作系统在创建文件时会对权限位做额外调整——高位的非权限标志会干扰最终的权限计算，导致组权限的写位被意外移除。

为什么八进制0700就正常？ #

八进制0700对应的十进制是448，二进制是111000000，刚好填满os.FileMode的最低9位，而且完全对应Unix权限规则：

• 所有者（前三位）：111 → rwx（读、写、执行）
• 组（中间三位）：000 → 无权限
• 其他（后三位）：000 → 无权限

所以用os.FileMode(0700)创建的文件，权限就是预期的-rwx------。

你的测试结果逐一解析 #

咱们对照你的测试数据再理一遍：

• os.FileMode(700) 和 os.FileMode(01274)：这俩数值是相等的（十进制700=八进制1274），都包含第9位的特殊比特，最终被操作系统调整为--w-r-xr--
• os.FileMode(0700)：纯权限位，无高位干扰，得到预期的-rwx------
• os.FileMode(1274)：十进制1274的二进制包含第10位的特殊比特，导致权限进一步被调整为--wxr-x---

正确的做法 #

永远记住这两点：

1. 直接用八进制字面量表示权限：比如0644、0755、0700，这是Unix权限的标准写法，直观且不会出错。
2. 如果权限来自外部字符串输入，要解析为八进制整数：

   import "strconv"
   
   modeStr := "700"
   // 把字符串按八进制解析为uint32
   modeUint, err := strconv.ParseUint(modeStr, 8, 32)
   if err != nil {
       // 处理解析错误
   }
   mode := os.FileMode(modeUint)
   // 后续使用mode创建文件
   

你提到的Go内部工具曾经因为用十进制700代替八进制0700出现权限bug，就是因为没搞清楚这个区别——十进制数值的高位比特会被当作特殊标志，彻底打乱预期的权限。

内容的提问来源于stack exchange，提问作者Rob Fagen