PDF导出返回404主因是路由或静态文件处理失败：检查Symfony路由是否正确定义并启用，Nginx需为.pdf配置独立location块避免误转至index.php，禁用session依赖改用getOutputFromHtml，确保响应头完整且内容有效。
PDF导出请求返回404，通常不是PDF生成本身出错，而是路由或静态文件处理环节断掉了——比如你生成完PDF后用 Response::make($pdfContent, 200)->header('Content-Type', 'application/pdf') 直接返回，但用户点击下载链接时却触发了404，这说明请求根本没进控制器，被Nginx/Apache拦在了外面。
检查PDF下载链接是否走对了路由
确保前端发起的PDF请求（如 /export/invoice/123）对应一个真实定义的Symfony路由，且该路由绑定到能返回PDF Response的控制器动作。常见错误包括：
- 路由名拼写错误或未启用，运行
php app/console router:debug | grep export确认路由存在 - 使用了子域名但没在
routing.yml中声明host条件，导致本地能访问、线上404 - EasyAdmin 或其他Bundle自动注册的导出路由被覆盖或未加载
避免把PDF当静态文件被Nginx误判
如果你把PDF临时存到 public/exports/xxx.pdf 并用URL直接访问（如 https://example.com/exports/invoice-123.pdf），那必须确保Nginx不把它转给 index.php 处理——否则Symfony找不到这个路径，就返回404页面。
- 在Nginx配置中为
.pdf显式添加 location 块，例如：location ~ \.pdf$ { add_header Content-Type application/pdf; try_files $uri =404; } - 不要依赖通用
try_files /index.php /index.php;—— 它会把所有没匹配到的请求都甩给 index.php，包括 PDF 文件 - 确认
public/exports/目录可读，且PDF文件真实存在、权限正确（如 www-data 可读）
别让PDF响应被重定向吞掉
某些场景下，PDF生成前需要登录态，而你用了 getOutputFromUrl() 渲染受保护页面，结果Snappy发起的HTTP请求没带session cookie，被防火墙重定向到 /login，最终PDF内容是HTML登录页——浏览器尝试解析它为PDF失败，可能静默报错或显示空白，有些客户端甚至会把重定向响应当成404处理。
- 一律改用
getOutputFromHtml($html)：在控制器里先$html = $this->renderView('invoice/print.html.twig', [...])，再传给Snappy - 确保模板中所有资源路径用绝对URL，例如
{{ absolute_url(asset('images/logo.png')) }}，否则图片字体加载失败，PDF虽生成但内容残缺 - 若必须用URL渲染（如第三方报表），请勿依赖 session，改用带时效的token参数，并在目标控制器中校验，而非靠Cookie
验证PDF响应头和内容完整性
即使控制器成功执行，返回的Response若缺少关键头或内容为空，部分浏览器或下载工具也会表现为“打不开”或“404-like”行为（实际是200但内容无效）。
- 强制设置
Content-Disposition: attachment; filename="invoice-123.pdf"，避免浏览器试图在线打开 - 用
file_put_contents('/tmp/test.pdf', $pdfContent)本地保存并手动用PDF阅读器打开，确认生成无误 - 检查PHP内存限制（
memory_limit），Dompdf等库处理复杂HTML易OOM，导致输出为空字符串
