应使用chmod 755而非777；755赋予所有者读写执行、组和其他人读执行权限，兼顾功能与安全，而777使所有用户均可读写执行，极易引发安全风险。
chmod 755 和 777 到底该用哪个
绝大多数权限冲突不是因为“没给权限”，而是给了不该给的权限。777 是最危险的默认解法，它让所有用户（包括 web server 进程以外的普通用户）都能读、写、执行，一旦目录里有上传入口或可解析的脚本，就等于给攻击者开了后门。
正确做法是分角色设权：www-data（或你的 web server 用户）需要写入时，把目录属主设为它；PHP 脚本只需读取配置或模板时，chmod 755 就够了——所有者可读写执行，组和其他人可读可执行。
- 用
ls -l看当前属主和权限，别靠猜测 - 改属主用
sudo chown www-data:www-data /path/to/dir，不是只改权限 - 上传目录必须可写，但绝不应放在
webroot下且能被直接访问，比如不要放/var/www/html/uploads/，而应放/var/www/uploads/并在 web server 配置里禁止 HTTP 访问
PHP mkdir() 报错 “Permission denied” 怎么定位
这个错误不一定是目标路径没权限，更可能是父目录不可写或不可执行——Linux 下进入一个目录需要「执行」权限（x），否则连 mkdir 都无法创建子项。
例如：想创建 /var/www/app/cache/2024/06，但 /var/www/app/cache 权限是 755 且属主是 root，PHP 进程以 www-data 身份运行，就卡在进不去 cache 目录这一步。
立即学习“PHP免费学习笔记（深入）”；
- 逐级检查父目录：从
/开始，用namei -l /var/www/app/cache/2024/06查每级的权限和属主 -
mkdir()第二个参数$mode受umask影响，实际创建的权限是$mode & ~umask，所以即使写了0777，也可能变成0755 - 临时调试可用
error_log(print_r(stat('/path'), true))看真实权限值
fopen(‘w’) 失败但 error_get_last() 没报错
这种情况大概率是 SELinux 或 AppArmor 在后台拦截——它们不走传统 Unix 权限体系，也不触发 PHP 的常规错误机制，只默默拒绝系统调用。
尤其在 CentOS/RHEL 或 Ubuntu 启用了安全模块的服务器上，fopen 打开失败却查不到 Permission denied 错误信息，就是典型表现。
- 先看系统日志：
sudo ausearch -m avc -ts recent | audit2why（SELinux）或sudo dmesg | grep -i apparmor - 临时验证是否是它：用
sudo setenforce 0关 SELinux，再试一次（仅调试，勿上线） - PHP 进程需要的最小上下文：SELinux 中一般是
httpd_sys_rw_content_t，用chcon -t httpd_sys_rw_content_t /path/to/dir赋予
require_once 包含文件失败，提示 “failed to open stream: Permission denied”
这不是文件没读权限，而是 PHP 进程无法遍历到那个路径——常见于使用相对路径（如 ../vendor/autoload.php）时，当前工作目录（getcwd()）和预期不符，导致解析出错的绝对路径。
比如 CLI 下运行脚本，getcwd() 是你执行命令的位置，但 web 请求下是 DocumentRoot，两者不同，相对路径就会指向完全不同的地方。
- 统一用
__DIR__拼接：require_once __DIR__ . '/../vendor/autoload.php'; - 检查
open_basedir是否限制了可访问路径，phpinfo()里搜这一项 - 如果用了 Docker，确认挂载卷权限：宿主机文件属主是
root，容器内 PHP 用户没有读权限，要用chown -R www-data:www-data /host/path或启动时指定--user www-data
权限问题最难缠的地方，从来不是“怎么加”，而是“谁在哪个上下文里、以什么身份、走哪条路径、被哪层机制拦住”。多一层验证，少半天排查。
