结论是HTML质量问题必须作为交付产物验证，而非源码管理；CI阶段需校验构建后静态HTML，禁止扫描JSP/PHP源文件，并强制Unsafe前缀、契约化复用及axe-core断言。
直接说结论：JSP 和 PHP 混合系统做解耦迁移时，HTML 质量问题不能靠“统一模板引擎”解决，必须把 HTML 当作交付产物来验证，而非源码来管理。
CI 阶段必须校验最终 HTML，而不是 JSP 或 PHP 源文件
很多团队在迁移中花大量时间统一 jsp:include 和 include() 的写法，但实际问题出在渲染后——比如 JSP 里 <%= title %> 未转义、PHP 中 echo $title 直接输出，都可能让 XSS 进入最终 HTML。这些漏洞在源码层无法被 ESLint 或 PHP_CodeSniffer 捕获。
- 用
html-validate或axe-core对构建/部署后生成的静态 HTML 做断言，例如检查<form>是否缺失method、<img>是否缺alt - 禁止在 CI 中扫描
*.jsp或*.php文件——它们只是中间态，语义和安全行为由运行时决定 - 对 SSR 场景（如 Tomcat + PHP-FPM 双后端），需分别抓取两套环境下的真实响应 HTML，再比对结构一致性
动态内容注入路径必须显式标记 unsafe
JSP 的 <c:out value="${title}" /> 默认转义，而 PHP 的 <?php echo $title ?> 默认不转义；两者混用时，开发人员极易凭经验误判安全性。更危险的是，CMS 返回的富文本常被直接塞进 JSP 的 <%= rawHtml %> 或 PHP 的 echo htmlspecialchars_decode($raw)，绕过所有默认防护。
- 强制约定所有跨服务/跨语言传入的数据字段名带
Unsafe前缀，例如UnsafeArticleContent、unsafe_user_bio - 在构建脚本中用正则扫描：
grep -r "Unsafe\|unsafe_" dist/ | grep -E "(jsp|php)"，命中即阻断发布 - 模板层禁止出现
script、onerror、javascript:字符串——不是靠人工 review，而是用htmlhint的attr-unsafe-char规则自动拦截
复用片段必须脱离文件路径，改用契约化注册
老系统常见 <jsp:include page="/common/header.jsp" /> 和 <?php include 'inc/footer.php'; ?> 并存，表面是复用，实则埋下三重风险：路径硬编码导致迁移失败、变量作用域不一致引发空指针、CSS/JS 加载时机错乱造成 FOUC。
立即学习“PHP免费学习笔记（深入）”；
- 将 header、footer 等公共片段抽象为独立 HTTP 接口，返回标准化 JSON Schema，例如
{ "type": "header", "logoUrl": "...", "navItems": [...] } - 前端用
fetch()获取并渲染，或后端通过统一代理网关聚合数据，避免模板层直连文件系统 - 若必须保留服务端包含，就用契约代替路径：JSP 注册
template("site-header")，PHP 注册register_template('site-header')，调用时只认名称不认路径
最难处理的不是语法差异，而是两种语言对“HTML 是什么”的隐含假设不同——JSP 把它当视图层副产品，PHP 常把它当字符串拼接结果。治理起点不是改代码，是先定义：哪些 HTML 片段必须通过 axe 扫描？哪些字段必须走 Unsafe 前缀？哪些 include 必须退化为 API 调用？没明确这三条，任何工具链或规范都会失效。
