调用 stat() 后必须检查返回值是否为0才能访问 st_gid，否则属未定义行为；st_gid 是数字 gid，需用 getgrgid() 转换为组名；其数值不能直接用于权限判断，应使用 access() 或实际 i/o 操作验证。
用 stat() 读取 st_gid 前必须检查返回值
直接访问 st_gid 是危险的——stat() 调用失败时，struct stat 内容是未定义的，此时读 st_gid 属于未定义行为。常见错误是只判断指针是否为空（对 stat() 来说根本没指针），或完全不检查返回值。
-
stat()成功返回0，失败返回-1并设置errno - 路径不存在、权限不足、符号链接循环等都会导致失败，不能假设文件一定可读
- 别用
lstat()替代，除非你明确需要获取符号链接本身的元数据（而非目标文件）
struct stat sb;
if (stat("/path/to/file", &sb) == -1) {
perror("stat");
return -1;
}
// 此时才能安全使用 sb.st_gid
st_gid 是数字 ID，不是组名
很多人拿到 st_gid 后直接打印，看到一串数字就懵了：这到底对应哪个组？st_gid 存的是内核层面的整数型 GID（group ID），和 /etc/group 里文本名是两层映射关系。它本身不携带字符串信息。
- 要转成组名，得调用
getgrgid()，传入sb.st_gid -
getgrgid()返回的是struct group*，其gr_name字段才是字符串名 - 该函数在 glibc 中是线程安全的，但返回的结构体内容存于静态缓冲区，多线程下需注意重入问题（可用
getgrgid_r()替代）
struct group *grp = getgrgid(sb.st_gid);
if (grp != nullptr) {
printf("Group name: %s\n", grp->gr_name);
} else {
printf("GID: %d (no name found)\n", sb.st_gid);
}
不同平台对 st_gid 的解释基本一致，但要注意 NFS 和容器场景
POSIX 规定了 st_gid 是“文件所属组的数字 ID”，Linux、macOS、FreeBSD 都遵守。但实际部署中，值的意义可能被运行环境扭曲：
- NFS 挂载时，若服务端和客户端的 GID 映射不一致（比如服务端 GID 1001 对应 “dev”，客户端 GID 1001 对应 “backup”），
st_gid数值不变，但语义已变 - Docker 容器中，宿主机 GID 在容器内可能不存在，
getgrgid()查不到对应组名，但st_gid本身仍是有效的数值 - 某些无特权容器或 user namespace 场景下，
st_gid可能落在 “mapped range” 外，表现为看似合法的数字却无法查到组信息
别把 st_gid 当作权限判断依据
仅靠 st_gid 无法确定当前进程是否有权限访问文件——Linux 权限检查看的是：进程的有效 GID 是否匹配 st_gid，或进程是否属于该组（通过 supplementary groups），或文件有全局可读/可写位。直接比较 getgid() 和 st_gid 是错的。
-
getgid()返回的是 real GID，权限检查用的是 effective GID（getegid()） - 用户可能属于多个组，
getgroups()才能拿到全部 supplementary GID 列表 - 真正判断可否访问，请用
access()或直接尝试 open/read/write，而不是自己模拟权限逻辑
数值上相等 ≠ 有权访问；数值不等也不代表一定无权——组成员关系、umask、ACL、seccomp 等都可能介入。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
