os.chmod在windows上改不了“读写权限”是因为windows使用acl权限模型，不支持unix的rwx位，仅映射只读标志（stat.s_iwrite），其余位被忽略；需用win32security等api才能精细控制。
os.chmod 为什么改不了 Windows 上的“读写权限”
在 Windows 上直接用 os.chmod 设置 0o600 或 0o755，文件属性看似没变化，甚至可能抛出 NotImplementedError —— 这不是你代码错了，是 Windows 的权限模型根本不支持 Unix 风格的权限位。Windows 用的是 ACL（访问控制列表），os.chmod 在它上面只粗略映射“只读”标志（stat.S_IWRITE）和“隐藏/系统”等少数属性，其余位被忽略。
如果你真需要控制 Windows 文件的完整访问权限，得用 win32security 或 shutil.chown（Python 3.12+）配合 Windows API，而不是依赖 os.chmod。
Linux/macOS 下 chmod 的权限数字怎么算才不翻车
Unix 权限三位八进制数（如 0o644）分别对应 owner/group/others，每位是 r(4)+w(2)+x(1) 的和。常见错误是写成十进制 644（Python 会当 644 十进制处理，相当于八进制 0o1204，远超预期），必须加 0o 前缀。
-
0o600→ owner 可读写，group/others 无权限（适合私钥、密码文件） -
0o644→ owner 可读写，group/others 只读（常规文本文件） -
0o755→ owner 可读写执行，group/others 可读可执行（常用脚本或目录） - 目录要执行位（
x）才能 cd 进入，缺了会报Permission denied
chmod 后文件还是打不开？检查 umask 和父目录权限
os.chmod 只改目标文件自身权限，但两个隐形因素常导致结果不符预期：
- 进程的
umask会在文件创建时就过滤掉某些权限（比如umask 0022会让open(..., 0o666)实际生成0o644），os.chmod是后续覆盖，但若你忘了调用，就只能靠 umask 控制 - 即使文件是
0o777，如果它的父目录没有x权限，用户依然无法访问该文件（路径不可遍历） - 使用
os.stat(path).st_mode & 0o777确认实际生效的权限位，别只信你传进去的数字
Python 3.12+ 新增的 follow_symlinks=False 参数有什么用
默认情况下 os.chmod(path, ...) 会顺着符号链接走到目标文件再改权限。如果只想改链接本身（比如让链接不可读，但保留目标可读），就得显式加 follow_symlinks=False。
这个参数在旧版本（TypeError；而如果你在新版本脚本里操作 symlink 却没加，很可能误改了目标文件权限，尤其在部署脚本或配置管理中容易引发权限扩散问题。
示例：
os.chmod('mylink', 0o444, follow_symlinks=False) # 只改链接文件自身的权限
真正麻烦的从来不是 chmod 这一行代码，而是你没意识到权限是路径上每一级目录 + 当前文件共同决定的，而且跨平台时连“权限”这个词的含义都不同。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
