W3C验证通过仅表示语法符合规范，不保证代码正确、可用或用户体验达标；它无法检测动态行为、可访问性实效、浏览器兼容性及真实用户场景问题。
W3C验证通过 ≠ 代码正确或可用，更不等于用户体验达标。它只说明当前文档在语法层面符合所声明的DTD或规范草案要求，而真实项目中大量合理、必要、广泛支持的写法反而会导致验证失败。
为什么 HTML5 页面用 却仍被报错
常见现象：明明写了标准 ，<code>validator.w3.org 却提示“Element X is not permitted as child of element Y”或“Attribute Z is not serializable”。
- 验证器默认按“严格语义层级”检查，比如在
<div> 中直接放 <code><h1></h1>没问题，但若该<div> 出现在 <code><footer></footer>内且未设role，部分验证模式会警告 -
<picture></picture>+<source type="image/webp"></source>在旧版验证器中曾被标为“unknown attribute”，尽管 Chrome/Firefox 早已原生支持 - 使用
data-属性时，若值含空格或特殊字符（如data-id="user:123:prod"），某些验证器版本会误判为非法字符序列 -
aria-hidden="true"加在包含焦点元素的容器上（如<nav aria-hidden="true"><a href="#">首页</a></nav>）——验证通过，但键盘用户无法访问链接 -
role="button"用在<div> 上却没加 <code>tabindex="0"和onclick/onkeydown处理——验证无错，但无法聚焦、无法空格/回车触发 -
aria-label值与视觉文本重复（如按钮内写“提交”，又设aria-label="提交"）——验证OK，但对部分 NVDA/JAWS 组合可能引发冗余播报 -
background: linear-gradient(45deg, #fff, #000);在旧验证器中常被标为“Parse error”，尽管所有现代浏览器支持完好 -
@supports (display: grid)块内的规则，验证器可能跳过解析，导致其内部声明（如grid-template-areas）被单独标记为“unknown property” - 自定义属性（
--main-color: #333）在未启用 CSS Custom Properties 模式时，整个声明行会被当作无效语句丢弃，进而影响后续继承链判断 - 用
fetch()替换XMLHttpRequest后未处理AbortController，导致页面跳转时请求悬停——验证器完全不感知 -
<img loading="lazy" alt="W3C验证通过就绝对正确吗_规范与实践差异说明【指南】" >在 Safari 15.4 之前不支持，但验证器不会提示兼容性风险 - CSS 中写
width: min(100vw, 1200px)，验证器可能报“invalid function”，但实际 Chromium 94+ 已稳定支持
aria- 属性通过验证但实际无效的典型场景
验证器只检查属性名拼写和是否在白名单中，不校验上下文有效性。很多 aria- 写法语法合法，却因违反 ARIA 实践原则导致屏幕阅读器忽略或误读。
CSS 验证器对现代特性的“滞后性”表现
validator.w3.org 的 CSS 验证模块长期基于 CSS 2.1 规范构建，对 CSS3+ 新特性缺乏动态更新机制，导致大量生产环境常用写法被误报。
真正影响质量的关键点往往不在验证结果里
验证工具看不到 DOM 动态变化、JavaScript 行为、网络加载状态、设备像素比适配、第三方脚本注入，也测不出可访问性真实路径。一个 100% 通过验证的页面，可能在 iOS VoiceOver 下完全不可操作，或在低端 Android WebView 中白屏。
别让绿色对勾掩盖真实问题。验证是起点，不是终点；机器说“可以”，得用人眼、真设备、真实用户去确认“真的行”。
