[toc]
一、资源引入与脚本加载
1. src 与 href 的区别
在引用外部资源时,两者有着本质的语义和行为差异:
| 属性 | 含义 | 行为特征 | 典型应用 |
|---|---|---|---|
src | Source(资源嵌入) | 阻塞解析:会下载并嵌入资源,直到加载、编译、执行完成。 | <script>, <img>, <iframe> |
href | Hypertext Reference(超链接) | 非阻塞:与当前文档并行下载,不影响文档处理。 | <a>, <link> |
2. script 标签加载机制:defer vs async
不加属性,脚本会阻塞 HTML 解析
async:异步下载,下载完成后立即执行(会阻塞 HTML 解析)。适用于独立性强的脚本,如统计代码defer:异步下载,等待 HTML 解析完成后再执行。适用于需要 DOM 结构的脚本,且能保证执行顺序
| 属性 | 行为特征 | 执行顺序 | 最佳场景 |
|---|---|---|---|
| 无属性 | 立即下载并执行,阻塞解析 | 按 HTML 顺序 | 极其精简的基础脚本 |
async | 下载完立即执行,可能阻塞解析 | 不保证顺序(谁快谁先跑) | 广告、埋点统计、第三方组件 |
defer | 解析完 HTML 后执行 | 按源码顺序执行 | 依赖 DOM 的核心业务逻辑 |
二、 元数据控制:Meta 标签的应用
meta 标签是网页的“名片”,定义了 SEO、编码、视口等关键属性
基础配置:
<meta charset="UTF-8">(编码)SEO 优化:
keywords和description用于定义关键词与页面描述移动端适配:
viewport是响应式开发的关键html<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">索引控制:
robots控制搜索引擎是否检索页面及跟踪链接(如index,follow)。
三、语义化与 HTML5
HTML5 不仅仅是增加了几个标签,更是赋予了浏览器强大的应用能力
1. 结构与语义化
通过 header, nav, footer, article, section, aside 等标签,让网页结构清晰,利于 SEO 和无障碍阅读
2. 多媒体与表单增强
- 媒体标签:
audio和video提供了原生的多媒体支持。配合source标签,可以实现多格式兼容 - 表单控件:新增了
email,url,number,range,color,date等类型,极大地简化了前端验证逻辑 - 表单属性:
placeholder(提示),autofocus(自动聚焦),required(必填),pattern(正则校验)
3. Web 存储与 API
Web Storage:
localStorage(永久存储)与sessionStorage(会话级存储)特性 localStorage sessionStorage 生命周期 永久存储,除非手动清理 页面会话结束(关闭标签页)即销毁 存储容量 约 5MB - 10MB 约 5MB 作用域 同源的所有窗口共享 仅在当前窗口/标签页有效 图形绘制:
canvas(位图画布)与SVG(矢量图形)高级能力:
Geolocation(地理定位)、History API(无刷新跳转)
四、 元素分类
| 类型 | 特点 | 常见标签 |
|---|---|---|
| 块级元素 (Block) | 独占一行,可设宽高 | div, ul, li, p, h1-h6 |
| 行内元素 (Inline) | 不换行,宽高由内容撑开 | a, span, strong, input |
| 空元素 (Void) | 没有内容,无需闭合 | br, hr, img, meta, link |
块级元素可以通过
display: inline变为行内元素,行内元素也可以通过display: block变为块级元素
五、Canvas vs SVG
在需要动态生成图形时,这两者是完全不同的技术路径:
| 特性 | Canvas (画布) | SVG (矢量图) |
|---|---|---|
| 渲染模式 | 位图(依赖分辨率),由脚本驱动绘制 | 矢量图(不依赖分辨率),基于 XML 描述 |
| DOM 操作 | 不支持。图形一旦画好,浏览器就不再关注它 | 支持。每个图形元素都是一个 DOM 节点 |
| 性能表现 | 适合绘制大量对象、高频刷新(如游戏) | 适合静态图标、地图,对象数量多时性能下降 |
| 事件绑定 | 只能给整个 Canvas 绑定 | 可以给每个图形路径绑定事件 |
六、移动端适配方案
1. Viewport 视口缩放
通过设置 <meta> 标签,让移动端浏览器按照理想宽度渲染。
- 实现:
<meta name="viewport" content="width=device-width, initial-scale=1.0"> - 缺陷:它只能保证页面不缩放,但无法解决“大屏手机看更多内容”还是“大屏手机看更大内容”的逻辑。
- 解决:这通常作为所有适配方案的前置条件,必须配合其他方案使用
2. Rem 布局
通过监听窗口大小,动态修改 <html> 的 font-size,页面所有单位使用 rem
- 实现:使用
amfe-flexible库或手写window.onresize脚本,配合postcss-pxtorem插件自动转换 - 缺陷:
- 性能损耗:需要 JS 脚本监听并计算,可能导致页面闪烁(Flash of Unstyled Content)
- 精度问题:部分浏览器对小数像素处理不一,可能导致 1px 边框变粗或消失
- 不适用于富文本:系统字体大小改变时,
rem可能导致排版崩坏
- 解决:
- 针对 1px 问题:使用
transform: scale(0.5)配合伪元素实现 - 针对闪烁:将计算逻辑写在
<head>的最顶部,内联执行
- 针对 1px 问题:使用
3. Vw / Vh 布局
直接利用 CSS3 的视口单位(1vw = 视口宽度的 1%),不再依赖 JS
- 实现:配合
postcss-px-to-viewport插件,在开发时写px,编译后转为vw - 缺陷:
- 无法限制最大宽度:在平板或 PC 上打开时,UI 会被无限拉伸(变得巨大无比)
- Vh 陷阱:在带有工具栏的移动端浏览器(如 Safari)中,
100vh可能会被工具栏遮挡
- 解决:
- 限制最大/最小宽:配合
max-width和margin: 0 auto给页面容器设限 - 解决 Vh 遮挡:使用 CSS 新单位
svh(Small Viewport Height) 或lvh
- 限制最大/最小宽:配合
4. 响应式布局
根据不同的断点(Breakpoints)展示不同的样式。
- 实现:
@media (max-width: 768px) { ... } - 缺陷:工作量巨大。需要为不同屏幕写多套样式,维护成本极高,且在连续的屏幕尺寸变化中不够平滑
- 解决:仅用于跨端项目(如同时适配手机和 PC)。纯移动端项目建议配合 Flex 布局使用,只在关键节点微调