结论：Nginx配置错一个字符（如try_files顺序错误、PATH_INFO缺失、root路径不匹配）会导致Symfony直接返回404或500且无具体错误；核心在于配置位置、修改权限、缓存清理三要素，而非单纯语法优化。
直接说结论：Nginx 配置错一个字符，Symfony 就会返回 404 或 500，且不报具体错误；核心不是“怎么配”，而是“在哪配、谁有权改、改完要不要清缓存”。
为什么 try_files 顺序错了就 404？
常见现象：访问 /about 返回 Nginx 404，但 /index.php/about 能正常加载 —— 这说明请求根本没进 PHP，更没到 Symfony 路由层。
-
try_files $uri $uri/ /index.php?$query_string;必须严格按此顺序：先查静态文件（$uri），再查目录（$uri/），最后兜底到/index.php - 漏掉
$query_string→ 所有 GET 参数（如?page=2）丢失，路由匹配失败 - 写成
try_files /index.php?$query_string $uri $uri/;→ 永远先走/index.php，静态资源（CSS/JS）全被 PHP 处理，404 率飙升 - 共享主机上若不支持自定义
nginx.conf，这行配置根本加不进去，别硬刚，换方案
fastcgi_param PATH_INFO 不设就 500？
典型症状：Nginx access.log 有记录，error.log 空，PHP 错误也不显示，页面白屏 + 500 —— 很大概率是 PATH_INFO 为空导致 Symfony 路由解析崩溃。
- 必须配合
fastcgi_split_path_info ^(.+\.php)(/.*)$;使用，否则$fastcgi_path_info取不到值 -
fastcgi_param PATH_INFO $fastcgi_path_info;这一行不能少，也不能写成$path_info（旧写法已废弃） - 如果用的是 PHP-FPM Unix socket（如
unix:/run/php/php8.2-fpm.sock），PATH_INFO 行为和 TCP 方式一致，无需额外处理 - 检查
phpinfo()输出里$_SERVER['PATH_INFO']是否为空，空就是没生效
资产路径 404 却找不到文件在哪？
现象：浏览器请求 /css/app.css 404，但 public/css/app.css 确实存在 —— 根本原因不是 Nginx 配置，而是 Web 根目录和项目部署路径不一致。
- 共享主机通常强制把 Web 根目录设为
public_html/，而你把整个 Symfony 项目放进了public_html/myapp/，那么真实可访问路径是/myapp/css/app.css - 在
.env中必须显式设置：ASSET_BASE_URL=/myapp（注意开头的/） - 不要依赖 Twig 的
{{ asset('css/app.css') }}自动推断，它默认按域名根路径生成 - 检查
public/下文件权限：上传后常为600，需手动改为644，否则 Nginx 读不了
为什么 APP_ENV=prod 还报开发环境错误？
现象：明明设置了 APP_ENV=prod，却仍看到 Symfony 调试工具栏或未定义路由异常 —— 缓存没生效，或环境变量根本没加载。
-
APP_ENV必须在 Web 服务器启动时注入，不是只改.env就行；Nginx + PHP-FPM 场景下，需在php-fpm.conf或 pool 配置里加：env[APP_ENV] = prod - 运行
php bin/console cache:clear --env=prod后，务必手动删掉var/cache/prod/目录再试，共享主机常因权限问题写入失败却不报错 - 检查
public/index.php开头是否含$_ENV['APP_ENV'] ??= 'prod';，否则环境变量可能被忽略 - 部署后首次访问必须触发缓存生成，直接 curl
/一次比等用户点进来更可靠
最易被忽略的点：Nginx 配置改了，PHP-FPM 重启了，但浏览器还缓存着旧的 301 重定向（比如从 /app.php/about 到 /about），清掉本地 DNS 和浏览器缓存再测。
