os.chmod改不了权限最可能因mode非八进制（如755应写为0o755），Windows不支持执行权限，符号链接默认改链接本身，且不递归；需用stat常量、验证st_mode确保生效。
os.chmod 为什么改不了权限？常见错误现象
直接调用 os.chmod(path, mode) 却发现文件权限没变，最可能的原因是：你传的 mode 值不是八进制整数，而是十进制或字符串。比如写成 os.chmod("file.txt", 755) —— 这实际是十进制 755（对应八进制 1363），远超常规权限范围，系统会静默截断或忽略。
另一个高频问题是：在 Windows 上调用 os.chmod 修改“执行权限”完全无效，因为 NTFS 不支持类 Unix 的 rwx 三元组语义，它只区分“只读”和“可写”。
- Linux/macOS 下必须用八进制字面量，如
0o644、0o755（注意前缀0o） - Windows 下
os.chmod(path, 0o777)只会影响“只读”标志位，不会赋予“执行”含义 - 若目标路径是符号链接，默认修改的是链接本身权限（非指向文件），需加
follow_symlinks=False显式控制
chmod 参数 mode 怎么算才对？rwx 和数字映射关系
mode 是一个整数，代表三组权限（user/group/others）的位掩码总和。每组用三位二进制表示：读（r=4）、写（w=2）、执行（x=1）。例如 0o755 = user(4+2+1) + group(4+0+1) + others(4+0+1) = 7-5-5。
别硬记数字，用 stat 模块常量更安全、可读：
立即学习“Python免费学习笔记（深入）”；
import os
import stat
<h1>等价写法，推荐</h1><p>os.chmod("script.py", stat.S_IRWXU | stat.S_IRGRP | stat.S_IXGRP | stat.S_IROTH | stat.S_IXOTH)</p><h1>即：用户全权 + 组读+执行 + 其他人读+执行 → 相当于 0o755-
stat.S_IRUSR/stat.S_IRWU等后缀USR/GRP/OTH明确作用对象 - 组合用
|（按位或），不是+（虽然数值结果常一样，但语义清晰更重要） - 避免直接写
0o777，除非真需要全局可写——这在多数部署场景是安全隐患
修改目录权限时要注意什么？递归不是默认行为
os.chmod 只改单个路径的权限，不递归。想给整个目录树设权限，得自己遍历：
import os
for root, dirs, files in os.walk("/path/to/dir"):
for d in dirs:
os.chmod(os.path.join(root, d), 0o755)
for f in files:
os.chmod(os.path.join(root, f), 0o644)- 先设目录（
0o755），再设文件（0o644），顺序反了可能导致中间目录不可进入 - 注意
os.walk默认跳过权限不足的子目录，遇到PermissionError需捕获处理 - 如果只是想让新创建的文件自动继承父目录权限，应改 umask 或用
os.makedirs(..., mode=...)控制新建目录权限
权限修改失败的静默陷阱：没有报错但没生效
最危险的情况是调用成功返回，但权限未变——比如在容器或 NFS 挂载点上，底层存储不支持 chmod，或挂载时用了 noexec/nosuid 选项，此时 os.chmod 不抛异常，只静默失败。
- 修改后务必用
os.stat(path).st_mode验证结果，而不是只信返回值 - 检查挂载参数：
mount | grep $(df . | tail -1 | awk '{print $1}') - 在 Docker 中，宿主机文件挂入容器时，权限由宿主机决定，容器内
chmod通常无效
权限这事，表面是数字，背后是文件系统、挂载策略、运行上下文三重约束。改完不验证，等于没改。
