投资入门指南完整学习路线：从0到1建立美股与加密货币知识框架的实战计划
2026/9/27 0:23:52
面试前端，HTML 往往是第一道"隐形门槛"。很多候选人简历上写"精通 HTML"，结果面试官随口问一句"<!DOCTYPE html>是干什么的"，答案就开始打转。我做了多年前端开发和面试官，太清楚这类现象了：问题看起来简单，恰恰能筛掉一大批"只写过页面、没思考过原理"的人。这篇文章我整理了 5 道在面试中反复出现、最能体现 HTML 基础功底的题目，每道题都附上详细解析，把我自己当面试官时的评分视角、当开发时踩过的坑，一并写出来。目标很简单：让你看完之后，遇到这类基础题不再靠背，而是真正能讲清楚"为什么"。
1. 第一道题：DOCTYPE 声明，从一坨乱码排查说开去
面试开场最常见的问题就是："你平时写 HTML，第一行<!DOCTYPE html>为什么不写？它的作用是什么？"这题不复杂，但能看出你是真做过页面，还是只敲过模板。
1.1 标准模式与怪异模式：一个让整个页面布局崩掉的开关
DOCTYPE全称Document Type Declaration，也就是文档类型声明。它的核心作用只有一个：告诉浏览器用哪一种模式来渲染这个页面。浏览器的渲染模式主要分为两种：标准模式（Standards Mode）和怪异模式（Quirks Mode）。
怪异模式是浏览器为了兼容老网页特意保留的一种"向后兼容"模式。在早期浏览器大战时期，很多老页面依赖非标准的渲染规则，比如 IE 的盒模型、不严格的嵌套容错、默认字号等。如果页面没有 DOCTYPE，浏览器就会默认进入怪异模式，按照老一套规则渲染。
我自己在实际项目中遇到过一件很典型的事：接手一个维护多年的老项目，某个页面实际加载出来整体宽度溢出了一截，排查了半天，最后发现是模板里有一段被注释掉的代码把<!DOCTYPE html>挡住了，浏览器直接当成没有文档类型声明来处理，进入了怪异模式。怪异模式下，box-sizing的默认表现、百分比宽度的计算、行内元素的基线对齐都会变得"不讲道理"，这也是为什么很多老同事一遇到诡异布局问题，第一反应就是先看一眼页面头部有没有 DOCTYPE。
1.2 为什么 HTML5 的 DOCTYPE 这么简短
如果你看过 HTML4 时代的代码，会发现当时写的是这样一串长声明：
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">而 HTML5 只需要<!DOCTYPE html>。原因很简单：HTML5 里面不需要再通过 DTD 来定义文档结构了，浏览器只要看到doctype关键词，就知道你要用标准模式渲染。所以这一行文字既是给浏览器看的开关，也是给维护者看的"页面正常运行的保险丝"。
面试官问这道题，通常还会追问一句："如果我不写 DOCTYPE，浏览器会报错吗？"不会报错，页面照样能显示，但是会以怪异模式渲染，而这种模式下的表现细节和标准模式差异很大。把这个逻辑讲清楚，比背一个定义要有说服力得多。
1.3 趁热打铁：lang 属性和 charset 为什么要紧跟着写
HTML 文档的<html>标签上通常有lang="zh-CN"，<head>里则有<meta charset="utf-8">，这两样也常常被面试官连带问起。
lang="zh-CN"的作用是声明页面主要语言。它有三个实际价值：一是帮助搜索引擎判断页面语言区域，二是帮助屏幕阅读器用正确的发音规则朗读内容，第三是当浏览器内置翻译功能时，可以准确识别源语言。很多只写静态页面的开发者会忽略这个属性，但做 SEO 和无障碍时它是有分量的。
<meta charset="utf-8">则决定了浏览器以什么字符编码来解析文档。编码声明如果写得太靠后，或者写错成gb2312、gbk导致和实际文件编码不一致，就会出现中文乱码。规范里有一个细节：编码声明应该放在文档前 1024 字节内，因为浏览器要提前知道用哪种编码读取后续内容。所以实操上的标准姿势是把<meta charset="utf-8">放在<head>的最前面、越靠前越好。我自己习惯先写<!DOCTYPE html>，紧接着就是<html lang="zh-CN">，下一行就是 charset，然后是 title 和 viewport，这个顺序不会出错。
2. 第二道题：语义化标签，别再说"div 一把梭"
"谈谈对 HTML 语义化的理解"几乎每十场面试就要出现八场。很多面试者能背出"语义化就是使用语义恰当的标签"这句话，但真要让他分析一段页面结构，立刻露馅。
2.1 语义化到底解决了哪三个问题
语义化不是"用 header 代替 div"这种表面动作，它解决的是三个实际问题。
第一是 SEO。搜索引擎的爬虫不认识"哪块是导航、哪块是正文"，它依靠的是一套权重和结构分析算法。使用h1到h6表达标题层级、用article标记正文主体、用nav标记导航，比一大堆<div class="title">更容易被搜索引擎正确识别页面结构和内容重点。
第二是无障碍访问。屏幕阅读器会按语义标签来朗读页面。比如遇到nav时，辅助工具可以直接跳过导航区域让用户快速进入正文；遇到table时会用表格导航模式；遇到button时会识别出这是可交互控件。如果你全用div + onclick模拟按钮，在无障碍层面它就是一块没有角色的死区域。
第三是代码可维护性。语义化结构让代码变成一种"自描述文档"。新人接手项目时，看header、main、aside、footer这些标签，一下子就能理解页面骨架，而不需要逐个 class 去猜。
2.2 一张标准页面骨架应该怎么搭
我建议面试者心里要有一个标准的页面骨架模板，遇到语义化问题可以直接用它来举例：
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>页面标题</title> </head> <body> <header> <h1>网站标题或文章标题</h1> <nav>主导航</nav> </header> <main> <article> <h2>文章标题</h2> <p>正文内容</p> <time datetime="2025-01-01">2025年1月1日</time> </article> <aside>侧边栏相关内容</aside> </main> <footer>版权与联系方式</footer> </body> </html>这里有三个高频误区要特别注意。<section>不是随便用来包内容的，规范建议它应当包含一个标题；如果一段内容独立出来也能自成一体，应该用article而不是section；<aside>也不只是"右侧栏"，它表示与主内容只有间接关系的内容，比如引述、广告、相关推荐，放在左边也一样可以用 aside。
2.3 面试官爱挖的坑：h1 到底能出现几个
语义化的追问环节，我经常出这几道小坑题：
页面上h1能出现多个吗？严格意义上 HTML 规范没有禁止多个h1，但从 SEO 最佳实践和文档结构清晰度来看，一个页面建议只保留一个h1，用来表达整张页面的核心主题。多h1会让搜索引擎难以判断主标题。
strong和b、em和i有什么区别？strong表示内容重要性强，em表示语气强调，它们是有语义的；b和i原本是纯视觉样式标签，在 HTML5 里的语义也弱化成了"样式偏移"作用。开发时更推荐使用strong和em。
还有一个实用细节：h1字号能通过 CSS 改吗？当然可以。语义化不等于不允许设置样式，h1的默认样式只是一个浏览器默认值，你用 CSS 把h1字号改成16px完全没问题，语义不会因此改变。很多面试者误以为语义化标签不能修改外观，这是个典型的理解偏差。
3. 第三道题：meta 标签里藏着的移动端适配细节
第三道高频题往往藏在<head>里："你解释一下viewport这个 meta 是干什么的？"如果候选人连viewport都不清楚，移动端适配这一块基本就是要扣分项。
3.1 charset 和乱码：一张办公文档引发的惨案
讲 meta 先从charset说起。我遇到过最典型的乱码场景是这样的：产品从办公室同事那里拿到一份 HTML 模板，同事在 Windows 上用记事本另存为时默认编码是gbk，但模板的<meta charset="utf-8">又写的是 UTF-8，浏览器按 UTF-8 去解析 GBK 编码的文件，于是中文全部变成"�口口"。
排查乱码问题的标准顺序是这样的：先确认文件本身是什么编码，再确认<meta charset>声明是否一致，最后确认服务器返回的响应头里Content-Type是否有冲突。三者只要有两个不一致，就可能乱码。这个经验写成面试答案也很管用：说到charset时带上实际排查案例，分数明显不一样。
3.2 viewport：为什么手机页面不写它就会"缩成一团"
viewport是移动端页面适配的关键设置，标准写法是：
<meta name="viewport" content="width=device-width, initial-scale=1.0">先解释一个基本概念：手机浏览器的默认布局视口宽度大约是 980px（不同浏览器略有差异）。如果不写 viewport，页面在手机上就会按 980px 的宽度渲染，然后被整体缩小塞进屏幕，于是出现文字小得看不清、用户双击才能放大的体验。加入width=device-width之后，布局视口宽度被设置成设备的屏幕宽度，页面就能按设计稿的正常比例展示。
这里面有三个参数经常被追问：
width控制布局视口宽度，一般是device-width，也可以写具体数值。initial-scale是初始缩放比例，1.0表示不缩放。user-scalable用于控制用户能否手动缩放，但为了无障碍体验，主流做法已经不建议禁用缩放，iOS 上maximum-scale也经常被忽略不计。
面试官如果继续深挖，会问"布局视口、视觉视口和理想视口有什么区别"。布局视口是 CSS 布局时用的视口，视觉视口是用户当前在屏幕里看到的那一区域，理想视口则是设备屏幕宽度这个理想值。width=device-width就是把布局视口设置为理想视口。能把这个链条讲出来，这个答案就是满分。
3.3 附加题：页面分享卡片和 SEO 相关 meta
meta 相关的加分项还有很多。比如description是页面的搜索摘要描述，写得准确能提高搜索结果的点击率；keywords在现在的搜索引擎权重算法里已经几乎没有什么作用了，不写也没有影响。
做社交分享时还要用 Open Graph 协议，比如：
<meta property="og:title" content="页面的分享标题"> <meta property="og:image" content="https://example.com/cover.jpg"> <meta property="og:description" content="分享摘要">这些标签在微信、FB、Twitter 等平台分享页面时会被读取，用来生成卡片。很多面试者不知道这一层，如果你能顺口说出来，面试官会觉得你不只是写内部页面，还做过对外传播场景。
老项目里还有一种写法也值得知道：<meta http-equiv="X-UA-Compatible" content="IE=edge">，作用是让老版本 IE 用最高版本的文档模式渲染。虽然 IE 已经退出历史舞台，但维护过老系统的前端还是很有必要知道这个历史遗留知识点。
4. 第四道题：块级元素与行内元素，基础题里的陷阱
"div和span有什么区别？"这种题小学生都会答，但面试官换个问法就变成陷阱："img是块级元素还是行内元素？"答案不是简单一句"行内"能带过的。
4.1 用"盒子"来理解两类元素的本质差异
块级元素和行内元素的核心差别，按"盒子模型"来理解最清晰。
块级元素（如div、p、h1、ul、li）默认独占一行，可以设置width、height，上下margin、上下padding都能生效，多个块级元素会纵向排列。行内元素（如span、a、em、strong）默认不会独占一行，多个行内元素在一行里排到放不下才换行；它不能设置宽高，设置上下margin和上下padding也不会把周围元素推开，只有左右方向的margin、padding生效。
用生活场景类比：块级元素像一箱一箱整齐叠放的货物，每个箱子都要占用一整层货架；行内元素则像一条流水线上的零件，沿着同一个平面往前排，只能左右挪动、不能单独占一层。理解了这个"盒子占有规则"，布局上很多怪问题都能解释清楚。
4.2 特殊角色：替换元素为什么能设宽高
接下来是重点陷阱。img、input、button、textarea这类元素，默认display值其实还是inline，但你可以给它们设置宽度和高度，而且上下margin、padding也生效。这是因为它们属于"替换元素"（replaced elements），内容由外部资源或浏览器控件替换，元素本身在渲染时拥有内在尺寸，所以宽高规则和普通行内元素不同。
面试里如果问到"img是行内还是块级"，我的建议是分层回答：默认display是inline，但替换元素可以设置宽高；更准确地描述是它们呈现出"inline-block"的很多特征。这种回答既照顾了默认值，又体现了对替换元素的理解，不会被人钻空子。
4.3 高频追问：inline-block 之间的缝隙哪来的
块级、行内讲完，面试官很自然的下一问是"inline-block是什么？有什么坑？"
inline-block兼有两者的特点：元素不会独占一行，同时可以设置宽高和上下margin、padding。但它有一个著名的"幽灵空白节点"问题：源代码里两个inline-block元素如果之间有换行符或空格，页面上就会出现几个像素的间隙。
<div class="box"></div> <div class="box"></div>当这两个.box都是inline-block时，中间的换行会被渲染成一个空白字符，于是两张盒子之间就多了些空隙。解决办法有三种：父容器设置font-size: 0，再给子元素恢复字号；或者把两个元素直接写成一行中间不加换行；或者用负margin抵消。
我自己的建议是，现在做布局优先用flex或grid，它们从设计上绕过了行内元素的空白问题，而且对齐能力更强。但面试题还是会问inline-block，因为有大量老代码和某些场景（比如横向菜单、简单图标排版）仍然依赖它。能讲清楚这个坑，说明你写过真实页面而不是只看过文档。
5. 第五道题：HTML5 新特性，怎么答才有区分度
"说说 HTML5 有哪些新特性"是一道百科全书式问题，面试者最容易答得又乱又浅。有人上来就背"canvas、video、localStorage"，背完结束了，面试官什么也没听出来。这道题的答题思路应该是有结构、有主次、有实战。
5.1 先搭框架：新特性可以这样分类
我把 HTML5 新特性按用途分成四类，面试答题用这套框架特别稳。
第一类是语义化标签与页面结构，比如header、nav、main、section、article、aside、footer、figure、figcaption等。第二类是表单增强，包括新输入类型email、url、number、date、color、range等，还有required、placeholder、pattern、autofocus、datalist这种表单控件属性。第三类是多媒体与绘图，也就是audio、video、canvas、svg内联使用。第四类是 Web 应用 API，最常见的是localStorage、sessionStorage、Web Worker、history API、地理定位、拖拽 API等。
这样说一遍，面试官会觉得你有体系。接下来要做的，是挑其中最容易被追问的两个点深入展开。
5.2 面试官必问的区分题：Canvas 与 SVG 有什么不同
如果候选人提到了canvas，我几乎一定会追问一句："Canvas 和 SVG 有什么区别？"
答案可以用一张表说清楚：
| 对比维度 | Canvas | SVG |
|---|---|---|
| 图形类型 | 位图（像素） | 矢量（几何图形） |
| 绘制方式 | 通过 JavaScript API 逐笔绘制 | 通过 XML 标签描述图形 |
| DOM 节点 | 只有一个画布元素，内部无节点 | 每个图形都是独立 DOM 节点 |
| 事件绑定 | 需要自行计算坐标命中检测 | 每个图形节点可以直接绑定事件 |
| 缩放表现 | 放大后会模糊 | 任意缩放不失真 |
| 适用场景 | 游戏、实时图表、大量动态绘制 | 图标、地图、简单交互图形 |
补充一个实战经验：如果一个场景要渲染上万个节点并且频繁更新，Canvas 性能更好；如果只是几个图标、简单的可交互图形，SVG 更合适。用项目体验来支撑这个回答，往往能让面试官眼睛一亮。
5.3 localStorage、sessionStorage 与 Cookie：一道高频对比题
HTML5 存储相关的问题也属于"必考题型"。核心是要能说清楚三者的差别：
| 对比项 | Cookie | localStorage | sessionStorage |
|---|---|---|---|
| 容量 | 约 4KB | 约 5MB 或更大 | 约 5MB 或更大 |
| 请求携带 | 每次 HTTP 请求自动携带 | 不会自动携带 | 不会自动携带 |
| 生命周期 | 按 Expires/Max-Age 控制 | 持久保存，手动清除才消失 | 会话结束即被清除 |
| 作用域 | 域名内 | 同源共享 | 仅当前标签页会话 |
| 存储类型 | 字符串 | 字符串 | 字符串 |
这里有个经常被忽略的细节：存储 API 只能保存字符串，如果你要存一个对象，必须JSON.stringify之后再存，读取时再JSON.parse回来。很多新人直接localStorage.setItem('user', userObject)，控制台不报错，但取出来就变成"[object Object]"，这就是原型坑。
还有一个有意思的知识点：sessionStorage即使在新开标签页时复制了地址也不会共享，只在当前标签页生命周期内有效，刷新页面数据还在，但关闭标签页就没了。这个特性在实现"页面临时草稿"功能时会非常有用。
5.4 容易被继续追问的实战细节：视频自动播放和 datalist
video标签也算高频。经典坑是自动播放策略。现代浏览器普遍限制了带声音的视频自动播放，你设置autoplay属性不一定生效。实际方案是给video加muted属性，静音视频通常可以自动播放，用户点击后再打开声音。移动端 WebView 还要注意加playsinline、x5-playsinline之类的属性，否则视频在 iOS 上容易默认进入全屏播放。
datalist是一个好用但存在感不高的新特性，它能给输入框提供下拉建议值：
<input list="browsers" name="browser"> <datalist id="browsers"> <option value="Chrome"> <option value="Firefox"> <option value="Edge"> </datalist>用户既可以从建议里选，也可以自由输入，不需要引入任何 JavaScript。提到这个，很容易比那些只背大路货特性的面试者更让人觉得技术面广。
6. 把答案组织成面试官想听到的样子
说完了五道题，最后再聊几句面试技巧。同样一道题，组织方式不同，效果差很多。
6.1 答案结构：结论加原理加场景
我建议大家按"结论、原理、场景"三段式答题。比如被问到 DOCTYPE，先说结论"DOCTYPE 是用于触发标准模式的文档类型声明"；再解释原理"没有它浏览器会进入怪异模式，导致盒模型、排版不一致"；最后补一个场景"我之前遇到过某老页面没有 DOCTYPE，布局宽度溢出，加上后恢复正常"。
这种结构不但信息完整，还给面试官留出了追问空间。无论他追问哪个方面，你都还有内容可讲。
6.2 防止翻车的三个细节
第一，不要背"标准答案"背得太流利。面试官能听出来机械记忆和真实理解的区别。如果某个点你确实只知其然不知其所以然，宁可停下来想想再说，也别张口就来。
第二，不知道的 API 要诚实承认，但可以补一句自己的排查思路。比如问到陌生的标签，可以说"这个我实际项目里没用过，不过按规范推断它的作用应该是这样，我会去 MDN 确认一下"。坦诚加合理推断，比硬编一个答案可信得多。
第三，随手写一点 HTML 再上考场。面试前打开编辑器把标准骨架写一遍，把 meta、语义化标签、表单控件、多媒体标签都跑一遍，比翻一百篇面经都顶用。我见过很多候选人嘴上概念背得清，让他现场写一个完整的表单结构，却连action、method都交代不清楚，这种反差非常减分。
我也把话说回来：HTML 基础题难吗？真的不难。但它是一面很好的"照妖镜"，能照出你是真正写过大量页面、处理过乱码和移动端适配的人，还是只在文档里见过这些标签的人。把这五道题吃透，至少在 HTML 这一关，你能给面试官留下一个"基础扎实、思路清晰"的印象。