应配置 Nginx 拒绝访问敏感文件：location ~ /.(env|git|svn|hg|project) { deny all; }，确保 .env 位于项目根目录而非 public 下，设置权限为 640 并属主部署用户、属组 web 用户。
ThinkPHP .env 文件被直接下载怎么办
Nginx 默认不处理 .env，用户访问 /env 或 /.env 时，如果路径匹配不到路由，就可能把文件原样吐出去。这不是 ThinkPHP 的错，是 Nginx 没拦住。
最简单有效的做法是在站点配置里加一条拒绝规则：
location ~ /\.(env|git|svn|hg|project) {
deny all;
}
注意：~ \. 是正则匹配，点号要转义；deny all 比 return 403 更稳妥，避免某些版本 Nginx 对 return 的继承行为出问题。
- 别只写
location = /.env—— 这种精确匹配防不住/public/.env或大小写变体 - 别依赖 ThinkPHP 自身的路由拦截 ——
.env在框架启动前就可能被读取 - 上线前用 curl 测：
curl -I https://yoursite.com/.env，看返回是不是 403
Nginx 配置里 root 和 alias 写错导致 .env 可见
常见错误是把 ThinkPHP 的 public/ 目录用 alias 指向，却没注意 alias 的路径拼接逻辑，结果让 Nginx 实际映射到了项目根目录。
立即学习“PHP免费学习笔记（深入）”；
正确写法只有这一种：
root /var/www/your-project/public; index index.php;
如果非要用 alias（比如二级目录部署），必须补全路径且末尾带斜杠：
location /subpath/ {
alias /var/www/your-project/public/;
try_files $uri $uri/ /index.php?$query_string;
}
-
alias值末尾的/缺不得，否则/subpath/.env会被拼成/var/www/your-project/public.env，反而绕过拦截 -
root是拼接整个 URI，alias是替换 location 路径 —— 混用极易越权暴露上层文件 - 检查 Nginx 配置生效范围：虚拟主机块、server 块、location 块里的 root 是否层层覆盖
Linux 文件权限设太松，.env 被 PHP 读取后又被 Web 用户间接获取
即使 Nginx 拦住了直接下载，如果 .env 权限是 644 或更松，而 PHP 进程又运行在 web 用户（如 www-data）下，攻击者可能通过其他漏洞（如任意文件读取、日志包含）拿到内容。
安全底线是：.env 只能被 PHP 进程读，不能被 web 用户直接读。
- 执行
chmod 640 .env，然后确认 PHP 进程用户（如www-data）属于该文件所属组 - 不要用
755或644—— 这等于把数据库密码贴在门口 - 检查
ls -l .env输出，确保 owner 是部署用户（如deploy），group 是www-data，且 group 有读权限 - CI/CD 自动部署时，记得在最后一步重设权限，避免 git clone 带来默认宽松权限
ThinkPHP 自带的 env 加载机制与部署时的冲突点
ThinkPHP 5.1+ 默认从项目根目录加载 .env，但如果你把入口 index.php 放在 public/，而 .env 却放在 public/ 下——那就彻底暴露了。
标准结构必须是：
/var/www/your-project/ ├── .env ← 在项目根，不在 public 下 ├── app/ ├── public/ ← Nginx root 指向这里 │ └── index.php └── think
如果误把 .env 放进 public/，就算 Nginx 拦了 /.env，也拦不住 /public/.env（因为 public 是 root）。
- ThinkPHP 不会主动校验
.env位置是否安全，它只按约定找 - 部署脚本里别用
cp -r . /var/www/...全量复制，要排除.env或单独处理 - 本地开发用
.env.local覆盖，上线时删掉或改名，避免误传
最麻烦的不是配置多难，而是改完 Nginx、调完权限、挪完文件位置之后，忘了删测试时放 public 里的那个备份 .env —— 它比所有防护都管用。
