企业官网HTML骨架是后续样式、交互、SEO、无障碍和多端适配的底层契约；DOCTYPE必须顶格、lang值须为zh-CN、meta charset须为head内首个标签，三者出错将引发怪异模式、读屏失效、乱码等90%兼容性问题。
直接说结论：企业官网的HTML骨架不是“写完就扔”的临时结构，而是后续所有样式、交互、SEO、无障碍和多端适配的底层契约。骨架一旦出错，后期改起来成本远高于重写——尤其是 !DOCTYPE html 位置、lang 值、meta charset 顺序这三处，90% 的兼容性问题都源于它们。
为什么 !DOCTYPE html 必须顶格且前面不能有任何字符
浏览器只扫描文档开头第一个非空白字符来决定渲染模式。哪怕开头是 UTF-8 BOM（EF BB BF）、一个空格或注释 <!-- --> ，IE 和微信内置浏览器就会强制进入怪异模式（Quirks Mode），导致：box-sizing 失效、position: sticky 不工作、getBoundingClientRect() 返回异常值。
实操建议：
- 用 VS Code 打开文件，右下角确认编码为 UTF-8（不含 BOM）
- 输入
!后按 Tab，让 Emmet 自动补全标准模板，别手敲 - 检查方法：终端运行
hexdump -C your.html | head -n 1，前三个字节必须是3c 21 44（即）
lang="zh-CN" 为什么不能写成 zh 或 zh_CN
BCP 47 标准要求语言子标签用连字符分隔，地区码必须大写。写错会导致屏幕阅读器发音逻辑混乱、拼写检查器匹配不到简体词库、搜索引擎忽略语言信号。
立即学习“前端免费学习笔记（深入）”；
常见错误现象：
-
lang="zh"→ 屏幕阅读器默认按繁体逻辑读，比如“软件”读作“軟體” -
lang="zh_cn"或lang="zh-CN"混用 → 部分 SSR 框架（如 Next.js）hydration 时触发 DOM mismatch 报错 -
lang=""→ 等价于未声明，SEO 权重归零
局部英文内容应单独标注：<p lang="en">API response</p>，不要全局硬切。
meta charset 和 viewport 的位置为什么不能乱放
浏览器只扫描 <head> 前 1024 字节来确定编码。如果 <meta charset="UTF-8"> 被 <title> 或 JS 注释挡在后面，中文会直接变方框，刷新也恢复不了。
实操要点：
-
<meta charset="UTF-8">必须是<head>内第一个标签（紧贴<head>开始） -
<meta name="viewport" content="width=device-width, initial-scale=1.0">必须在<title>之前，否则某些 Android WebView 会忽略 - Webpack/Vite 的
html-webpack-plugin默认不注入viewport，得手动配置meta选项
<main> 为什么不能嵌套在 <div id="app"> 里
<main> 是语义化主内容容器，规范要求页面中只能有一个，且必须直接承载主要内容。把它塞进 <div id="app">（常见于 Vue/React SSR 输出）会导致：
- Chrome DevTools 的 Accessibility 面板报 “No accessible name”，说明屏幕阅读器无法定位主内容区域
- SEO 工具（如 Lighthouse）判定语义结构缺失，影响可访问性评分
- 部分无障碍辅助技术跳过该区域，用户无法快速导航到核心内容
正确做法：SSR 渲染时，确保 <main> 是 <body> 的直接子元素；若用框架，把 <main> 放在根节点外，或用 aria-labelledby 显式关联标题。
真正难的不是写多少标签，而是每个标签的位置、属性值、嵌套关系背后都有明确的规范约束。骨架搭歪了，后面加再多 CSS 和 JS，也只是在沙上盖楼。
