不是。symfony 不强制绑定 twig，但官方骨架和核心组件默认深度集成 twig；换引擎需手动实现 templatingengineinterface 并注册服务，否则 form_theme、is_granted()、asset() 等功能失效，且生态兼容性、安全特性和维护成本显著升高。
Symfony 默认只支持 Twig 吗？
不是。Symfony 本身不强制绑定 Twig，但官方骨架（skeleton）和所有核心组件（如 FrameworkBundle、TwigBundle）默认集成并深度适配 Twig。你完全可以不用 Twig，但得手动剥离、替换、补全大量胶水逻辑。
常见错误现象：TemplateNotFoundException 或 Unable to find template 报错后，有人试图直接写原生 PHP 模板（.php 文件），却发现 render() 方法根本不认——因为 Response 渲染流程依赖 TemplatingEngineInterface 实现，而默认容器里只注册了 Twig 引擎。
- 要换引擎，必须显式注册一个实现该接口的自定义服务（比如用 Plates、Latte 或原生 PHP 封装）
-
templating配置项在 Symfony 6+ 已被标记为废弃，意味着官方连“兼容性支持”都在收缩 - 路由、表单、安全等组件生成的 HTML 片段（如
$form->renderRow()）内部硬依赖 Twig 的TwigRenderer
不用 Twig 会丢掉哪些功能？
不是“少几个语法糖”，而是部分 Symfony 功能会直接失效或退化成半成品。
-
form_theme：表单主题定制完全基于 Twig block 继承机制，换引擎后需重写整套渲染逻辑 -
security.authorization_checker在模板中调用is_granted()时，底层走的是 Twig 扩展，非 Twig 模板无法直接使用 - 资产管理（
asset()、encore_entry_script_tags()）函数由 Twig 扩展提供，PHP 模板里只能手写路径或重复造轮子 - 调试工具（Web Debug Toolbar 中的模板渲染时间、已加载模板列表）仅捕获 Twig 调用
如果坚持用原生 PHP 模板，要注意什么？
可行，但属于“自建地基”级别改造，不是简单换后缀名。
- 必须禁用
TwigBundle，并在config/bundles.php中移除它 - 手动实现
TemplatingEngineInterface，并注册为templating.engine.php服务（注意命名，Symfony 会按此识别） - 所有控制器中
return $this->render('template.php', $params)调用仍可用，但$this->render()内部会委托给你的引擎——你要自己处理路径解析、继承、缓存等 - PHP 模板里不能直接用
{{ app.user.username }}这类 Twig 表达式；变量得靠<?php echo $user->getUsername(); ?>，且$app、$request等全局变量不会自动注入
性能和维护成本差异在哪？
Twig 编译为原生 PHP 代码，首次加载有编译开销，但后续执行和原生 PHP 模板几乎无差别。真正影响维护的是生态断层。
- 社区 Bundle（如
EasyAdminBundle、LiipImagineBundle）99% 只提供 Twig 模板，你要么复制修改，要么 fork 后重写视图层 - 升级 Symfony 主版本时，Twig 升级路径明确（看
UPGRADE-文件），而自研模板引擎没人帮你测兼容性 - 团队协作中，新成员熟悉 Twig 成本远低于理解你封装的 PHP 模板抽象层
最常被忽略的一点：Twig 的 sandbox 模式、自动转义、严格变量检查这些安全特性，在手写的 PHP 模板里极易遗漏，而且一旦漏掉，就是 XSS 或信息泄露风险。
