w3c validator 用于发现html真实结构问题，它校验文档是否符合规范定义的合法结构，而非仅语法正确性；常见错误包括位置不当、缺失或嵌套错误等。
怎么用 W3C Validator 发现真实结构问题
W3C Markup Validation Service 不是“语法检查器”，它校验的是文档是否符合 HTML 规范定义的合法结构。很多看似能渲染的代码，比如漏掉 或把 <meta charset="UTF-8"> 放在 <title></title> 后面，会被它标为错误——不是因为浏览器不能显示，而是因为解析顺序和语义已偏离标准。
常见卡点：
-
<meta charset>必须出现在<title></title>之前，否则部分浏览器会触发重解析 - 多个
<h1></h1>不报错但属于警告，而<main></main>缺失或嵌套在<header></header>内则直接报错 -
<img>没有alt是警告，但<input type="text">没配<label></label>也是警告——两者对可访问性影响程度不同，但 Validator 不区分优先级
为什么 HTMLHint 比 W3C 更适合团队落地
W3C 验证器只回答“合不合法”，HTMLHint 回答“要不要这么写”。它允许你配置规则，比如禁止 style 属性、强制 <button></button> 有 type、限制 id 命名格式，这些都不是规范强制项，却是协作中容易引发冲突的实际痛点。
实操建议：
- 把
.htmlhintrc提交进仓库，避免本地配置不一致 - 禁用
attr-lowercase（属性名小写）这类冗余规则——现代编辑器和 Linter 已默认处理 - 开启
attr-no-unsafe-char和head-script-disabled，堵住 XSS 常见入口 - CI 流程中加一行：
npx htmlhint src/**/*.html --config .htmlhintrc，失败即阻断合并
沙箱 iframe 审核时容易忽略的 CSP 细节
在线运行 HTML 的沙箱环境常设 sandbox="allow-scripts"，但这不等于安全。若未同步设置 Content-Security-Policy，<script src="https://evil.com/x.js"></script> 仍可执行——sandbox 只限制 DOM 访问和表单提交，不限制资源加载。
必须配套的最小 CSP 策略：
-
script-src 'self'：禁止远程脚本，本地<script></script>仍可运行 -
object-src 'none'：关闭<object></object>、<embed></embed>，防 Flash/Java 插件利用 -
base-uri 'none'：防止攻击者篡改<base href>影响所有相对路径 - 不要用
unsafe-inline，哪怕只为了加一段调试console.log
语义化标签审核中最常被误判的三个场景
审核者看到 <div class="card"> 就打回重写，未必合理；看到 <code><section></section> 就打勾通过，也可能踩坑。语义不是标签名游戏，而是信息层级是否匹配内容意图。
典型误判：
-
<article></article>用于新闻列表项 ✔️，但用于用户评论 ❌（应为<aside></aside>或无语义容器） -
<nav></nav>包含分页链接 ✔️，但包含面包屑导航 ❌（应为<ol class="breadcrumb"></ol>+ ARIA） -
<main></main>在页面中有且仅有一个 ✔️，但它被包裹在<div id="app"> 内且该 div 有 JS 初始化逻辑 ❌（<code><main></main>应为直接子元素，否则语义链断裂）真正难的不是记住每个标签的定义，而是判断当前 DOM 片段在整页信息架构中的实际角色——这没法靠工具自动判断，得人看上下文。
