模板注释不参与PHP运行但保留在编译缓存中，混淆后易暴露敏感信息、破坏PHPDoc关联、干扰文档生成，须部署前清除注释、禁用模板PHP、清空缓存。
ThinkPHP 模板注释本身不会被混淆工具处理，也不参与 PHP 代码的运行逻辑，但它在代码混淆场景下容易被忽略——不是因为注释会被改写，而是混淆后它可能暴露关键信息、干扰调试，甚至成为安全盲区。
模板注释不进 PHP 编译流程，但会原样保留在编译缓存中
ThinkPHP 模板引擎（think-template）将模板文件（如 index.html）编译为纯 PHP 文件，存于 runtime/cache/ 目录。这个过程保留所有模板注释（{// 单行}、{/* 多行 */}），包括开发时留下的接口说明、字段含义或临时调试标记。
- 混淆工具只处理 PHP 源码（
.php文件），对模板文件（.html、.htm）默认不扫描 - 但编译后的 PHP 缓存文件里，模板注释会变成 PHP 注释（如
// {// 单行}），若未清理缓存，上线后仍可被直接查看 - 尤其当注释中包含数据库字段名、API 路径、密钥占位符等，就构成信息泄露风险
混淆后模板注释与 PHPDoc 失去上下文关联
开发者常在控制器方法上用 PHPDoc 写参数说明（如 @param int $page），再在模板里用 {// 对应 $page：当前页码} 做呼应。一旦 PHP 代码被混淆：
- 函数名、参数名被替换成
$a、$b，IDE 和 phpstan 无法再通过反射匹配模板注释中的变量名 - 模板里写的
{// $page 参数来自 UserController::list()}变成无效指引，维护者难以追溯数据来源 - Swagger 等文档生成工具读不到原始 PHPDoc，导致 API 文档缺失，而模板注释又不被其识别
生产环境必须禁用模板 PHP 代码，否则注释+代码组合更危险
有人为“方便调试”开启 template.tpl_deny_php = false，并在模板里混写 <?php // 这是数据库查询逻辑 ?>。混淆后这类内容：
立即学习“PHP免费学习笔记（深入）”；
- 不会被混淆工具处理，但可能含真实 SQL 片段、配置路径、硬编码 token
- 若混淆器误判为字符串并 base64 加密，解密后反而让敏感内容更隐蔽、更难审计
- 配合
{php}...{/php}标签使用时，注释若写成{php} // 连接测试库 {@link config/database.php}，等于主动暴露路径
安全建议：三步清掉隐患
不是靠混淆保护注释，而是主动管理注释生命周期：
-
部署前自动清除模板注释：用脚本遍历
view/目录，删掉所有{//和{/*开头的块（正则/\{\s*\/\*[\s\S]*?\*\s*\/\s*\}/i和/\{\s*\/\s*[^\}]*\}/） -
禁止在模板注释中写敏感词：如
password、key、secret、绝对路径、内网域名，一律改用泛化描述（如“用户凭证字段”） -
混淆后强制清空 runtime/cache：避免旧编译文件残留带注释的 PHP 代码，防止通过 URL 直接访问缓存文件（如
/runtime/cache/xxx.php）
