PostHTML本身不校验语义或可访问性，仅按插件规则修改AST；要自动插入缺失alt属性，需编写插件匹配无alt、role和aria-hidden的img标签并补alt=""，且必须返回修改后的node。
PostHTML 本身不校验语义、不检查可访问性、也不压缩或格式化 HTML——它只按插件规则改 AST。想靠它“自动提升代码质量”，必须自己写或组合插件，且每条规则都要明确对应一个可验证的质量点。
怎么用 PostHTML 自动插入缺失的 alt 属性
很多团队在图片审核时卡在「所有 <img> 必须带 alt」这一条。PostHTML 可以在构建时补全，但要注意逻辑边界：
- 只处理没有
alt属性、也没有role="presentation"或aria-hidden="true"的<img> - 装饰性图片应设
alt=""，不能硬塞占位文字（如 "image"） - 若
src是 data URL 或 base64，仍需补alt，不能跳过 - 插件必须返回修改后的
node，否则 AST 不变 —— 常见错误是只读取没赋值
示例片段（同步插件）：
posthtml([function () {
return function (tree) {
tree.match({ tag: 'img' }, (node) => {
if (!node.attrs?.alt && !node.attrs?.['role'] && !node.attrs?.['aria-hidden']) {
node.attrs = { ...node.attrs, alt: '' }
}
return node
})
}
}])
如何用 posthtml-include 替代手写 <div class="header"> 实现语义化拆分
人工维护重复的 <header>、<footer> 容易漏改、语义错位。用 posthtml-include 在构建时内联，能强制统一结构：
立即学习“前端免费学习笔记（深入）”；
- 入口 HTML 写
<include src="./components/header.html"></include>，被包含文件必须是完整语义块（含<header>标签） - 路径解析基准是入口文件所在目录，不是
<include>所在行 —— 混用相对路径时容易 404 - 不支持传参，所以
<include src="card.html" title="Hello">会直接忽略title属性 - 若被包含文件里有未闭合标签（如漏写
</section>），PostHTML 解析会失败，报错信息是Unexpected end of file
为什么 posthtml-pretty 经常让格式更糟而不是更好
很多人装了 posthtml-pretty 就以为 HTML 自动变规范了，结果发现缩进错乱、空行爆炸、甚至破坏 <pre> 里的换行。根本原因是：
- 它默认把所有文本节点当普通内容处理，不会识别
<pre>、<textarea>、<script>等需要保留原始空白的标签 - 配置项
indent控制缩进宽度，但wrap和maxLineLength若设得太激进，会强行折行破坏内联 SVG 或 CSS 字符串 - 它不理解语义层级 —— 比如不会因为
<nav>包着<ul>就多缩进一层，只是机械套规则 - 和
html-loader配合时，若postprocessor中先跑转换插件再跑posthtml-pretty，可能把已优化的结构又“格式化”回冗余状态
自定义插件检测 <button> 缺失 type 属性的真正难点
W3C 规范要求 <button> 显式声明 type="button" / "submit" / "reset"，否则表单内默认为 submit，极易引发意外提交。用 PostHTML 检测不难，但落地时三个细节常被忽略：
- 必须遍历所有
node.tag === 'button'，包括嵌套在<template>或注释中的（它们也会进 AST） -
node.attrs?.type为undefined或空字符串都算缺失，但type="button"是合法的，不能误报 - 仅检测不够 —— 更稳妥的做法是自动补
type="button"，但得加开关控制：生产环境强制补，开发环境只警告并输出console.warn到构建日志 - 若项目用了 Web Components，自定义标签名含
button（如<my-button>），要排除，否则误伤
AST 层面的代码质量提升，本质是把人工 checklist 转成可执行、可验证、可复用的节点断言。写插件时最耗时间的从来不是语法，而是厘清“什么算合格”“什么算例外”“出错了怎么反馈”。
