os.Chmod无法直接设置Sticky Bit，因sticky位是other执行位的扩展位，仅当目录对others有x权限（末位为1/3/5/7）时才生效；必须用八进制01777等显式含第4位值，且需验证os.Stat结果或ls -ld确认t/T显示。
Go 的 os.Chmod 无法直接设置 Sticky Bit，必须用八进制 mode 显式包含粘滞位值（即第 4 位为 1），否则即使调用成功，权限也不会生效。
为什么 os.Chmod 设置 Sticky Bit 容易失败
Sticky Bit 不是独立开关，而是权限字段中「other 执行位」的扩展位。Linux 内核只在目录的 `x` 权限被置位时才检查 sticky 位是否启用；若目录本身对 others 没有 `x`（即权限末位不是 `1`、`3`、`5`、`7`），哪怕你传了 `01777`，内核也会静默忽略 sticky 位。
-
os.Chmod(path, 0777)：不带 sticky，等价于chmod 777，永远不设 sticky -
os.Chmod(path, 01777)：带 sticky，等价于chmod 1777，只有当目录已有 o+x 时才真正生效 - 普通用户调用
os.Chmod修改他人文件的 sticky 位会返回operation not permitted，但错误可能被忽略——err为nil并不表示成功 - 容器或 FUSE 挂载点（如某些 CI 环境的
/tmp）可能完全禁用 sticky 支持，stat -c "%a %n" path可验证实际权限
os.Chmod 中 Sticky Bit 的正确写法
Go 的整数字面量默认是十进制，1777 是一千七百七十七，不是八进制的 sticky + rwxrwxrwx。必须加前导 0 表示八进制：
err := os.Chmod("/tmp/shared", 01777) // ✅ 正确：八进制 1777 = sticky + rwxrwxrwx
err := os.Chmod("/tmp/shared", 1777) // ❌ 错误：十进制 1777 ≠ 八进制 1777
常见合法 sticky 组合：
-
01777→drwxrwxrwt（所有人可读写执行 + sticky） -
01755→drwxr-xr-t（所有者全权，组/其他仅读+执行 + sticky） -
01775→drwxrwxr-t（组可写，其他仅读+执行 + sticky）
注意：这些值必须作用于 目录，对普通文件设 sticky 无意义，Linux 会忽略。
如何验证 Sticky Bit 是否真生效
不能只看 os.Chmod 返回 nil，得查系统实际状态：
- 用
os.Stat获取os.FileInfo，再调用Mode()方法：
fi, _ := os.Stat("/tmp/shared")
mode := fi.Mode()
if mode&01000 != 0 { // sticky 位在 FileMode 的第 4 位（01000 八进制）
fmt.Println("sticky bit is set")
}
- 更可靠的方式是 shell 验证：
ls -ld /tmp/shared，末位显示t或T才算成功（t表示 o+x 存在，T表示 o+x 缺失） - 如果目录父级设置了 sticky（如
/tmp），而你又不是文件所有者，os.Chmod会静默失败——此时err可能为nil，但Mode()查不到 sticky 位
Sticky Bit 在 Go 文件操作中的典型陷阱
多数人以为设了 sticky 就能防删，但 Go 程序里真正决定“能否删除”的是 父目录权限，不是目标文件自身权限。比如：
- 你用
os.Remove("/tmp/shared/user2_file")失败，不是因为user2_file权限低，而是/tmp/shared的 sticky 位起效，且调用者不是user2_file的所有者 -
os.Chmod成功设置了 sticky，但后续os.MkdirAll创建的子目录默认没 sticky——粘滞位不继承，必须显式再调一次os.Chmod(subdir, 01777) - 在 rootless 容器中，挂载参数含
noexec,nosuid,nodev时，sticky 会被内核丢弃，os.Chmod却不报错
真正关键的判断永远落在：目录是否可写 + 是否设了 sticky + 调用者是否是目标文件所有者。Go 层面只负责把位写进去，能不能拦住删除，得看内核和文件系统怎么解释它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
