子模板中同名{% block %}是彻底替换父内容，非追加；需用{{ parent() }}保留并扩展父内容，且必须在block内单次调用。
子模板里直接写同名 {% block %} 就是覆盖
覆盖不是“注册”或“声明”，而是“重写”。只要子模板中定义了和父模板完全同名的 {% block %}，渲染时就会用子模板的内容替换父模板中该 block 的全部内容（包括默认内容）。
常见错误是以为写个空 {% block sidebar %}{% endblock %} 就算“隐藏”了侧边栏——其实它只是覆盖为空，但 block 仍存在、仍被 Twig 解析执行。如果父模板里 {% block sidebar %} 包含了 {{ render(controller(...)) }} 这类逻辑，覆盖为空会直接跳过执行，这是预期行为；但如果父模板依赖该 block 输出 HTML 结构（比如包裹 div），那空覆盖可能导致布局错乱。
- 覆盖会彻底丢弃父模板中该 block 的所有内容，不保留默认值
- 若需保留父内容并追加，必须显式调用
{{ parent() }} - block 名区分大小写，
content和Content是两个不同 block - 不能在同一个模板里多次定义同一 block，Twig 会报
SyntaxError: A block can only be defined once
{{ parent() }} 不是可选功能，是安全扩展的前提
很多开发者在子模板里写 {% block javascripts %}<script src="custom.js"></script>{% endblock %}，结果发现 jQuery 或全局初始化脚本没了——因为父模板的 javascripts block 里原本就写了基础 JS，而你覆盖时没留它。
{{ parent() }} 必须出现在子模板 block 内部，且只能调用一次（多次调用会重复输出）。它不是函数调用，而是 Twig 的编译期指令，指向父模板中同名 block 的原始内容。
- 想追加资源？写在
{{ parent() }}后面：{% block javascripts %}{{ parent() }}<script>app.init();</script>{% endblock %} - 想前置插入？写在
{{ parent() }}前面：{% block javascripts %}<script>earlyLoad();</script>{{ parent() }}{% endblock %} - 多级继承（A → B → C）时，
{{ parent() }}总是指向上一级（B），不是最顶层（A） - 如果父 block 本身为空（
{% block foo %}{% endblock %}），{{ parent() }}输出也为空，不会报错
漏定义 {% block %} 是静默失效，不是报错
父模板里没声明 {% block footer %}，子模板却写了 {% block footer %}© 2026{% endblock %}——这行代码完全无效，Twig 会忽略它，也不会警告。页面上照样显示父模板原来的页脚（如果有），或者什么也不显示（如果父模板根本没写页脚 HTML）。
这种“漏定义”问题极难调试，尤其当团队协作、模板分层较深时。典型表现是：某个区域怎么改子模板都没反应，检查半天才发现父模板压根没开这个 block 口子。
- 基础模板（如
base.html.twig）应提前规划好所有可能被定制的区域：至少title、stylesheets、content、javascripts - 不要依赖 HTML 结构“暗示”可覆盖点，Twig 不解析标签，只认
{% block %}标签 - 用编辑器高亮或静态分析工具（如 PHPStan + Twig extensions）可提前发现未声明 block 的调用
条件性覆盖必须靠逻辑判断，不能靠 block 命名
没有 {% block sidebar if is_admin %} 这种语法。所谓“条件覆盖”，本质是在子模板的 block 内部写 {% if %} 判断，控制内容输出与否。
例如，想让后台页面显示侧边栏、前台页面隐藏，不能靠换 block 名，而要在子模板里做判断：
{% block sidebar %}
{% if app.request.attributes.get('_route') starts with 'admin_' %}
{{ parent() }}
{% endif %}
{% endblock %}
注意：这里用了 {{ parent() }} 而不是硬编码内容，是为了复用父模板已有的侧边栏结构（比如容器 div、通用样式类等），只控制是否渲染。
- 条件判断写在 block 外部（如
{% if %}...{% block %}...{% endblock %}{% endif %}）是无效的——block 定义必须在顶层作用域 - 避免在 block 内部做复杂计算或数据库查询，Twig 不适合放业务逻辑
- 若条件分支较多，建议提取成独立 macro 或自定义 Twig 函数，保持模板干净
真正麻烦的从来不是“怎么写覆盖”，而是“谁负责定义 block”和“覆盖后是否破坏了父模板的结构契约”。一个没文档的 base 模板，配上随意覆盖的子模板，三个月后谁都看不懂页面为什么突然塌了。
