cms模板输出html易出问题，因其不校验渲染结果，仅填充数据；混用内联js、手动拼接或绕过api易致标签缺失、属性混乱、xss漏洞；需在ci中生成全站快照并用htmlhint扫描，结合dompurify清洗用户输入，严控插件注入行为，将校验前置至构建环节。
为什么CMS模板输出的HTML容易出问题
CMS（如WordPress、Drupal、Strapi）本身不校验模板渲染结果，它只管把数据塞进{{content}}或里。一旦模板里混用内联JS、手动拼接字符串、或开发者绕过CMS API直接操作DOM，生成的HTML就可能缺失<doctype></doctype>、漏闭合<div>、属性大小写混乱、甚至注入未转义的用户输入——这些在静态HTML里一眼可见的问题，在CMS动态渲染后反而更难定位。
<h3>HTMLHint必须跑在构建后、部署前</h3>
<p>不能只在开发时本地跑<code>htmlhint index.html，CMS生成的页面往往来自数据库+模板组合，真实输出路径是/public/blog/post-123.html这类动态路径。正确做法是：在CI流程中加一步生成全站快照，再批量扫描。
- 用
puppeteer或playwright访问所有路由，保存为本地HTML文件 - 执行
htmlhint ./dist/**/*.html --config .htmlhintrc - 配置
.htmlhintrc启用tag-pair、attr-lowercase、id-unique等硬性规则，禁用attr-no-duplication这类CMS插件可能绕过的宽松项 - 把
htmlhint退出码设为非零时中断CI，避免带问题HTML上线
模板层要主动拦截危险输出
CMS模板引擎（如Twig、Liquid、Nunjucks）默认不做XSS防护，{{ user_input }}直接输出等于裸奔。必须明确区分“原始内容”和“已清洗内容”：
- 禁止在模板里出现
{{ raw_html | safe }}这类标记，除非你100%控制来源 - 对所有用户提交字段（评论、富文本编辑器内容）强制走
DOMPurify.sanitize()后再插入，而不是靠前端JS补救 - 模板中
<img src="%7B%7B%20url%20%7D%7D">这类属性，必须校验url协议是否为https:或data:，拒绝javascript:或blob: - 避免用
innerHTML = templateString拼接，改用textContent或dataset传参
别忽略CMS插件引入的HTML污染
很多SEO、广告、统计插件会通过wp_head()或drupal_add_js()注入脚本和样式，它们生成的HTML常不遵守语义规范——比如把<script></script>塞进中间、插入无alt的<img>、甚至覆盖<title></title>。这类问题不会出现在你写的模板里，但会出现在最终HTML中。
- 用
curl -s https://yoursite.com/ | grep -A5 -B5 "script"快速抽检第三方脚本位置 - 在
.htmlhintrc里加script-placement规则（需自定义），强制<script></script>只能在末尾或前 - 定期审查插件源码，禁用那些直接
document.write()或appendChild()的旧版插件
CMS模板输出的HTML治理难点不在语法，而在责任分散：前端写模板、后端配插件、运营填内容。没人对最终HTML负责，就容易变成“谁最后碰谁背锅”。真正有效的治理，是把校验点卡在构建流水线里，让问题在生成那一刻就被挡住，而不是等用户报错才去翻源码。
