PHP脚本必须设644而非755，因其由Web服务器通过解释器读取执行，无需执行位，755反而易被误执行或探测；上传目录应设755并禁用PHP解析，绝不可用777。
755 和 777 不是“够不够用”的选择题，而是“谁该碰、谁不该碰”的安全边界问题。关键不在数字本身，而在权限背后对应的操作主体和执行场景。
PHP脚本文件为什么必须是644，而不是755
PHP 文件由 Web 服务器（如 Nginx 或 Apache）调用 PHP 解释器读取并执行，不需要文件自身具备执行位（x）。设成 755 反而埋下隐患：
- 若服务器配置出错（例如误启 CGI 模式或 AddHandler 规则不当），.php 文件可能被当作二进制直接运行，触发未预期行为
- 攻击者上传的恶意脚本若与正常 PHP 文件同目录，755 权限会让它更容易被探测、访问甚至执行
- 组和其他人拥有执行权限毫无必要——Web 进程通常只以单一用户（如 www-data）身份运行
正确做法是统一设为 644：所有者可读写，Web 用户可读，其他人仅可读。命令示例：chmod 644 *.php。
上传目录为什么不能只靠755就放心
upload/ 类目录确实需要 Web 进程写入，但开放执行权限等于主动邀请 Webshell 上线。
- 权限设为 755 或更严的 750（推荐），绝不用 777
- 必须配合 Web 服务器禁用 PHP 解析：Nginx 中加
location ~ \.php$ { deny all; }；Apache 中用 - 理想方案是将上传目录移出 Web 根目录，再通过 alias 或符号链接对外提供访问，实现物理隔离
只改权限却不堵解析入口，就像锁了门却忘了关窗。
755 和 777 的本质区别：写权限归谁
两者核心差异不在“能不能读”或“能不能进”，而在于“谁可以改”：
- 755 = rwxr-xr-x：仅所有者能写，组和其他人只能读和进入目录（对目录而言，x 表示可 cd 和访问子项）
- 777 = rwxrwxrwx：所有人（所有者、组、其他人）都能读、写、执行——任意登录用户都可删、改、覆盖
777 在生产环境几乎无正当用途。临时调试可用，但上线前必须收回。很多主机商甚至会自动拦截或重置 777 权限，视为风险信号。
权限配错的常见假象：不是不够，而是太乱
ThinkPHP runtime 写入失败、Laravel storage 报 Permission denied，常被误判为“权限太小”，实则是属主错配或 SELinux/AppArmor 干预：
- 先确认 PHP-FPM 实际运行用户（查
/etc/php/*/fpm/pool.d/www.conf中的 user/group） - 再用
chown -R www-data:www-data runtime/统一属主（把 www-data 换成你环境的真实用户） - 最后设权限：
find runtime/ -type d -exec chmod 755 {} \;和find runtime/ -type f -exec chmod 644 {} \; - CentOS/RHEL 系统需检查 SELinux 日志（
dmesg | grep avc），用semanage fcontext配置 httpd_sys_rw_content_t 上下文
盲目 chmod 777 不仅掩盖真实问题，还会让安全机制直接拒绝服务（如 PHP-FPM 的 security.limit_extensions 会拦截 777 目录下的写操作）。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
