直接用 chmod -R 755 /path/to/dir 易出错，因不区分文件与目录；应使用 find 分别设置目录755、文件644，并注意umask影响及避免777。
chmod -R 为什么经常改错权限
直接用 chmod -R 755 /path/to/dir 是最常见也最容易出问题的操作。它不区分文件和目录，把所有东西都套同一套数字权限——结果就是可执行文件可能被去掉了 x 位，普通文件却意外获得了执行权限，Web 服务器拒绝读取、脚本无法运行、甚至安全策略报错。
- 目录必须有
x（进入权限），文件通常不需要x -
755对目录合理，但对 .txt/.log/.conf 这类文件属于过度授权 - 递归操作不可逆，误操作后得靠备份或手动逐个修复
用 find + chmod 分开处理文件和目录
这才是稳妥的递归权限设置方式：先给所有目录加 x，再给所有非目录文件去掉 x。不用记复杂符号，靠 find 的类型判断就足够精准。
- 设目录为
755：find /path/to/dir -type d -exec chmod 755 {} \; - 设普通文件为
644：find /path/to/dir -type f -exec chmod 644 {} \; - 如果要保留某些脚本的可执行性，加条件：
find /path/to/dir -name "*.sh" -type f -exec chmod 755 {} \;
umask 和默认新建权限的关系
递归改完不是一劳永逸。后续在该目录下新建的文件，权限仍由当前 shell 的 umask 决定。比如 umask 002 会让新文件默认是 664，而不是你刚设好的 644。
- 查当前 umask：
umask（输出0002表示掩码值） - 临时修改：
umask 022（让新文件默认644，新目录755） - 永久生效需写入
~/.bashrc或/etc/profile，但注意影响范围——别在共享账户里乱设
chmod 777 是万能解？不，它是权限雪崩起点
看到“Permission denied”就下意识跑 chmod -R 777，等于主动拆掉门锁还把钥匙塞给所有人。很多 Web 漏洞、提权攻击都是从这里开始的。
-
777让任何用户都能删改文件，Nginx/Apache 进程可能被恶意覆盖配置 - SELinux 或 AppArmor 启用时，
777反而触发更严格的拦截，错误信息变得更难懂 - 容器环境里，宿主机挂载目录被设成
777，容易导致容器内进程以 root 权限写入关键路径
ls -l 看一眼原始结构；改完用 find /path -type f -perm /111 扫一遍有没有不该有执行位的文件——这种检查比事后救火省力得多。 
