ThinkPHP 访问不到 index.php 导致 404 的根本原因是 Nginx 未将伪静态请求重写至 index.php，需配置 try_files $uri $uri/ /index.php?$query_string; 并确保 root 指向 public/ 目录、静态资源 location 优先且放行、SCRIPT_FILENAME 与 root 对齐、文件权限正确。
ThinkPHP 为什么访问不到 index.php 就 404？
不是代码问题，是 Nginx 根本没把请求转给 PHP 处理。默认配置下，Nginx 只认真实存在的文件，而 ThinkPHP 的 URL 是伪静态（比如 /user/list），背后实际要走 index.php 入口，但 Nginx 不知道该转发——它直接去磁盘找 /user/list 这个路径，当然 404。
关键点在于：必须让 Nginx 把所有非静态资源请求，全部重写到 index.php，再由框架自己解析路由。
- 静态资源（
.js、.css、.png等）要放行，不走重写，否则性能崩、缓存失效 -
try_files是最稳妥的写法，比rewrite更少出错；try_files $uri $uri/ /index.php?$query_string;是核心 - 务必确认
root指向的是public/目录，不是项目根目录；否则index.php路径会错 - 如果用了子目录部署（比如
https://example.com/app/），location块要带前缀，且try_files中的/index.php要对应成/app/index.php
Nginx 配置里 fastcgi_param SCRIPT_FILENAME 为什么总报 No input file specified？
这是最常见的 502 或 500 错误根源。Nginx 找到了 index.php，但传给 PHP-FPM 的文件路径错了——PHP 收到的是一个不存在或权限不对的路径。
根本原因：Nginx 的 root 和 fastcgi_param SCRIPT_FILENAME 没对齐。
立即学习“PHP免费学习笔记（深入）”；
- 如果
root /var/www/myapp/public;，那fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;才正确 - 千万别写死成
/var/www/myapp/public/index.php，否则换环境就挂 - 检查 PHP-FPM 的
security.limit_extensions是否包含.php（默认是，但有些精简镜像会删掉） - 用
ls -l /var/www/myapp/public/index.php确认文件存在且 Nginx 用户（如www-data）有读取权限
ThinkPHP 的 URL_MODEL 和 Nginx 重写怎么配合？
ThinkPHP 的 URL_MODEL（现在叫 url_commonly 或 url_route_must）只影响框架内部生成 URL 的方式，**不影响 Nginx 怎么转发请求**。Nginx 重写规则本身和这个配置无关——它只管“所有非静态请求都推给 index.php”。
但上线时容易混淆：你开了 url_route_must = true，结果 Nginx 没配好，页面全是 404，就以为是框架配置问题。
- 只要 Nginx 正确重写，
url_route_must和url_commonly都能工作 - 如果你用的是 ThinkPHP 6+，确保
config/app.php中'url_domain_deploy' => false（除非真需要二级域名路由） - 调试时临时加一行
echo $_SERVER['REQUEST_URI']; die();到public/index.php开头，看 Nginx 是否真的把原始 URL 传进来了
上线后 CSS/JS 404 或者页面空白，但 HTML 能加载？
说明 Nginx 重写生效了，但静态资源被错误地也重写进了 index.php，导致 PHP 尝试解析 JS 文件——当然失败，返回空或乱码。
典型表现：浏览器 Network 面板里，style.css 返回状态码 200，但响应体是 HTML 内容。
- 必须在
location ~ \.(js|css|png|jpg|gif|svg|ico|woff2?)$块里显式加try_files $uri =404;，禁止 fallback 到index.php - 注意正则顺序：静态资源
location必须写在主重写location /之前，Nginx 匹配是按配置顺序的 - 如果用了 CDN 或反向代理，检查是否缓存了错误响应（比如 200 空内容），清缓存再试
- 用
curl -I https://yoursite.com/static/css/app.css看返回的Content-Type是不是text/css，不是就说明被 PHP 处理了
最常被忽略的其实是 root 路径和 public/ 目录权限的组合问题——配置看着全对，但 Nginx 用户根本读不了那个目录，连日志都不报错，只默默返回 403 或 404。
