安全使用 chmod() 需先用 is_dir() 和 is_writable() 双重校验路径，权限值必须用八进制（如 0755），避免操作根目录，执行后用 fileperms() 验证结果，并配合 umask(0) 和 setgid 保障新文件权限。
chmod() 函数怎么用才安全
直接调用 chmod() 修改文件夹权限是最常见做法，但不加判断就硬设容易失败——尤其当 php 进程没权限修改目标目录的父级 inode 时，会静默失败或抛出警告。必须先确认目标存在且可被当前用户访问。
- 用
is_dir()和is_writable()双重检查路径有效性，而不是只靠file_exists() - 权限值务必用八进制写法：
0755（不是755），否则 PHP 会当成十进制处理，实际设成完全不同的权限位 - 避免对根目录或系统路径（如
/var/www）直接操作；优先在项目子目录内完成，比如./uploads - 执行后用
substr(sprintf('%o', fileperms($path)), -4)验证结果，防止 umask 干扰导致权限未生效
为什么 setfacl 或 chmod -R 后 PHP 还写不进去
递归设置（chmod -R 0755 uploads/）只是改了现有文件和子目录的权限位，但新创建的文件仍受当前进程 umask 影响。PHP 默认 umask 是 0022，意味着新建文件最多只有 0644，目录最多 0755——即使你把父目录设成 0777，新文件也不会自动继承。
- 在脚本开头加
umask(0)可临时放开限制，但仅对当前请求有效，且需确保 web 服务器用户有对应权限 - 更稳妥的做法是在创建子目录时显式调用
mkdir($path, 0775, true)，第三个参数true表示递归创建，第二个参数才是真正起效的权限 - 如果用 apache + mod_php，注意
apache2.conf中的UMask指令可能覆盖 PHP 层设置
linux 下 www-data 用户和你的 FTP 用户权限冲突怎么办
开发时用 FTP 上传文件，属主是你的个人用户（如 ubuntu），而 PHP 运行在 www-data 下，两者不属于同一组时，哪怕目录设成 0775，PHP 也写不进文件——因为“组”权限不生效。
- 把你的用户加进
www-data组：sudo usermod -a -G www-data ubuntu，然后重新登录终端 - 统一目录属组为
www-data：sudo chgrp -R www-data /var/www/myapp/uploads - 设置 setgid 位让新建文件自动继承父目录组：
sudo chmod -R g+s /var/www/myapp/uploads - 避免滥用
0777：它等于向所有用户开放写权限，nginx/Apache 日志里一旦出现open_basedir或Permission denied，大概率是权限太松触发了安全模块拦截
windows 上 chmod() 为什么总返回 false
Windows 文件系统（NTFS）没有 unix-style 的 rwx 权限模型，chmod() 在 Windows 下仅能模拟部分行为（如只读标志），对文件夹几乎无效，且返回 false 不代表出错，只是“不支持”。别指望它能解决实际问题。
立即学习“PHP免费学习笔记（深入）”；
- Windows 下应改用
shell_exec('icacls "C:path" /grant Users:(OI)(CI)F')（需开启exec且 web 服务有足够权限） - 更现实的做法是：开发环境用 WSL 或 docker，保持与生产 Linux 环境一致；否则干脆跳过权限设置，专注检查
is_writable()返回值做逻辑分支 -
scandir()或opendir()失败时，先看错误日志里是Permission denied还是failed to open dir——后者更可能是路径不存在或符号链接断裂，而非权限问题
实际部署时，最常被忽略的是 umask 和 setgid 的组合效果：光设目录权限不够，新文件的属组和权限位必须靠这两者共同保障。不验证新建文件的实际权限，只看父目录设置，迟早踩坑。