必须禁用777权限并隔离敏感配置：网站目录设755，仅上传/缓存等目录设775且属组为Web用户；.env等配置文件权限640、禁止Git提交、不放public下；Web服务器root指向public目录；上线前验证phpinfo、关闭display_errors但开启log_errors。
上传前必须改掉 777 权限
新手常把整个网站目录设成 777，以为“能运行就行”，结果直接暴露 Web 目录写入风险，尤其当有上传接口、缓存目录或日志文件时，攻击者可能写入恶意脚本。PHP 进程（如 www-data 或 nginx 用户）只需读取代码、有限写入日志或缓存，不需要全盘写+执行权限。
正确做法是分角色设权：
-
public/（或htdocs、web）目录：设为755，确保 Web 服务器可读可执行，但不可写 - PHP 源码目录（如
src/、app/、config/）：同样755，禁止 Web 可写 - 需要写入的目录（如
var/cache/、var/logs/、public/uploads/）：设为755或775，且属组需为 Web 用户（如chgrp www-data var/cache），避免用777 - 敏感配置文件（如
.env、config/database.php）：设为644，确认不在 Web 可访问路径下（例如不要放在public/里）
index.php 放哪、怎么被 Web 服务器识别
线上环境不是本地双击打开，Web 服务器（Nginx/Apache）必须明确知道哪个文件是入口。常见错误是把整个项目压缩包解压到 /var/www/html/，导致 index.php 和 vendor/、composer.json 全暴露在根 URL 下。
安全做法是只让 public/（Laravel/ThinkPHP 等框架标准）或自定义的 web/ 目录对外可见：
立即学习“PHP免费学习笔记（深入）”；
- Nginx 配置中
root必须指向/path/to/project/public，而非项目根目录 - Apache 启用
mod_rewrite并确保.htaccess生效（或在虚拟主机配置中显式写重写规则） - 手动测试：访问
https://yoursite.com/index.php应正常加载，但https://yoursite.com/config/或https://yoursite.com/composer.lock必须返回 403 或 404
上传后立刻检查 phpinfo() 和错误显示
很多新手传完代码就开浏览器刷首页，发现白屏却不知从哪查起。PHP 默认线上环境会关闭 display_errors，错误全进日志，你根本看不到。
上线首步应快速验证基础 PHP 环境和错误是否可见：
- 临时建一个
test.php放在public/下，内容为，访问确认 PHP 版本、扩展（如pdo_mysql、openssl）已启用 - 检查
php.ini中display_errors = Off（线上必须关），但同时确认log_errors = On且error_log路径可写（比如/var/log/php_errors.log） - 如果首页白屏，立刻看 Web 错误日志：
tail -f /var/log/nginx/error.log或tail -f /var/log/apache2/error.log，而不是反复刷新页面
数据库配置和 .env 文件别硬编码进 Git
本地开发时把数据库密码写进 .env 很方便，但一旦把这个文件传到线上，又没从 Git 忽略，等于把生产库凭据公开。更糟的是，有人直接把密码写死在 config/database.php 里，版本一推，全网可查。
必须隔离线上配置：
-
.env文件绝不能提交 Git：确认.gitignore包含.env，上传前用git status --ignored检查 - 线上部署时，手工在服务器上创建
.env，权限设为640，属主为部署用户，属组为 Web 用户（如chown deploy:www-data .env） - 若用 Laravel，确保
APP_DEBUG=false，否则异常会泄露完整路径、SQL 和环境变量
权限这事，不是“能跑通”就结束；一次疏忽的 777 或一个漏删的 .env，可能比代码逻辑漏洞更快被利用。
