html文档必须以开头，否则浏览器进入怪异模式；、（须紧贴开头）、为必备项；语义化标签（如、）关乎可访问性与seo；@supports用于渐进增强，js能力检测应使用'inset' in css.supports；服务端返回的html需是可运行最小闭环，确保js失效时核心内容仍可用。
HTML文档结构必须从开始
不写这行，浏览器就可能进入怪异模式（Quirks Mode），CSS盒模型、JS行为全不可靠。哪怕只是本地测试，也得先加这一行——它不是可选注释，是解析器的开关。
常见错误：复制粘贴时漏掉空格或写成（小写）；或者混进BOM字符导致首行失效。用VS Code保存为UTF-8无BOM格式能避开这类坑。
-
里的lang属性不能省，它直接影响屏幕阅读器发音和搜索引擎语义判断 -
里<meta charset="UTF-8">必须紧贴开头，晚于它插入其他标签可能导致乱码 -
<meta name="viewport" content="width=device-width, initial-scale=1.0">不是“响应式可选”，而是现代移动端渲染的硬性前提
语义化标签不是为了好看，而是为了让document.querySelector和辅助技术都找得到你
用<div class="header">代替<code><header></header>，表面看不出区别，但document.querySelector('header')会查不到，屏幕阅读器跳过导航区块，SEO权重也被稀释。
关键场景：一个用户用键盘Tab键浏览页面，<nav></nav>能被自动识别为导航区，<main></main>标记主体内容起点，<aside></aside>暗示附属信息——这些不是装饰，是结构契约。
-
<section></section>必须有标题（<h2></h2>或更高），否则语义断裂；<article></article>适合独立可分发的内容单元（如博客正文），不是所有<div>都该升级 <li>避免嵌套<code><header></header>inside<header></header>，同理<footer></footer>也不应包着另一个<footer></footer>，DOM层级错乱会影响无障碍树构建 - 旧项目迁移时，别一次性替换全部
<div>，先从<code><main></main>、<nav></nav>、<footer></footer>这三个最无歧义的标签切入@supports比Modernizr更轻量，但要用对地方@supports (display: grid)这类CSS规则，本质是让浏览器自己判断能力，而不是靠JS库探测后加class。它只在支持该特性的浏览器里生效，不支持的直接忽略整段规则——这才是真正的渐进增强。容易踩的坑：把
@supports当成兼容性补丁开关，比如写@supports not (backdrop-filter: blur(1px))去降级，结果发现某些浏览器连not语法都不支持，反而全挂了。- 优先用
@supports包裹视觉增强（如grid布局、inset定位），别用它控制核心交互逻辑 - JS侧想做能力检测，直接用
'inset' in CSS.supports（注意引号），比查window.CSS更准 - 不要在
@supports里嵌套媒体查询，部分旧引擎解析失败；需要组合时，外层放媒体查询，内层放@supports
服务端返回的HTML必须是“可运行”的最小闭环
所谓渐进式增强，前提是首屏HTML本身就能完成核心任务。如果服务端返回的HTML里依赖
document.getElementById('app').innerHTML = ...才出内容，那JS加载失败时页面就是白屏——这不是增强，是单点故障。真实案例：某文档站把所有章节内容藏在JS里，
里只留一个空<div id="root"></div>，结果CDN故障时整个站点不可访问。- 服务端渲染（SSR）或静态生成（SSG）输出的HTML，至少要包含标题、摘要、首段正文——这些是用户打开链接后立刻需要的信息
- 内联关键CSS时，只提取首屏可见区域样式（critical CSS），别把整套
tailwind.css塞进<style></style>标签，HTML体积超过14KB会触发移动网络的延迟渲染 - JS文件用
defer而非async，确保执行顺序；但<script defer src="/app.js"></script>之前，页面已有可用内容
<main></main>或@supports，而是每次加新功能前，先问一句：如果这段代码完全不存在，用户还能完成核心任务吗？这个判断点，往往被跳过。 - 优先用
