结论是：chmod符号模式适合增量调整，八进制模式适合彻底重设；目录必须有x权限才能访问，chmod -r易误设文件执行位或剥夺目录x位，应优先用find分类型处理。
直接说结论：用 chmod，别碰图形界面改权限——它不透明、不一致、不便于复现，且对目录和特殊文件常失效。
你真正需要的不是“怎么点”，而是“为什么加 x 后还是进不去目录”、“chmod 755 和 chmod u+x,g+x,o+x 看似一样，但行为可能不同”这类实际卡点。
chmod 符号模式 vs 八进制模式：选哪个？什么时候会翻车？
符号模式（如 u+x）适合局部调整，八进制模式（如 755）适合彻底重设。
两者本质不同：符号模式是“增量修改”，八进制模式是“覆盖写入”。
-
chmod u+x script.sh只给所有者加执行位，其他权限不动 -
chmod 755 script.sh直接把权限设为rwxr-xr-x，不管原来是什么
容易踩的坑：
- 对一个原本是
600（rw-------）的密钥文件执行chmod g+x，结果变成610（rw----x---）——组用户突然能执行了，但你根本没想开这个口子 - 在脚本部署中混用两种模式：先
chmod 644 *.conf，再chmod a+x deploy.sh，看似合理，但若某次漏掉deploy.sh，后续执行失败时很难回溯是权限没设，还是设错了
建议：
- 日常调试用符号模式（快、可逆）
- 部署脚本或配置固化用八进制模式（明确、无歧义）
- 永远在改之前跑
ls -l filename确认当前状态
修改目录权限时，x 位到底起什么作用？
对目录来说，x 不是“运行”，而是“可访问”——没有它，连 ls 都会报 Permission denied，哪怕你有 r。
常见错误现象：
-
ls mydir显示一堆问号（??????????），但ls -l能看到权限是drw-r--r--→ 缺x -
cd mydir失败，提示Permission denied，但ls mydir却能列出文件名 → 这是典型的“有r没x”，只能看名字，不能查属性或进入
正确组合示例：
- 开发用共享目录：
chmod 775 mydir（所有者/组可读写执行，其他人只读+执行 → 能进、能列、不能改） - 私人配置目录：
chmod 700 ~/.config（仅自己可进可改） - Web 服务静态资源目录：
chmod 755 /var/www/html（Web 用户需x才能遍历路径）
注意：目录的 w + x 组合才允许创建/删除文件；只有 w 没 x 是无效的。
chmod -R 递归修改：为什么脚本变不可执行了？
-R 会把目录和里面所有内容（文件 + 子目录）都套用同一套数字权限，这很危险。
典型问题：
-
chmod -R 755 myproject/→ 把所有.log、.conf、.json文件也设成可执行，既没必要，又可能被安全扫描工具报高危 -
chmod -R 644 myproject/→ 把所有子目录的x位全干掉，导致无法cd进入，ls失败
更稳妥的做法：
- 先设目录：
find myproject -type d -exec chmod 755 {} \; - 再设文件：
find myproject -type f -exec chmod 644 {} \; - 单独放开可执行文件：
find myproject -name "*.sh" -exec chmod 755 {} \;
如果只是想让新文件继承父目录权限，该调的是 umask 或用 setgid（chmod g+s dirname），而不是靠 -R 补救。
关键点其实就两个：
一是目录的 x 位不是可选，是刚需；
二是 -R 不是“批量省事”，是“批量埋雷”——它不管类型、不区分用途、不验证合理性。
真要改权限，宁可多敲两行 find，也别图快砸一整个 chmod -R 755。
