ls -l输出中第四列为所属组，第一列前10字符含类型与三类用户权限：首字符标识类型（-普通文件、d目录、l软链接等），后9位分三组rwx表示所有者、所属组、其他用户的读写执行权限。
用 ls -l 查看文件的所属用户组和权限位
直接运行 ls -l 文件名 就能一次性看到所有关键信息：权限字符串、所有者（user）、所属组（group）、大小、时间等。重点看输出第一列的 10 个字符和第三、四字段。
例如：-rw-r----- 1 alice dev 4096 Jul 5 14:22 script.sh
- 第一位
-表示普通文件（d是目录，l是软链接） - 接下来 9 位
rw-r-----分三段：rw-（所有者）、r--（所属组）、---（其他人） -
alice是所有者，dev是所属组 —— 这就是该文件“属于哪个组”的直接答案
注意：ls 不显示组内成员，只告诉你这个文件“被划给了哪个组”。组本身是否包含你，得另外查。
用 id 或 groups 确认当前用户是否在该组里
即使文件所属组是 dev，你也得确认自己是不是 dev 组成员，否则权限不生效。这不是文件自带的信息，得单独查。
-
groups：只显示当前用户所属的所有组名，简洁直观 -
id：显示 UID、GID 和全部组 ID 列表，适合脚本解析或排查 GID 冲突 -
id -nG username：查指定用户（比如id -nG bob），比groups bob更可靠，因为后者在某些 shell 下可能不接受参数
如果 dev 不在输出里，那即使文件权限对组开放（比如 r-x），你也无权访问 —— Linux 权限检查是“精确匹配组名”，不递归查嵌套组或别名。
为什么 cat /etc/group 不能代替 ls -l 查单个文件的组？
cat /etc/group 显示的是系统定义的所有组及其成员列表，但它完全不关联具体文件。它回答的是“哪些人属于 dev 组”，而不是“这个文件属于哪个组”。
- 误用场景：看到
/etc/group里有dev:x:1001:alice,bob，就以为script.sh的组权限自动生效 —— 错。还得确保script.sh的第四字段确实是dev - 真正需要时：比如要确认某用户能否通过组身份访问文件，才需对照
/etc/group查该组有哪些成员 - 风险点：手动编辑
/etc/group不会自动更新已有文件的所属组，必须用chgrp dev filename显式修改
权限生效依赖两个独立条件：文件属组 + 用户实际归属
Linux 的组权限不是“只要用户在某个组里，就能访问所有该组的文件”。它要求同时满足：
- 文件的所属组字段（
ls -l第四列）必须匹配某个你所属的组名 - 该组在权限位中必须有对应操作权限（比如想读，就得有
r；想进入目录，就得有x）
常见陷阱：文件属组是 www-data，你用 sudo usermod -aG www-data $USER 加了组，但没重新登录或 newgrp www-data，shell 会话仍沿用旧组列表 —— 此时 groups 不显示 www-data，权限也不生效。
