go中写0755是编译期八进制字面量，被转为十进制493（二进制111101101），低9位精确对应rwxr-xr-x权限；若写644（无前导0）则按十进制解析，导致权限错乱。
Go里写0755到底发生了什么
你写的0755不是字符串，也不是十进制755，而是编译期就确定的八进制字面量。Go编译器直接把它转成整数值493（即十进制的0755），再隐式转为os.FileMode类型——本质就是uint32(493)。这9个bit（111101101）正好对应rwxr-xr-x：高三位是user（111→rwx），中间三位group（101→r-x），低三位other（101→r-x）。它不经过任何运行时解析，没有性能开销，也不会被umask干扰。
os.Mkdir和os.Chmod传0644却变成-rw-r--r--的底层依据
关键在os.FileMode的底层定义：它是个uint32，但只有最低9位参与Unix权限解释，其余高位用于文件类型标志（如os.ModeDir、os.ModeSymlink）。当你传0644，实际生效的是0644 & os.ModePerm（os.ModePerm == 0777），也就是只取后9位。这意味着：
- 传
0644、00644、000644效果完全一样——前导零在字面量层面就被忽略 - 传
644（无前缀0）是十进制644 → 二进制1010000100→ 后9位是00000100→ 权限变成----w----，完全不是你想要的 - 如果同时要设目录+权限，得用位或：
os.ModeDir | 0755，不能只靠0755
从字符串配置读取权限时为什么strconv.Atoi("755")会出错
配置项常以字符串形式存在（如JSON里的"mode": "755"），这时必须避免用strconv.Atoi。它把"755"当十进制解析，结果是整数755，转成os.FileMode后实际权限位是755 & 0777 = 755（十进制），二进制为1011110011，后9位11110011对应--wxrw---x，而非预期的-r-xr-xr-x。
正确做法是：
- 用
strconv.ParseInt("755", 8, 32)显式按八进制解析，返回int64 - 再强制转为
uint32，最后转os.FileMode：os.FileMode(uint32(modeInt)) - 它能兼容
"755"、"0755"、"00755"，前导零自动处理
为什么os.WriteFile("x.txt", data, 0600)比先写再os.Chmod更安全
两步操作存在竞态窗口：文件已创建但权限未设好，其他进程可能在此间隙读取敏感内容。而os.WriteFile（及os.OpenFile）的perm参数是在open(2)系统调用中一次性完成创建+设权，由内核原子保证。
还要注意：
-
0600这种字面量写法只适用于编译期确定的权限；动态权限必须走ParseInt(s, 8, 32)路径 -
os.Chmod不受当前进程umask影响，但它要求调用者是文件所有者或root；而os.WriteFile受umask限制（除非用O_CREAT|O_WRONLY配syscall.Umask(0)临时清空，不推荐） - Windows上
0600只影响os.ModeReadOnly位，其余权限位被忽略——跨平台程序需额外判断
权限位是位掩码，不是魔法数字。写0开头就进了八进制语义域，不写就掉进十进制陷阱；字符串进来必须指定基数8，否则位模式全乱。这点在CI脚本、配置驱动服务、CLI工具里最容易翻车。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
