frameworkbundle:template:template是最轻量渲染twig模板的方式，适用于privacy.html.twig等纯展示页面，无需控制器，但不支持传参；路径需相对于templates/目录。
用 FrameworkBundle:Template:template 直接渲染 Twig 模板
这是最轻量、无需写控制器就能返回静态页面的方式，适合纯展示型内容（如 privacy.html.twig、terms.html.twig）。它本质是 Symfony 内置的一个通用控制器，只做一件事：加载并渲染指定模板。
常见错误现象：Unable to find template "AcmeBundle:Static:about.html.twig"——路径写错，或模板没放在 templates/ 下对应目录；或者用了旧版 Bundle 结构但项目已迁移到现代 Symfony（无 Bundle）。
使用场景：
- 法律类页面（隐私政策、服务条款）
- 单页介绍（About、FAQ、Contact）
- 临时维护页（
503.html.twig配合error_controller）
关键配置示例（config/routes.yaml）：
acme_privacy:
path: /privacy
defaults:
_controller: FrameworkBundle:Template:template
template: 'static/privacy.html.twig'
options:
expose: true
注意：template 值是相对于 templates/ 的路径，不是完整文件系统路径；不支持传参给模板（$this->render('...', ['foo' => 'bar']) 这种能力不存在）。
用 Stenope 构建全站静态 HTML 文件
Stenope 不是“运行时渲染”，而是把整个 Symfony 应用在构建时（bin/console stenope:build）爬取、执行、快照成纯 HTML 文件，输出到 ./static 目录。它适用于需要极致性能、CDN 托管、无 PHP 环境部署的场景。
容易踩的坑：
- 所有路由必须能被
stenope:build访问到（即不能依赖未登录态无法触发的逻辑，比如未设默认值的查询参数） - 动态内容（用户头像、实时计数器）会固化为构建那一刻的快照，无法更新
- 若模板中调用
$this->isGranted()或security.token_storage，构建时会因无 token 报错，需提前 mock 或跳过
适用场景：
- 企业官网、文档站点（内容稳定、SEO 敏感）
- 营销落地页（需快速上线、高并发承载）
- 离线可用的内部工具前端（打包进 Electron 或 PWA）
它和普通 Symfony 路由共存：你既可以保留 /admin 动态后台，又让 /docs/* 全部走静态生成。
用 asset() + public/ 目录托管真正静态资源
很多人混淆“静态页面”和“静态资源”。真正的静态 HTML 页面（非 Twig 渲染）可直接放 public/ 下，例如 public/maintenance.html，然后通过 NGINX 直接响应，完全绕过 Symfony 内核。
为什么这么做？因为 asset() 函数只管 URL 生成，不管内容来源；而 NGINX 的 try_files 可以优先命中物理文件，不进 PHP。
NGINX 配置要点（放在 location / 块内）：
location / {
# 优先尝试匹配 public/ 下的真实文件
try_files $uri $uri/ /index.php?$query_string;
}
# 单独为 maintenance.html 开绿灯（不走 PHP）
location = /maintenance.html {
add_header Cache-Control "public, max-age=3600";
try_files /maintenance.html =404;
}
这种做法的边界很清晰：它不经过任何 Symfony 逻辑，没有 Twig 变量、没有安全校验、没有路由解析。适合真正“一成不变”的 HTML，比如服务器级维护页、SSL 检查页、或第三方要求的验证文件（/.well-known/security.txt）。
为什么不能总用 controller 返回 static HTML 字符串？
有人会写一个 HomeController::maintenance()，里面直接 return new Response(file_get_contents('public/maintenance.html'))。这看似简单，但实际埋了三个隐患：
- 每次请求都读磁盘，没利用 OPcache，比 NGINX 直接 sendfile 慢 3–5 倍
- HTTP 缓存头要手动设（
Response::setPublic()->setMaxAge(3600)），漏了就变成 no-cache - 如果
public/权限配置不当，file_get_contents可能失败，而 NGINX 会静默返回 404
真正静态的内容，就该交给 Web 服务器处理；需要动态能力的，才交给 Symfony。混用反而增加故障点和调试成本。
