PHP与HTML混用关键在于规范输出上下文：用户数据必须过滤（htmlspecialchars或HTMLPurifier），模板禁用业务逻辑和危险函数，统一路径生成，按上下文选择转义方式。
PHP 与 HTML 混合写不是错，但随意混用会快速导致维护困难、逻辑泄漏、XSS 风险和缓存失效。关键不在“能不能混”，而在“在哪混、怎么混、谁负责输出”。
PHP 输出 HTML 时必须过滤用户数据
直接 echo $_GET['name'] 或 = $_POST['email'] ?> 是高危操作，浏览器会把输入当 HTML 解析，造成 XSS。
- 对纯文本内容，一律用
htmlspecialchars()，并指定ENT_QUOTES和字符编码：echo htmlspecialchars($_GET['q'], ENT_QUOTES, 'UTF-8');
- 若需保留有限 HTML（如富文本），不能靠白名单正则硬拦，应使用专用库如
HTMLPurifier；strip_tags()不够安全，它不处理属性里的 JS 事件（如onerror） - 输出到 JavaScript 字符串或 HTML 属性中时，需额外转义：
json_encode($str, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT)是更稳妥的选择
避免在 HTML 模板里写复杂 PHP 控制逻辑
一个 .php 文件里塞满 if/foreach 嵌套、SQL 查询、函数调用，会导致模板不可复用、无法静态预览、IDE 自动补全失效。
- 视图层只做「数据展示」：变量插值、简单循环、条件显示（
if ($user->is_active)可以，if (get_user_role($id) === 'admin')不行） - 业务判断、数据获取、格式转换全部前置到控制器或服务类中，传给模板的应是已加工好的数组或对象
- 禁止在模板中调用
file_get_contents()、mysqli_query()、date_default_timez等非渲染相关函数
one_set()
用短标签需确认服务器配置且统一风格
安全通用；= $name ?> 简洁但依赖 short_open_tag = On； $name ?> 已被 PHP 8.0+ 移除，绝对禁用。
- 团队项目必须在
php.ini中显式设置short_open_tag = Off，然后统一用—— 避免部署到新环境时模板全挂 -
= ?>可用于简单变量输出，但不要用于表达式：= $user->getName() ?>可以，= $a + $b ?>易读性差，应先赋值再输出 - 所有模板文件顶部加
（如果项目启用严格类型），防止弱类型隐式转换污染视图
分离静态资源路径与 PHP 渲染上下文
写死 /assets/css/app.css 看似简单，但遇到子目录部署（如 https://example.com/myapp/）、CDN 切换、版本哈希时立刻崩盘。
- 定义统一路径生成函数，如
asset('css/app.css')，内部根据$_SERVER['SCRIPT_NAME']或配置自动补前缀 - CSS/JS 中的图片路径也走该函数，不要在 HTML 里写
background: url(images/icon.png)—— 这类路径由构建工具处理，不属于 PHP 渲染职责 - 避免在 HTML 中拼接 PHP 变量进 URL 查询参数：
href="list.php?sort== $sort ?>&page== $page ?>"容易漏转义，应改用http_build_query()构造完整查询字符串
最常被忽略的是「模板继承链中的输出上下文切换」—— extends / include 的文件可能在不同 HTML 上下文中被引入（比如在 内部却输出了未转义的 HTML 实体），这时候 htmlspecialchars() 就不够用了，得按上下文选 js_escape()、attr_escape()、css_escape()。没有银弹，只有分场景防御。
