cheerio是node.js中轻量、高效、jquery风格的html解析库，通过fs.readfilesync同步读取文件，cheerio.load(content, {xmlmode: false, decodeentities: true})加载并解析，支持精准选择器定位结构/语义问题，适用于静态质量筛查。
怎么用 Node.js 快速读取并解析 HTML 文件
cheerio 是最轻量、最贴近 jQuery 习惯的解析方案，比正则稳定，比 Puppeteer 快。它不执行 JS、不渲染样式，只做结构分析——这恰恰是质量筛查需要的“纯静态视角”。
关键点：
-
fs.readFileSync比fs.readFile更适合批量扫描：避免回调嵌套，逻辑线性清晰 -
cheerio.load(content, { xmlMode: false, decodeEntities: true })必须显式关掉xmlMode，否则会把<br>
当成未闭合标签报错 - 不要用
$("body").html()提取内容——它会丢掉里的<meta>、<title></title>等关键信息 - 真实项目中常遇到 UTF-8 BOM 头导致
cheerio解析失败，建议先用content.replace(/^\uFEFF/, '')清理
哪些 HTML 问题能靠 cheerio 静态识别
不是所有问题都得跑浏览器，很多结构性缺陷在源码层就能暴露。cheerio 能稳准快抓出这几类高频硬伤：
- 缺失或重复的
id：用$("*[id]")收集所有 id 值，再用Set判重 - 孤立的
label[for]：查label[for]的值，再$("#" + forValue)看是否真有对应元素 - 空
alt但没加role="presentation"的<img>：匹配img[alt=""]:not([role="presentation"]) - 语义错用：比如
div[role="button"]但没加tabindex或aria-label -
button缺type属性：直接$("button:not([type])")即可定位
为什么不用 W3C validator API 做全部检查
nu-validator（W3C 官方服务）确实权威，但它有硬伤：超时限制严、并发数低、不返回具体行号。对 CI/CD 流水线来说，它更适合做“最终把关”，而不是日常开发筛查。
使用HTML,CSS,JavaScript开发Android应用程序 英文文字pdf版附源文件
下载
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
实操建议：
- 本地扫描优先用 cheerio 做结构/语义/可访问性初筛，90% 的问题当场定位到行号和选择器
- 只对
index.html或关键落地页调用nu-validatorAPI 做标准合规兜底 - 别把
nu-validator接入每文件扫描循环——它平均响应 2~5 秒，100 个页面就卡死 - API 返回的错误格式是 JSON，但字段名不统一（有时叫
message，有时叫extract），需预处理再映射到源码行
容易被忽略的路径与编码陷阱
脚本跑通 ≠ 跑对。很多团队写完脚本本地 OK，一上 CI 就失效，问题基本出在这几处：
-
path.join(__dirname, "../src")在不同工作目录下解析结果不同，建议统一用process.cwd()为基准 - Windows 下路径分隔符是
\，但 cheerio 内部用/做选择器，$(fileContent)不受影响，但日志打印路径时要path.normalize() - 某些 CMS 导出的 HTML 含 GBK 编码，
fs.readFileSync(file, "utf8")会乱码，得先用iconv-lite转码 - 扫描含内联
<script></script>的 HTML 时，cheerio 默认会把 JS 字符串里出现的<div> 当成真实标签解析——加 <code>script: false选项禁用脚本解析更安全真正难的不是写个能跑的脚本，而是让它在不同环境、不同编码、不同构建产物路径下，每次都能准确定位到第 42 行那个没写
alt的<img>标签。
