ThinkPHP模板上手较快但有隐性门槛：非纯PHP也非Blade，依赖编译缓存，不支持任意PHP表达式；{:dump()}需开启debug；{volist}中id是作用域别名；三元运算须写全；render()自动匹配路径而fetch()显式指定；{extend}须首行无空格；{$Think.get.id}失效常因重定向导致GET丢失。
ThinkPHP 模板语法是否上手快
对熟悉 PHP 原生开发或 Laravel Blade 的人来说，ThinkPHP 的模板（think\Template）不算难，但有几处隐性门槛容易卡住：它不是纯 PHP，也不是完全类 Blade，而是一套轻量自研解析器，依赖运行时编译缓存，且不支持任意 PHP 表达式嵌入。
-
{:func()}可调用函数，但{:dump($data)}这类调试函数在生产环境默认被禁用（需开启template.debug） -
{volist name="list" id="vo"}是常用标签，但id不是变量名而是作用域别名，不能写成{volist name="$list"}—— 模板里不认$ - 模板中无法直接使用三元运算符简写（如
{$status ?: '正常'}），必须写全{$status ? '正常' : '异常'}
render() 和 fetch() 的区别与选用场景
两者都用于视图渲染，但行为差异直接影响调试效率和部署稳定性：
-
render()自动匹配控制器同名模板（如Index/index控制器 →index.html），适合常规 MVC 流程，但路径不可控，出错时提示模糊（比如报Template not found却不告诉你找的是哪条路径） -
fetch('common/header')显式指定模板路径，支持子目录、点号分隔（admin.user.list→admin/user/list.html），更适合模块化或复用布局，也方便单元测试中隔离视图逻辑 - 注意：
fetch()默认不触发模板编译检查，若模板有语法错误，可能静默失败或报Parse error在缓存文件里，建议开发期配合'template.cache_expire' => 0
模板继承中 {block} 的常见失效原因
继承机制本身简洁，但实际用起来常因路径、顺序或配置中断：
- 父模板必须用
{extend name="layout"}开头，且该语句必须是文件第一行（前面不能有空格、BOM 或注释） -
{block name="title"}默认标题{/block}中的name区分大小写，子模板中{block name="Title"}就不会覆盖 - 如果开启了模板缓存（默认开启），修改父模板后子模板可能仍用旧缓存，需手动清空
runtime/template/下对应哈希目录，或临时设'template.cache' => false -
{block}不支持嵌套定义，也不能在{php}...{/php}标签内使用
{extend name="layout"}
{block name="title"}用户列表{/block}
{block name="content"}
{$title}
{volist name="users" id="user"}
{$user.name} - {$user.email}
立即学习“PHP免费学习笔记（深入）”；
{/volist}
{/block}
为什么有时 {$Think.get.id} 拿不到 GET 参数
这是新手高频问题：不是语法错，而是变量注入时机问题。ThinkPHP 模板中 {$Think.*} 系列变量（如 {$Think.get}、{$Think.session}）并非实时读取，而是由框架在渲染前统一封装进模板变量，前提是这些数据源已被初始化。
-
{$Think.get.id}失效，往往因为当前请求是 POST + redirect 后的 GET（如表单提交后跳转），此时原始 GET 参数已丢失，get数组为空 -
{$Think.post.xxx}同理，仅在当前请求为 POST 且未重定向时有效；重定向后要用session或cookie透传 - 更可靠的方式是控制器显式赋值：
$this->assign('get_id', input('get.id'));，再在模板中用{$get_id}
模板的便捷性取决于你是否接受它的约定边界——它省去了 Composer 依赖和复杂配置，但换来了对路径规则、缓存机制和变量注入时机的强依赖。最易被忽略的其实是缓存清理节奏：改完模板不删 runtime，十有八九会看到“明明改了却没生效”的假象。
