为什么ThinkPHP的layout_on配置与extend无关【避坑】

在很多ThinkPHP开发者眼里，布局功能似乎总带着点玄学色彩——明明开启了 layout_on，可模板里的 {extend} 就是不奏效；反过来，用了 {extend} 又觉得全局布局没被应用。其实真相很简单：这两套机制压根就不是一个物种，底层实现、触发时机、配置要求全都不同，混为一谈自然要踩坑。

先记住一个核心结论：layout_on 是视图引擎的“外层包装”逻辑，而 {extend} 是模板编译阶段的“继承注入”行为。它们各自独立运行，互不依赖，也互不影响。

layout_on 是全局包裹式布局

这种模式属于配置驱动的“套壳”操作：只要在 config/view.php（或TP5的 config/template.php）里把 'layout_on' => true 打开，并指定一个 'layout_name'，那么所有通过 return $this->fetch() 渲染的模板，都会自动被套进这个布局文件里。布局文件中用 {__CONTENT__} 占位，子模板的内容会自动填充进去。整个过程不依赖模板语法，引擎直接在外层包裹。

• 生效前提：配置文件中必须开启 layout_on 并指定布局模板路径
• 适用场景：控制器中直接 $this->fetch('index') 的写法，如果是链式调用 $this->view->engine->layout() 则不生效
• 禁用方式：在子模板首行写 {__NOLAYOUT__}，或者临时关闭配置

extend 是模板继承式布局

这和配置完全无关——它是模板引擎在编译阶段主动解析 {extend} 标签后执行的继承行为。哪怕 layout_on 关着，只要子模板第一行写对了 {extend name="layout/base"}，引擎就会去加载父模板，然后用子模板中的 {block} 标签替换父模板中同名的 {block} 内容。

• {extend} 必须严格位于子模板第一行第一个字符，前面不能有空格、BOM、注释或PHP标签，否则引擎直接忽略
• 父模板路径是相对于 view_path 的，TP6起需要显式带后缀，比如 {extend name="layout/base.html"}
• 父模板中必须定义同名的 {block} 标签，否则子模板的 {block} 内容会被静默丢弃

为什么常被混淆？

两者名字里都带“布局”，目标也都是复用头部底部，但设计定位完全不同。layout_on 适合全站统一样式，比如后台管理系统的整体框架；而 {extend} 适合分层清晰、多级嵌套的复杂页面结构，比如前台多主题站点。新手最容易犯的错误是：配好了 layout_on，就想当然地认为 {extend} 也会自动跑起来——实际上引擎在解析子模板时根本没去检查那行标签，因为 layout_on 阶段已经完成了外层包装，子模板内部的 {extend} 就不会再被触发了。

• TP6 默认移除了 {extend} 语法支持，需要手动安装 think-template 并设置 'type' => 'Think' 才能启用
• layout_on 对 return $this->fetch() 无效的情况，常见于没有意识到它只作用于底层 fetch() 调用，而控制器中常使用的是视图对象的链式调用
• 混用 {include} 和 {extend} 时要注意：{include} 是运行时引入，{extend} 是编译期注入，两者作用域不重叠，不能互相覆盖

怎么选才不踩坑？

小项目或只需要简单套头尾的场景，用 layout_on 配合 {include} 最省事，配置一两行就能搞定。中大型项目需要分区块定制、支持多级继承，那就必须上 {extend} + {block}，虽然配置稍复杂，但灵活度远超包裹式布局。至于TP6的新项目，建议优先考虑 think-view + {include} 的组合，稳定且无兼容风险，毕竟 {extend} 在TP6里已经不算原生支持了。