html-validate报错因语义校验严格：rel="preload"必配as属性，as="font"需加crossorigin；href含构建占位符、link写在title前、as值非法等均触发错误；需手动启用head-valid-content-model等规则并排除构建目录。
为什么在里还会被html-validate报错
不是位置错了，是校验器在查语义合法性，不是“放对地方就万事大吉”。rel="preload"必须带as属性，否则直接报Attribute "as" is required for link with rel="preload"；as="font"时还必须配crossorigin，否则校验器认为字体加载策略不明确——浏览器可能容忍，但html-validate会卡住。
常见踩坑点：
-
href值含构建占位符（如/assets/[hash].js），校验器无法解析路径，标为Bad value for attribute href -
<link rel="preload">写在<title>之前，部分规则配置仍按旧规范判为结构违规 -
as="fetch"这种非法值会被拒，必须按真实资源类型填：script、style、font、image等
html-validate怎么配置才真能拦住头部问题
默认规则几乎不拦危险操作。比如<meta charset>没放在<head>前几行，或<script>没defer就塞进<head>，默认都放过。必须手动开关键规则：
- 启用
head-valid-content-model：防止<script>错放位置，或<link rel="preload">混在<meta>中间被误判 - 加
charset-not-first：确保</meta charset>是<head>里第二或第三个标签（紧挨<title>后） - 排除构建产物目录：
"files": ["src/**/*.html", "!dist/**", "!build/**"]，只校源码，不校最终HTML - 禁用
img-redundant-alt同时开img-req-alt，避免alt=""被当成合规而漏掉空描述
preload和fetchpriority同时用反而失效
fetchpriority="high"对已preload的资源完全无效——preload本身已锁定Highest优先级，信号被覆盖。更麻烦的是，如果同时写了loading="lazy"，Chrome会强制把优先级降为Low，fetchpriority直接被忽略。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
真正起效的前提很苛刻：
-
src必须在HTML源码里就有真实值，不能是data-src或JS后续注入 - 图片得有
width/height，且处于首屏可视区，否则浏览器连“是否关键”都判断不了 -
preload只适合三类资源：关键字体（as="font"+crossorigin）、CSS背景图对应image、内联JS里马上要import()的模块
preconnect/prefetch和preload别混用
三者语义完全不同，混用等于给浏览器发矛盾指令。preconnect只写域名（如https://fonts.googleapis.com），不指定路径；prefetch指向用户**可能访问的下一页**，不是当前页资源；preload只针对当前页**立刻要用**的关键资源。
典型错误组合：
- 对
https://api.example.com做preconnect，又对/api/user做preload——HTTP接口不可预加载，preload会被忽略 - 用
prefetch拉一个JS文件，但页面里又用同步<script src>引入同一URL——Lighthouse会报“重复预取”，html-validate配合no-duplicate-prefetch规则也会警告 -
preconnect写了未实际使用的域名（比如声明了Google Fonts但页面根本没加载任何字体），W3C不拦，但html-validate的no-unused-preconnect会标记
最容易被忽略的点是：所有这些提示符的效果，都依赖于href路径与最终实际请求URL完全一致。构建工具注入的哈希、CDN前缀、环境变量拼接，都会让preload失效——校验器能发现路径非法，但发现不了“路径合法却命中不了缓存”。
