数字写法（如755）适合快速批量设权，符号写法（如u+x）更安全精准；文件常用644、脚本用755、敏感文件用600；目录需x位故用755或700；chmod -r需慎用，推荐u+rx配合find分步处理。
chmod 修改权限时数字和符号两种写法怎么选
数字写法（如 755）适合快速批量设权，符号写法（如 u+x）更适合精准增删某类权限。别硬记八进制，先理解 r=4、w=2、x=1 是加法关系——6 就是 rw-（4+2），7 是 rwx（4+2+1）。但实际操作中，符号写法更安全：比如只想给所有者加执行权，用 chmod u+x script.sh，比算出新八进制再覆盖整个权限位更不容易误伤。
常见错误现象：chmod 644 deploy.sh 后发现脚本无法执行——因为 644 没有 x 位；又或者 chmod 777 config.json 导致安全告警。
- 文件一般用
644（所有者读写，组和其他只读） - 可执行脚本用
755（所有者读写执行，组和其他读执行） - 敏感配置文件避免
777或666，宁可用600（仅所有者可读写） - 目录必须有
x才能 cd 进入，所以755或700更常见，644目录会报Permission denied
递归修改目录权限的陷阱
chmod -R 看似方便，但会把目录和里面所有文件一视同仁。问题来了：你给 logs/ 目录设 755，结果里面成千上万个日志文件也全变成 755——它们根本不需要执行权限，还可能被误执行或暴露。
正确做法是分两步：
- 先给目录加执行权：
chmod -R u+rX,g+rX,o+rX logs/（注意大写X：只对已有x的文件或目录加x，普通文件不会被强加执行位） - 再单独处理文件权限，比如去掉所有文件的执行位：
find logs/ -type f -exec chmod u-w,g-w,o-w {} \; - 如果只是想让子目录可进入、文件可读，
chmod -R 755 logs/+ 后续find logs/ -type f -exec chmod 644 {} \;更直观
chmod 改不了权限？先看这三个地方
执行 chmod 报错或看似生效实则无效，大概率不是命令写错，而是卡在底层约束上：
- 不是文件所有者，且没
sudo权限：普通用户只能改自己拥有的文件权限，chmod对别人文件直接失败 - 挂载选项含
noexec、nosuid或mode=：比如/tmp常被挂为noexec,nosuid,nodev，此时chmod虽不报错，但x位实际被忽略 - 文件系统是 FAT32 / NTFS（如双系统挂载的 Windows 分区）：根本不支持 Unix 权限，
chmod完全无效，只会静默返回成功
验证方式：mount | grep $(df . | tail -1 | awk '{print $1}') 看挂载参数；stat filename 看是否显示 Access: (0644/-rw-r--r--) 类信息。
umask 怎么偷偷影响 chmod 的结果
新建文件默认权限不是 666，而是受 umask 掩码“削”过——比如 umask 002，新建文件就是 664（666 & ~002），目录是 775（777 & ~002）。这个值不干扰 chmod 显式设置，但它决定了你每次 touch、cp、echo > file 出来的初始权限，容易让人误以为 chmod 没生效。
临时查当前 umask：umask；永久修改需改 shell 配置（如 ~/.bashrc 中加 umask 022）。
真正容易被忽略的是：某些服务（如 nginx、systemd 服务）启动时的 umask 是独立继承的，跟你的终端不一样——这时候你手动 chmod 好的文件，被服务进程创建的新文件还是会按它的 umask 走。
