OpenAI Doug曝光：预训练模型与API开发实战指南
2026/8/29 23:31:18
最近在帮部门做校招技术面试，连续面了十几个应届生，发现一个很有意思的现象：聊项目经历、聊框架原理，很多人能聊得头头是道，但只要把问题落到 HTML 上，立刻就能看出功底深浅。
不是他们不会写标签，而是他们对 HTML 的理解停留在“会用”层面，一旦被问到“为什么”“底层是什么”“浏览器怎么处理”，就答不上来了。
这篇文章我把校招面试中关于 HTML 的高频考点、易错点和深层原理全部梳理一遍。不背八股，不讲废话，每一个知识点都尽量说清楚“是什么、为什么、怎么用、面试官在考察什么”，给准备校招的同学一个可以直接参考的复习框架。
1. 语义化不是背标签，而是表达信息层级
1.1 语义化到底在考什么
面试官问“谈谈你对 HTML 语义化的理解”，本质上想知道的不是你能不能背出 article、section、aside 这几个词，而是三点：第一，你知不知道语义化解决了什么问题；第二，你在实际项目中会不会主动用；第三，你能不能说清楚语义化和无障碍、SEO、代码维护之间的关联。
先说结论：HTML 语义化，就是用最合适的标签表达最准确的内容结构。div 是万能的容器，但容器不表达任何含义。h1 表示页面最高层级的标题，nav 表示导航区域，article 表示一篇独立完整的内容。这种“含义”本身，就是语义化要传递的信息。
很多同学回答语义化时只会说“对 SEO 友好”，这话没错，但不完整。搜索引擎爬虫解析页面依赖语义标签来判定内容权重和结构，这是语义化的收益之一，但不是全部。
更要命的是，如果你理解不了语义化，你就理解不了后面所有和 HTML 结构相关的面试题，因为浏览器、搜索引擎、屏幕阅读器都是把 HTML 当作一棵有语义的树来处理的。
1.2 高频考点：每个语义标签的使用场景
校招面试里最常出现的语义标签组合，就这几个：
- header：页面头部或者某个区块的头部。注意，一个页面可以有多个 header，不是只能有一个。
- nav：导航链接的容器。但并不是所有链接组都叫 nav，只有主要导航才适合。
- main：页面主内容区域，一个页面只能有一个 main，不要多个。
- article：独立成文的内容块，比如一篇博客、一条评论、一个新闻条目。判断标准是脱离页面上下文它依然读得通。
- section：一个主题分组，通常带一个标题。很多人把所有 div 换成 section，这是不对的。
- aside：侧边栏、补充信息、与主内容关联度低的内容。
- footer：页面底部或区块底部，一般放版权、联系方式。
面试官通常会追问的场景是：“页面上的广告位用什么标签合适？” 答案不是 aside，因为 aside 是补充信息，而广告是独立于内容之外的。语义化标签里没有一个叫 ad 的标签，但 HTML5 时代之前大家用 div 加 class="ad"，现在更合理的方式是继续用 div，搭配 role 或 aria-label 标明用途，这涉及到一个原则——没有合适语义标签时，宁可用 div，也不要为了语义化而强行套一个不贴切的标签。
还有一个高频追问：“如果页面上有个展示文章摘要和图片的列表，用 article 还是 section？” 正确答案是 article。因为每一条摘要都是独立可分发的内容，即使只是摘要，它也具备文章的属性。
1.3 一个让面试官点头的回答示范
你可以用这个思路组织答案，我自己在面试中遇到对面候选人这样作答，一定会给加分：
先解释语义化是什么：用具备特定含义的标签构建页面结构，让结构和表现分离。再解释解决了什么问题：人看代码时能从标签名直接判断内容功能；机器（浏览器、搜索引擎、读屏软件）能理解页面层级和重点。接着举实际例子：比如标题用 h1+h2 构建层级，而不是用 span 加粗加大样式；导航用 nav 而不是 div 加 click 事件；正文图片用 figure + figcaption 而不是裸 img。最后补一句：语义化不能脱离项目盲目使用，更重要的是保持层级清晰、标签使用一致。
这样的回答有定义、有背景、有案例、有边界感，和那种“语义化就是 SEO 好”的干巴巴答案完全不是一个量级。
2. doctype 与浏览器兼容模式：细节里的分水岭
2.1 标准模式与怪异模式
<!doctype html> 这行声明，几乎每个 HTML 页面都有，但校招面试里能把它讲透的人很少。它为什么重要？因为它决定浏览器用什么模式解析渲染页面：标准模式还是怪异模式（也叫 quirks mode）。
怪异模式是浏览器为了兼容旧时代不规范页面而保留的一种渲染模式。当年 IE 和 Netscape 竞争时期，页面书写极其混乱，浏览器只能靠“猜”来解析，后来标准确立，但为了不让老页面全面崩坏，浏览器引入了模式切换：有 doctype 就按标准模式走，没有 doctype 就退回怪异模式。
这里有一个面试官最爱埋的坑：如果没有写 doctype，会发生什么？答案是浏览器会以怪异模式渲染页面，而怪异模式和标准模式在盒模型、行高、图片垂直对齐等很多 CSS 渲染细节上都不一样，最终表现就是“页面为什么和我写的 CSS 效果不一样”。
只用一句话记就行：DOCTYPE 是浏览器渲染模式的开关，HTML5 的申明极其简单，只有一行，但它的存在决定页面按什么规则渲染。
2.2 盒模型差异是核心
怪异模式最典型的影响是盒模型计算方式。标准模式下，width 指的是内容区宽度，padding 和 border 是额外加的，盒子的实际宽度 = width + padding + border。怪异模式下，width 指的是整个盒子的宽度，padding 和 border 会被“挤”进去，也就是说实际内容区宽度变窄。
我自己遇到过一个线上问题，一个老系统页面没有 doctype，里面的一个卡片组件在 Chrome 里宽度正常，在旧版浏览器里就撑破布局，排查半天发现是怪异模式惹的祸。后来把 doctype 补上，再针对少数兼容样式做了微调，问题就结束了。
面试中如果被问到“怪异模式和标准模式的区别”，能把盒模型差异讲清楚，再补一句“所以在项目里一定要确认页面有正确的 doctype”，就已经超出大多数候选人的回答了。
2.3 这一题还能延伸什么
追问一：HTML5 的 doctype 为什么这么短？ 因为 HTML5 不再基于 SGML 定义，不需要引用 DTD，所以一行就够。这个知识点说明你了解 HTML 的版本演进历史。
追问二：同一个页面在 IE 和 Chrome 里渲染效果不一样，可能是什么原因？ 除了浏览器引擎差异，一个很可能的原因就是 doctype 缺失导致 IE 进入怪异模式。这个追问考察的是调试思路和浏览器原理，不是死记硬背。
追问三：标准模式怪异模式之外还有没有第三种？ 有，几乎标准模式，出现在一些过渡 DTD 申明下。这个知道即可，校招不会被深挖，但说出来会显得知识体系完整。
3. meta 标签：一张页面里信息密度最大的标签
3.1 charset 与乱码问题
meta 标签可能是除了 title 之外，页面里出现频率最高的元素，但它往往被忽视。热词列表里反复出现 <!doctype html> 和 meta 的组合，也说明很多人在网上复制页面模板时，对这段代码只知其然不知其所以然。
的作用是告诉浏览器：这个文档使用 UTF-8 字符编码。如果编码声明不对，浏览器默认的解析方式和文件实际编码不一致，就会出现乱码。
很多初学者遇到过“页面中文变成锟斤拷”的情况，原因一般就是两种：文件本身保存为 GBK，但页面声明 UTF-8；或者文件没有声明编码，浏览器自动检测错误。解决方案是把 meta 标签放在 head 最前面，控制在 title 之前。为什么？因为浏览器解析到 meta 编码声明前，如果已经按默认编码解析了部分内容，再切换编码就可能出现乱码，所以编码声明要尽可能靠前。
一个小知识：HTTP 响应头也可以声明 charset，而且优先级高于 HTML 内的 meta。如果你改了页面里 meta 编码还是乱码，去检查服务器响应头。这个知识点在面试中不容易被问到，但实际排查中很有用。
3.2 viewport 参数逐个拆解
这行是移动端页面的标配。可以逐个拆开讲清楚：
- width=device-width：让页面布局视口的宽度等于设备屏幕宽度。移动端浏览器默认的布局视口宽度一般是 980px 左右，如果不设置，页面会先按 980px 渲染再缩放，字会小得看不清。
- initial-scale=1.0：定义页面初始缩放比例为 1，也就是不缩放。
- maximum-scale、minimum-scale、user-scalable 这几个参数，通常不建议设置。特别是 user-scalable=no 会禁用用户缩放，对可访问性有负面影响，面试时被问到这点能主动说出“不建议禁用缩放”，会是不错的加分项。
核心原理是“视口”这个概念。移动端有布局视口、视觉视口、理想视口之分，width=device-width 就是告诉浏览器把布局视口设置成理想视口的宽度。这个知识在校招面试里出现概率很高，因为它是移动端适配的基础。
3.3 容易忽略的 http-equiv 与 SEO 相关 meta
meta 有一个 http-equiv 属性，可以模拟 HTTP 响应头功能。最常见的两个用法：
，这个在老项目中很常见，作用是告诉浏览器使用最新可用的渲染引擎，只对 IE 有效。现在基本用不到了，但老项目维护中会碰到。
，作用是 5 秒后跳转，但现在不推荐用这种方式做跳转，因为对可用性和 SEO 都不好，跳转逻辑应该在 JS 或服务端处理。
SEO 相关的 meta 主要是 meta keywords 和 meta description。keywords 对搜索引擎的影响已经微乎其微，description 会影响搜索结果摘要展示，但页面的标题和内容质量才是决定排名的核心因素。面试时被问“怎么写 meta 标签做 SEO”，注意不要全盘否定 meta 的价值，但也要说明白搜索引擎的核心逻辑是内容质量和外链权重。
这一节想强调的重点是：meta 标签虽然只是一小行代码，但它背后关联的是字符编码原理、HTTP 协议、移动端适配、SEO 策略，每一块都能延伸出不少面试考点。
4. 渲染流程与资源加载：从 HTML 角度回答“性能优化”
4.1 一起梳一遍关键渲染路径
面试官如果问你“HTML 和性能优化有什么关系”，先别急着背那些缓存、压缩、CDN 的答案，回到 HTML 本身：浏览器拿到 HTML 之后要做什么？
整个过程叫关键渲染路径，大致是：下载 HTML 字节 → 解析 HTML 构建 DOM 树。解析过程中遇到 CSS 会请求并解析构建 CSSOM 树。DOM 和 CSSOM 合并成渲染树。然后计算布局（Layout），确定每个节点的位置和尺寸。最后绘制（Paint），把像素画到屏幕上。
这个过程中，HTML 的影响主要体现在两个地方。第一，HTML 结构越简单、嵌套越浅，DOM 树构建越快，布局越容易计算。第二，HTML 里引用的外部资源（CSS、JS、图片、字体）会阻塞解析过程，尤其是没有任何异步标记的 script 标签。
面试时不要求你完整复述整条流水线的每一步细节，但至少要说清楚“解析到 script 会暂停 DOM 构建，因为脚本可能修改 DOM”，这句话是整个资源加载优化问题的钥匙。
4.2 script 标签的三个状态：默认、async、defer
script 标签有三种加载执行方式，这是校招面试 HTML 题目里最经典的知识点，没有之一。
默认状态：解析 HTML 时遇到 script，立刻下载并执行，执行期间暂停 HTML 解析。这就是“阻塞解析”的含义。
async 属性：下载过程不阻塞解析，下载完成后立即执行。执行时机无法保证在 DOMContentLoaded 之前还是之后，所以 async 脚本之间不保证执行顺序。适合独立无依赖的第三方统计脚本。
defer 属性：下载过程不阻塞解析，等 HTML 解析完成后、DOMContentLoaded 事件之前执行。多个 defer 脚本会按文档顺序执行。适合操作 DOM 的业务脚本。
用一个类比解释：默认状态像一条单车道，遇到 script 所有车都必须停下来等它过完再走。async 像应急车道，各走各的，谁快谁先到。defer 像一个路口排队过，按顺序走，但不会把整条路堵死。
| 加载方式 | 是否阻塞 HTML 解析 | 执行时机 | 多个脚本执行顺序 |
|---|---|---|---|
| 默认 | 是 | 下载完成后立即执行 | 按文档顺序 |
| async | 否 | 下载完成后立即执行 | 不保证 |
| defer | 否 | HTML 解析完成后，DOMContentLoaded 之前 | 按文档顺序 |
面试官追问“jQuery 老项目里应该用 defer 吗”，可以这样回答：如果业务脚本依赖 DOM 结构，用 defer 是安全的，执行顺序也有保障。但现代项目里更推荐把脚本放在模块化体系中，用 ES Module 的方式来管理依赖和加载时机，script type="module" 的默认行为本身就类似 defer。
4.3 preload、prefetch、preconnect 的适用场景
这一层是加分项。HTML 的 preload 和 prefetch 可以提前告诉浏览器某些资源需要加载，从而优化加载时机。
preload 是“当前页面马上要用”，比如字体文件、首屏大图、关键 CSS 或 JS。写法是 ，注意 as 属性一定要写对，因为它决定资源优先级。
prefetch 是“下一个页面可能要用”，比如用户可能点击的详情页资源、懒加载列表后续图片。写法是 。prefetch 的优先级很低，会在空闲时加载。
preconnect 是提前建立到目标服务器的连接，适用于跨域请求较多的场景。比如页面加载了大量第三方 CDN 资源，可以<link rel="preconnect" href="https://cdn.example.com">。
这三个手段都属于“资源提示”，面试时能说出来，并且能区分各自适用场景，就已经证明你对页面加载优化有真实思考，而不是只会背“减少请求数、合并压缩文件”这些通用方法论。
5. form 表单与 label：校招面试最容易被问倒的细节
5.1 label 的 for 和作用原理
前端开发每天和表单打交道，但很多面试者在 label 这个基础标签上翻车。
label 的作用是把一段文字和某个表单控件关联起来。关联方式有两种。一种是显式关联，label 添加 for 属性，值等于控件的 id。另一种是隐式关联，把控件直接放在 label 内部。
为什么面试官爱考这个？因为它关联到一个重要交互细节：点击 label 文字时，焦点会自动跳到关联的 input 上，对于单选按钮和复选框，点击 label 就等于点击了控件本身，命中区域大幅扩大。
如果面试官继续追问“label 不能绑定哪些元素”，答案是 display: none 或 visibility: hidden 的元素无法获得焦点。还有一种情况是 input 设置了 hidden 属性（不是 type="hidden"），关联 label 也无法点击触发。实际开发中我常用的一种做法是：自定义 checkbox 时把原生 input 设为 opacity: 0 并绝对定位覆盖在自定义样式上层，这样既能保留键盘可访问性，又能点击 label 触发原生控件。
5.2 button 的 type 默认值是一个经典深坑
有五年经验的前端也可能在这上面翻车。button 有三种 type：submit、reset、button。默认值是 submit，没错，浏览器规范里 button 不写 type 时，默认就等于 submit。
所以如果页面上在表单里写了一个<button>查询</button>，点击后页面会刷新，因为表单提交了。正确做法是用按钮先一律显式声明 type="button"，除非你真的要提交表单。
这个点在校招面试里出现率极高。因为实战项目里表单提交大多改为 AJAX 方式，如果按钮还保持默认 submit 行为，页面就会被刷新一次，接口返回的数据全没了。很多同学遇到过这个问题但没意识到根源是 button type。
5.3 禁用态、校验与新增 input 类型
HTML5 给表单带来了很多原生能力，面试里值得提的包括：
input 的 required 属性可以做必填校验，pattern 属性可以自定义正则校验，maxlength 限制输入长度，这些都能在不写任何 JS 的情况下完成基础校验。但注意原生校验的 UI 在不同浏览器里表现不一致，生产环境通常还需要统一的校验交互和错误提示，所以不能直接依赖原生校验来替代业务校验逻辑。
disabled 和 readonly 的区别也要能说清。disabled 会让控件值不参与表单提交，readonly 的值会参与提交。disabled 控件不会触发点击事件，readonly 可以正常聚焦选择复制。这是表单方向的高频追问。
HTML5 新增的 input type 包括 email、tel、number、url、date、color、range、search 等，移动端键盘会随 type 变化，比如 type="tel" 弹出数字键盘，这是一个常被忽略但很实用的细节。面试时能提到“移动端 input type 影响键盘类型”，面试官会确认你是做过真实移动端项目的。
6. 可访问性：从“加分项”变成“必问题”
6.1 为什么面试官开始问可访问性
最近两三年，不管大厂还是中小公司，前端面试里可访问性出现的频率明显变高。背后原因一是产品合规要求越来越严格，无障碍成为必须；二是业界对听障、视障、认知障碍人群的数字化体验越来越重视，可访问性变成前端工程师的基本素养之一。
可访问性的英文缩写是 a11y，因为 accessibility 这个词有 11 个字母。面试官问 a11y，其实是在考察你有没有“用户不只是视力正常、操作鼠标的年轻人”这个意识。
6.2 最容易上手的三件事：alt、aria、焦点
第一件事是图片的 alt 属性。alt 不是可有可无的，它是图片在无法加载、被屏幕阅读器朗读时的替代文本。装饰性图片应该写空 alt="" 而不是省略 alt 属性，因为空 alt 会告诉屏幕阅读器“这张图可以跳过”，省略则会被朗读出图片文件名或 URL。
第二件事是 ARIA 属性。ARIA 是 WAI-ARIA 规范，用于在 HTML 语义无法满足需求时，给元素补充语义信息。常见的 aria-label 给元素添加可读名称，aria-hidden="true" 让辅助技术忽略该元素。注意一点：不要在原生可交互元素多余地加 aria，比如 button 本身就具备按钮语义，你不应该删掉它再换成 div 加 aria。
第三件事是焦点管理。可访问性的核心原则之一就是“所有交互功能都能通过键盘完成”。这意味着自定义弹窗打开时焦点要移入弹窗并锁定，关闭时焦点要还给触发按钮；tab 键的焦点顺序要符合预期；focus 样式不能被 outline: none 粗暴移除。面试时可以主动说“我不会直接删 outline，而是用更精致的 focus-visible 样式替代”，这会让面试官知道你真正理解键盘用户的需求。
6.3 一段代码演示无障碍优化
来一个实际例子。一个自定义的评分组件，可以用三个方式提升可访问性：
原生语义上用 role="radiogroup"，每个星星是 role="radio"。键盘操作上支持方向键切换评分，而不是只能鼠标点击。对当前分数用 aria-valuenow 或 aria-label 明确朗读“当前评分 4 分，满分 5 分”。
这段代码不需要多复杂，但能说明你理解“语义、键盘、读屏”三个层次。如果你在项目里实际做过类似优化，面试时拿出来讲，比任何背诵都有说服力。
可访问性是一个长期积累的领域，不可能靠面试前突击几天就能完全掌握。但作为校招生，能说清楚 alt、ARIA、键盘焦点这三个基础层次，已经足以证明你比大部分候选人多想了一步。
7. HTML 面试题答题技巧：把“知道”变成“理解”
7.1 典型错误与正确答法对照
| 问题 | 典型错误回答 | 加分回答思路 |
|---|---|---|
| 谈谈语义化 | 语义化对 SEO 好 | 用哪些标签、解决什么问题、如何判断边界 |
| doctype 有什么用 | 告诉浏览器是 HTML5 | 控制渲染模式，模式差异影响盒模型 |
| script 为什么放 body 底部 | 因为会阻塞 | 说明阻塞的原理是暂停 HTML 解析，配合 async/defer |
| label 有什么用 | 关联表单 | 点击命中区域扩大、屏幕阅读器识别、自定义控件兼容 |
| 无障碍做了什么 | 加 alt | 语义、键盘操作、焦点管理三层循环 |
对比之后你会发现，所有“加分回答”的共同点是：从“是什么”上升到“为什么”和“怎么做”。这一思维转换比背一百道题都管用。
7.2 答 HTML5 新特性时的思路
面试官问“HTML5 有哪些新特性”，很多人的答案像报菜名：语义化标签、canvas、video、localStorage…… 报完就没了。
更好的答法是分类加场景。比如分成四类。语义与结构：header、nav、main、article、section。多媒体：video、audio、canvas、SVG。表单增强：新增 input type、自动校验、placeholder。API 能力：Web Storage、Geolocation、Web Worker、History API。
然后挑一两类深入讲，比如提到 Web Worker 时，可以展开说大文件上传场景里用 Web Worker 做文件分片计算和哈希计算，把耗时任务从主线程剥离，避免阻塞 UI。这样就能把 HTMl5 新特性和真实项目结合，面试官会清楚你不是背概念，而是真的用过。
有一点要留意：不要在面试中表现得太“崇新”。面试官问“H5 和原生 app 有什么区别”时，不要说“原生能做的 H5 都能做”，这个认知偏差很大。诚实回答各自的适用范围，反而更专业。
7.3 校招简历上关于 HTML 该怎么写
简历上写“熟悉 HTML5、CSS3”几乎是标配，但这个描述太虚了，所有候选人都会写。更好的写法是把 HTML 相关的实践具体化，比如：
- “基于语义化标签与 WAI-ARIA 规范重构官网页面，通过组件测试中的无障碍检测项”
- “项目中使用 preload、prefetch 优化首屏资源加载，LCP 提升约 20%”
- “基于原生表单校验结合自定义错误提示，实现注册页动效与可访问性优化”
这些描述里没有一句虚假，就是把做过的事用业务语言表达出来。面试官看到这样的描述，提问方向会围绕你的真实经历展开，而不是抛一些泛泛八股。
简历是面试的引子，你写了什么，面试官就往哪个方向问，所以尽量写那些你真正理解、能展开讲的内容。如果你写了自己做过无障碍优化，那就要真的理解 aria 是什么，如果写了自己做过性能优化，那就要能解释 LCP 和 preload 的关系。
8. 从面试官视角做一次复盘
面了这么多人，我最大的体会是：HTML 面试题目的目的不是筛掉“不会背标签”的人，而是筛掉“只会背标签”的人。
真正扎实的候选人，谈起 HTML 不会停顿太久，因为他的知识是从项目里长出来的。他知道页面为什么需要语义化，因为他重构过老项目；他知道 script 为什么放底部，因为他排查过白屏问题；他知道 label 的 for 为什么重要，因为他给用户做过自定义表单控件。这些知识不是背诵的结果，而是实践的自然沉淀。
如果你还在准备阶段，给自己提三个问题：我写出的每一个标签，能说清它为什么出现在这里吗？浏览器解析我的页面时，每一步都在做什么？我做的页面，键盘用户能不能完整操作完所有功能？能把这三个问题自洽地答清楚，HTML 这一关基本就稳了。
面试是个双向选择的过程。技术考察的深度，往往也反映团队对前端基本功的重视程度。HTML 看似简单，实则是整个前端知识体系里最贴近浏览器底层的地基，地基稳了，上面盖多少层楼都不慌。