include + ob_start()是唯一可行路径，因为只有include能执行php逻辑（如），而ob_start()与ob_get_clean()可捕获其动态输出；file_get_contents()仅读取原始源码，导致邮件中出现而非“张三”。
直接用 file_get_contents() 读取含 PHP 逻辑的模板文件，必然导致源码泄露——邮件里出现 <?php echo $name; ?> 而不是“张三”，这不是渲染失败，是根本没执行。
为什么 include + ob_start() 是唯一可行路径
PHP 模板不是文本，是待执行的代码片段。只有 include 能触发解释器运行其中的 <?php ?>，而 ob_start() 和 ob_get_clean() 是捕获其输出的唯一标准方式。任何试图绕过执行、只做字符串替换的方案（比如 str_replace()）都只能处理静态占位符，无法支持条件、循环或函数调用。
-
file_get_contents()返回原始字节流，<?php标签原样保留，毫无例外 -
eval()理论上可行，但会执行任意代码，且错误堆栈指向字符串行号而非真实文件，调试崩溃 -
include单独使用会立即输出到响应体，无法拦截、修改或复用结果 - 必须配对使用
ob_start()和ob_get_clean()，漏掉任一环节都会导致内容丢失或重复输出
extract() 的变量污染风险怎么防
很多人用 extract($data) 简化模板内变量访问，但这是把双刃剑：一旦 $data 里混入 __FILE__、$_SERVER 或键名含空格/数字开头（PHP 8.3 会静默跳过），模板就可能意外暴露敏感信息或报错中断。
- 始终加
EXTR_SKIP：防止覆盖已存在变量，比如$data自身或$template - 避免在函数外直接
extract；封装成独立函数，让作用域天然隔离 - 不信任外部数据：对
$data做白名单过滤，或改用$data['title']显式访问，杜绝键名注入 - PHP 8.3 下若启用了
declare(strict_types=1)，非法键名不会报错但变量不可用，需提前校验
模板里哪些东西会悄悄破坏输出缓冲
ob_get_clean() 捕获的是“所有被 include 触发的输出”，包括你没意识到的空白、错误提示、甚至 echo 漏网语句。一个换行、一个未关闭的 PHP 标签、一句调试用的 print_r()，都会让最终 HTML 多出不可见字符，邮件格式错乱或前端解析失败。
- 模板文件必须以
<?php开头，禁止 BOM 和前置空格 - 文件末尾不能有多余换行或空行——PHP 会把它当纯文本输出
- 禁用
error_reporting(E_ALL)或确保display_errors = Off，否则 Notice 也会进缓冲区 - 不要在模板里调用
exit、die或未捕获异常，否则缓冲区不会被清理 - 若需调试，用
error_log()写日志，而不是echo或var_dump()
为什么不能对 $mail_template 再套 htmlspecialchars()
PHPMailer 的 isHTML(true) 依赖原始 HTML 结构（如 <p></p>、<strong></strong>）。如果在 ob_get_clean() 后再对整个字符串调用 htmlspecialchars()，所有标签都会变成 <p>，邮件变成纯文本，样式和链接全部失效。
- 转义必须在模板内部完成：
= htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8') ?> - 绝对不要在渲染后统一转义——那等于把 HTML 当作普通字符串处理
- 若模板中混入用户可控 HTML（如富文本编辑器内容），应使用
strip_tags()或白名单过滤，而非htmlspecialchars() - PHP 8.3 不提供自动转义机制，这点和 Twig / Laravel Blade 完全不同，必须手动控制
最易被忽略的点：模板路径必须是绝对路径。相对路径在 CLI、Cron 或不同路由下工作目录变化时会失效，而 include 报错又常被静默吞掉——你看到的只是空邮件，不是错误信息。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
