用str_replace实现最简模板渲染：将{key}占位符批量替换为$data数组对应值，纯字符串处理、天然防XSS、无需额外依赖；模板须为纯文本，禁含PHP代码。
PHP里怎么用str_replace做最简模板渲染
直接上手就能跑，不用 Composer、不依赖扩展。核心就是把模板里的占位符（比如{name}）替换成真实数据。适合小项目首页、邮件模板、生成配置文件这类场景。
常见错误是硬写正则或自己拼 HTML 字符串，结果 XSS 漏洞藏得深，又难维护。用str_replace最安全——它不解析、不执行、只替换，天然防注入。
- 模板文件内容必须是纯字符串，不能含 PHP 代码；否则要改用
eval或include，那就不是“简单渲染”了 - 占位符统一用
{key}格式，避免和 JSON、CSS 冲突；别用=$name?>这种，那是 PHP 原生语法，不属于模板引擎范畴 - 批量替换时，用
str_replace的数组参数，别循环调用，性能差还容易漏替换
示例：
$tpl = "欢迎{user}，今天是{date}";<br>$data = ['user' => '张三', 'date' => date('Y-m-d')];<br>$keys = array_map(fn($k) => "{${k}}", array_keys($data));<br>echo str_replace($keys, array_values($data), $tpl);
为什么不用extract + include？
很多人第一反应是extract($data); include 'template.php';，看起来干净，但隐患多。
立即学习“PHP免费学习笔记（深入）”；
最典型的问题是变量污染：extract会把所有键变成全局变量，如果模板里写了$GLOBALS或$this，可能意外覆盖或报错；更麻烦的是，一旦$data里混入__FILE__、$_SERVER这类敏感键，模板就可能读到不该读的路径或环境信息。
- 模板文件后缀必须是
.php，但内容里不能有<?php以外的 PHP 逻辑，否则失控风险高 - 无法限制作用域，
include是在当前作用域执行，函数内用会泄漏变量 - 错误提示指向模板文件行号，但实际出错原因可能是
extract前的数据结构不对，调试绕路
遇到Notice: Undefined index怎么快速定位？
这不是模板引擎的问题，而是数据没对齐。比如模板写了{email}，但$data里只有['name' => '李四']。
别急着加@压制错误，先确认两点：模板占位符是否拼错？$data是否被中途修改过？
- 在替换前加一层校验：
$missing = array_diff_key(array_flip($keys), $data);，能立刻知道缺哪些键 - 开发期可默认填充空字符串：
$data += array_fill_keys(array_map(fn($k) => trim($k, '{}'), $keys), ''); - 注意大小写：
{Name}和['name' => 'xxx']不会匹配，str_replace区分大小写
要不要支持条件和循环？
如果需求里出现“如果登录显示退出按钮”“遍历商品列表”，说明已经超出“简单模板渲染”的边界。这时候硬塞if/foreach进字符串替换逻辑，很快就会变成状态机噩梦。
真正该做的，是拆分职责：PHP 层处理逻辑（判断是否登录、组装商品数组），模板层只负责展示。哪怕多写几行if，也比在模板里搞{% if user %}...强。
- 循环可用
array_map+ 模板片段拼接，例如：implode('', array_map(fn($item) => str_replace(['{id}', '{title}'], [$item['id'], $item['title']], $itemTpl), $items)) - 条件渲染建议提前提取变量：
$showLogout = !empty($user); $data['logout_btn'] = $showLogout ? '<a href="https://www.php.cn/link/7b9226c896ac6346c8f2087125d65704">退出</a>' : ''; - 一旦发现要写三处以上类似逻辑，就该考虑换
Twig或Blade了，别死撑
模板这东西，越早接受“它只配干一件事”，后面越省心。占位符替换看着土，但边界清晰、无隐藏行为、出问题一眼看懂——复杂度不在代码行数，在你下次改需求时敢不敢动它。
