应避免使用 twig/blade 和 eval()，推荐用 preg_replace_callback 解析 {{ $var }} 并结合 ob_start()+extract()+include 安全渲染；需校验路径、处理未定义变量、兜底捕获解析错误。
为什么不用现成的 Twig 或 Blade
因为要嵌入轻量工具、定制渲染逻辑，或者只是想搞懂模板怎么“把变量塞进 HTML 里”。现成引擎太重，eval() 又太危险——得在安全和可控之间找平衡点。
用 preg_replace_callback() 解析 {{ $var }} 语法
这是最直接、不依赖外部库的方式。核心是把 {{ $name }} 这类标记替换成 PHP 变量访问表达式，再用 extract() 注入数据上下文。
常见错误现象：Undefined variable 报错、变量没被替换、双大括号被当成普通文本输出。
- 必须用单引号包裹正则模式，避免 PHP 提前解析
$符号 - 匹配模式推荐：
/\{\{\s*\$([a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*)\s*\}\}/，能过滤非法变量名 - 回调函数里要用
isset($data[$key]) ? $data[$key] : ''，别直接$data[$key]，否则未定义变量会报 Notice - 注意：不能处理嵌套表达式如
{{ $user->name }}或{{ $items[0] }}，那是更复杂解析器的事
用 ob_start() + include 执行模板文件
比字符串替换更灵活，支持原生 PHP 语法（<?php echo $title; ?>），也更容易调试。
关键不是“怎么写模板”，而是“怎么隔离作用域”。直接 include 会污染当前变量空间，所以得靠输出控制缓冲和作用域封装。
- 先调用
ob_start()开启缓冲 - 用
extract($data, EXTR_SKIP)把数据导入当前作用域，EXTR_SKIP防止覆盖已有变量 - 然后
include模板文件（路径需校验，禁止 ../ 路径穿越） - 最后
return ob_get_clean()拿到渲染结果 - 模板文件里不能有
return或exit，否则会中断执行
为什么不能直接 eval() 模板字符串
虽然技术上可行，但风险极高：用户可控的模板内容一旦含 system('rm -rf /') 就完蛋。哪怕加白名单也难防绕过。
真实项目中，只要模板来源不可信（比如 CMS 后台可编辑），就必须拒绝 eval()。哪怕只是本地开发玩具项目，也建议养成习惯——用 include 已经足够快，且天然受限于文件系统权限。
真正容易被忽略的是错误处理：模板里 PHP 语法错，会直接抛出 Parse Error，而你无法在 include 时捕获它。得靠 set_error_handler() + ob_end_clean() 做兜底，不然整个页面就崩了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
