linux文件系统设计基于进程视角、最小权限原则和跨设备一致性，/、/usr、/var 分离以支持只读根、升级隔离与共享；权限检查是全链路的，目录x权限决定路径可达性，删除由父目录w/x控制而非文件自身权限。
Linux 文件系统不是靠“目录树好看”或“权限好记”设计的，而是围绕进程视角、最小权限原则和跨设备一致性这三件事展开的。理解这点，才能看懂为什么 /bin 和 /usr/bin 要分开，为什么 root 用户删不掉某些普通文件，以及为什么 chmod 777 常常解决不了问题反而引发新问题。
为什么目录结构要分 /、/usr、/var 而不是全塞进一个大目录？
这是为了支持只读根文件系统、系统升级隔离和多主机共享。早期 Unix 就把“不变的”（如内核模块、命令二进制）和“可变的”（如日志、缓存、用户数据）物理分离。
-
/下只保留启动必需项：/bin（基础命令）、/sbin（系统管理命令）、/etc（本地配置）、/dev（设备节点）——这些必须在 rootfs 挂载时就可用 -
/usr是“shareable, read-only”的代名词：它本意是 “Unix System Resources”，现在存放绝大多数命令（/usr/bin）、库（/usr/lib）、头文件（/usr/include），可被多个机器 NFS 共享且挂为只读 -
/var专管运行时变化：日志（/var/log）、包管理数据库（/var/lib/dpkg或/var/lib/rpm）、邮件队列（/var/spool）——这些必须可写，且不能放在/usr里破坏其只读语义
现代发行版（如 systemd 的 initramfs）仍依赖这种划分：如果把 systemctl 放进 /usr/bin，而 /usr 是延迟挂载的，就得靠 initramfs 提前把它 bind-mount 进来，否则系统起不来。
ls -l 输出里那串 drwxr-xr-x 到底控制什么？
这不是“读/写/执行”三个权限的简单叠加，而是三组独立判断逻辑，每组对应一类主体（owner/group/others），且对目录和文件含义不同。
- 对文件：
r表示能否用cat/open()读内容；w表示能否write()修改内容；x表示能否被execve()执行（与文件后缀无关） - 对目录：
r表示能否readdir()（即ls列出文件名）；w表示能否在该目录下unlink()/mkdir()（即增删改文件名）；x表示能否chdir()进入或通过该目录访问子路径（没有x就算有r也ls不出内容） - 删除文件实际由父目录的
w和x决定，跟文件自身的权限完全无关 —— 这就是为什么普通用户能删自己创建的文件，但删不掉别人chmod 000的文件（只要父目录没给w）
为什么 chmod 777 经常不管用，甚至让服务起不来？
因为 Linux 权限检查是“全链路生效”，任意一级缺失都会中断。常见失效场景根本不在目标文件本身。
- Web 服务器访问
/var/www/html/index.html失败？先检查/、/var、/var/www、/var/www/html每一级的x权限 —— 缺一个，路径就走不通 - SSH 登录提示
Authentication refused: bad ownership or modes？是因为~/.ssh/authorized_keys所在目录（~/.ssh）或用户家目录（~）的权限太宽松（比如group或others有w），OpenSSH 主动拒绝加载 - 容器里挂载宿主机目录后程序报
Permission denied？很可能是挂载时用了noexec或nosuid选项，或者 SELinux/AppArmor 策略拦截，此时改chmod完全无效
ls -ld / /var /var/www /var/www/html # 必须每一级都有 x（对其他用户至少是 --x 或 -x-） # 如果某一级是 drw-r--r--，那后面全白搭
真正难的不是记住权限数字，而是意识到：Linux 的权限模型里，路径是资源，目录是接口，文件是数据，三者权限职责完全不同。错把目录当容器、把文件当入口，是绝大多数权限问题的根源。
