企业官网建设流程全解析

第八节课之前，我们做出来的网页基本属于“能看但不会动”的类型。标签、列表、样式表都堆上了，但一遇到要跟用户互动、要存数据、要定位、要拖拽，就只能干瞪眼。市面上那些看起来特别灵活的前端效果，背后大多不是纯CSS技巧，而是浏览器原生提供的API。这节课要聊的HTML5新增API，就是把这些交互能力一个一个掰开揉碎讲清楚。适合刚学完HTML和CSS、想做交互页面的同学，也适合对API犯迷糊、只想看明白怎么调用的人。放心，难度会控制在入门到进阶的过渡带，代码不多，但原理和坑都要说透。

1. 内容整体设计：HTML5 API到底给我们带来了什么

1.1 API是什么？把浏览器的“内功”借出来用

先解决一个最基本的问题：API到底是个啥。我在课上经常拿“在饭店点菜”打比方。你不需要知道后厨怎么洗菜、怎么炒、用什么锅，只需要对着服务员说“宫保鸡丁”，服务员就把结果端上来。前端里说的API，就是浏览器这家“大饭店”的服务员。你想定位，调用navigator.geolocation；你想存数据，调用localStorage.setItem；你想画图，拿canvas.getContext('2d')。你不需要自己实现定位芯片、不需要自己封装数据库、不需要自己写底层绘图库，浏览器已经把这些能力封装好，开放给你用。

HTML5新增API的意义，就是把这些过去必须依赖插件（比如Flash）或者第三方库才能做的东西，变成了浏览器内置的标准能力。所以你会发现，越到后面，做交互越“省力”。与其到处找库，不如先把浏览器送上门的能力用明白。这就是为什么这节课的标题叫“新增API与网页交互基础”——API是工具，交互是目的，两者是一件事。

1.2 这节会覆盖哪些API

HTML5 API数量非常多，一节课不可能全部讲完。我按“日常网页开发最常用”的标准，挑了几个代表性模块：本地存储（localStorage/sessionStorage）、地理位置（Geolocation）、拖放（Drag and Drop）、绘图（Canvas）、网络请求（Fetch），再加几个轻量但容易出效果的媒体和页面管理API。它们几乎覆盖了网页交互最常见的五个场景：记住状态、获取位置、拖动元素、绘制图形、和后端沟通。

我习惯用一个表格把它们的用途说清楚，方便你后面按图索骥：

后面每一节都会围绕一个API展开，既有最基础的概念，也有可以直接抄走的代码。这样学下来，你至少能把一个静态页面改造成一个“能跟用户聊天”的动态网页。

2. 本地存储API：localStorage与sessionStorage

2.1 localStorage和sessionStorage的区别

很多初学者一看到“本地存储”就想到了cookie，但HTML5的Web Storage完全是另一套思路。cookie的特点是每次请求都会自动带到服务器，而且大小限制在4KB左右，又慢又局促。localStorage和sessionStorage则把数据直接存在浏览器里，默认不会跟着请求到处跑，单键容量一般能到5MB左右，读取是同步的，代码非常直观。

两者的区别主要在一个“生命周期”上。localStorage只要你不手动删，它就一直在，关掉浏览器再打开数据还在；sessionStorage是“会话级”的，标签页关了，数据就没了。你可以这样理解：localStorage是抽屉，东西放进去，明天还在；sessionStorage是草稿纸，临时用用，起身走人就被收走。所以记住密码、主题偏好这类持久信息用localStorage，登录状态这类临时通行凭证通常用sessionStorage。我在做管理系统的时候，经常把用户的可配置项放localStorage，把单页内的临时筛选条件放sessionStorage，各管各的。

2.2 实战：表单自动保存与主题切换

先说一个最简单的表单自动保存需求：用户填到一半不小心关了页面，重新打开希望内容还在。其实就两行核心逻辑。

const textInput = document.getElementById('content'); // 只要用户输入，就存起来 textInput.addEventListener('input', function () { localStorage.setItem('draft', textInput.value); }); // 页面加载时恢复 window.addEventListener('load', function () { const saved = localStorage.getItem('draft'); if (saved !== null) { textInput.value = saved; } });

这个代码直接放在第八节课的练习里运行就能看到效果。输入几个字，刷新页面，内容还在。如果你希望自动保存不要频繁触发，可以加一个简单的防抖函数，等用户停顿几百毫秒再写。另一个特别实用的场景是主题切换：用户点了“深色模式”，你把theme = dark存到localStorage里，下次进页面直接用JS给根节点加class。这样用户的偏好就不会因为刷新而丢失，体验上很像一个真正的应用。

2.3 踩过的坑：JSON解析、隐私数据、隐私模式

localStorage最容易被坑的地方是“只能存字符串”。数组和对象直接存进去，读出来会变成[object Object]。正确做法是先JSON.stringify()再存，读取时用JSON.parse()还原。但是JSON.parse()有个烦人的地方：如果以前存的数据损坏了，或者键被其他页面写入了非法内容，解析会直接抛异常，导致整个脚本中断。我在项目里遇到的经典场景是，用户清了缓存，剩下半个JSON，读取时直接白屏。所以不管读什么，建议都包一层try catch，读不到就默认值兜底。

第二条规则是关于隐私的。localStorage就是浏览器本地的一个文本文件，任何能打开你电脑的人都能看见。密码、身份证号、银行卡这些敏感数据千万别往里面放。还有隐私模式的问题：像Safari的隐私模式，localStorage可能不可用，或者写入时会抛QuotaExceededError。别让页面因此挂掉，最稳妥的写法是：

let storageAvailable = true; try { localStorage.setItem('__test', '1'); localStorage.removeItem('__test'); } catch (e) { storageAvailable = false; }

先探测，再决定要不要用本地存储，这条习惯能帮你救回不少用户。

3. Geolocation API：浏览器如何“知道”你在哪

3.1 定位原理与权限机制

Geolocation是HTML5里“看起来很高端、其实特别依赖环境”的API。浏览器会综合判断设备的位置来源：手机优先用GPS和基站定位，电脑可能用Wi-Fi信号和IP地址反推。这些细节你不用深究，但一定要明白：浏览器需要向用户弹窗申请权限，用户点了允许之后，才会把经纬度交给你。

所以权限模型是这门API的第一道门槛。现在的主流浏览器要求页面必须在HTTPS环境下才能调用Geolocation，因为位置信息属于高度敏感的个人数据。本地开发的时候有个例外：localhost被视为安全环境，所以在自己电脑上跑不需要配HTTPS也能调试。我遇到过不少同学把项目放到一台纯内网IP的测试服务器上，结果定位完全没反应，多半就是协议问题。另外，如果用户点了“不允许”，浏览器会记住这个决定，你只能在控制台里把该站点的权限重置才能再次触发弹窗。

3.2 getCurrentPosition和watchPosition实操

定位API主要给你两个方法。一个是单次定位getCurrentPosition，一个是持续监听watchPosition。先看单次定位的标准写法：

navigator.geolocation.getCurrentPosition( function (position) { const lat = position.coords.latitude; const lon = position.coords.longitude; console.log('我在：', lat, lon); }, function (error) { console.log('定位失败：', error.message); }, { enableHighAccuracy: true, timeout: 5000, maximumAge: 60000 } );

第三个参数是配置项。enableHighAccuracy: true表示允许设备使用GPS等高精度方式，更准但更耗电；timeout是最长等待毫秒数，超过就触发错误回调；maximumAge表示可以接受多久之前的缓存位置，单位毫秒，如果传入60000，说明一分钟内的旧坐标可以直接用，不用重新定位。做外卖点餐、签到打卡这类功能，这几个参数非常关键。

watchPosition的用法更接近“GPS导航”：每隔一段时间自动上报新的位置。它的参数和单次定位一致，但返回一个watcher ID，不需要的时候一定要navigator.geolocation.clearWatch(watcherId)关掉，否则后台会一直跑，电量和流量都会白费。比如做配送员轨迹回放，就适合用watchPosition持续收集坐标点。

3.3 定位调试经验：HTTPS、模拟器和超时

开发定位功能，最大的敌人是“环境不对”。我自己踩过的坑可以列出来给你参考：

第一，代码在真机手机上测试时，一定要开HTTPS，否则整个接口都不可用。线上环境几分钟就能配好证书，本地测试用localhost就行。

第二，Chrome开发者工具里自带“传感器”面板，可以手动模拟经纬度，不需要你真跑到户外去测。具体位置在DevTools的Esc键弹出抽屉里，找“Sensors”或者按Ctrl+Shift+P搜“sensors”。模拟坐标填进去，页面的定位回调就会立即触发。

第三，定位超时大概率不是代码问题，而是环境无法获取卫星信号。在室内测试，很多设备会一直拿不到GPS，加上timeout设置太短，就频繁报错。我一般会先在回调里打日志，确认是哪类错误：用户拒绝（code 1）、无法获取位置（code 2）、超时（code 3），不同错误码给不同提示文案。比如超时可以提示“定位信号弱，请到开阔地带重试”，比一句干巴巴的“定位失败”友好得多。

拿到坐标后，最常见的是对接地图API，把经纬度显示成地图上的点。这里提醒一句：定位API返回的坐标默认是WGS84坐标系，而国内地图厂商通常使用GCJ-02火星坐标系，直接画会导致偏移几十一百米。对接高德或百度地图时，记得看他们的坐标转换工具，这是地图像交互里一定会遇到的细节。

4. 拖放API：把“拖着走”这个直觉搬到网页上

4.1 拖拽事件流与默认行为

拖放（Drag and Drop）是最符合人类直觉的交互方式之一。HTML5提供了原生拖拽事件，不需要任何第三方库，就能让元素在页面里“被拖起来”。

这里要记住一整串事件名：被拖拽元素上有dragstart、dragend，目标元素上有dragenter、dragover、dragleave、drop。它们和鼠标事件不一样的地方在于：你必须在dragstart里调用e.dataTransfer.setData('text/plain', 数据)，否则后续的drop事件压根不会触发。很多新手写了完整代码，却发现拖过去没反应，八成就是少了setData这一步。

还有两个默认行为必须手动阻止。一是dragover：浏览器默认不允许元素被拖放到别的元素上，所以你在dragover里必须e.preventDefault()。二是drop：拖放结束时浏览器默认会尝试打开被拖拽的数据，比如你拖一张图片到页面，不阻止的话它会像访问链接一样直接打开图片，所以drop里也要e.preventDefault()。这两步不做，代码写了等于白写。

4.2 做一个简易待办列表演示

课堂演示里我常用“待办事项拖拽排序”来练手，因为逻辑清晰，代码量适中。核心思路分三块。

HTML结构大概是：

<div class="task-list"> <div class="task" draggable="true">写课程笔记</div> <div class="task" draggable="true">整理代码</div> <div class="task" draggable="true">复习API</div> </div>

注意给要拖拽的元素加draggable="true"，否则它默认不是可拖拽的。

JavaScript部分，核心是记录当前拖拽的数据源，在drop时重新排列DOM：

let draggingItem = null; document.querySelectorAll('.task').forEach(item => { item.addEventListener('dragstart', function (e) { draggingItem = this; e.dataTransfer.setData('text/plain', this.id); this.classList.add('dragging'); }); item.addEventListener('dragend', function () { draggingItem = null; this.classList.remove('dragging'); }); item.addEventListener('dragover', function (e) { e.preventDefault(); }); item.addEventListener('drop', function (e) { e.preventDefault(); if (draggingItem && draggingItem !== this) { const children = Array.from(parent.children); const fromIndex = children.indexOf(draggingItem); const toIndex = children.indexOf(this); parent.insertBefore(draggingItem, fromIndex < toIndex ? this.nextSibling : this); } }); });

核心逻辑就是先用dataTransfer.setData记录被拖拽的元素，然后在drop时把这个元素插到目标元素的前面或后面。DOM的insertBefore方法配合索引判断，即可实现“插到前面”和“插到后面”两种效果。我给学生的建议是：不用死记代码，先理解那几个事件各自负责什么，然后照着自己的需求改。

4.3 拖放API的兼容性问题与替代方案

原生拖放API最大的坑，是移动端浏览器基本不支持。在手机上，HTML5 Drag and Drop事件基本不会触发，反而会触发滚动或长按菜单。所以如果你要做的功能需要手机和电脑都能用，我会更推荐用Pointer Events自己实现拖拽逻辑，或者直接使用成熟的库处理。移动端上，触屏的touchmove和touchend配合touch-actionCSS属性，可以做到类似效果，但实现复杂度会明显上升。

另外，dataTransfer对象内部的数据在不同的拖拽事件中可以读取，但你只能传入字符串，传对象需要先JSON.stringify。而且某些浏览器会限制跨窗口拖拽时读取数据，比如从浏览器外拖文件进来时，e.dataTransfer.files可以拿到文件列表，这个在“拖拽上传”功能里特别好用。做拖拽上传时，你只要在drop里遍历e.dataTransfer.files，然后丢给后面的Fetch上传就行，交互体验比点击上传按钮自然得多。

5. Canvas API：用代码画出一个世界

5.1 画布、画笔与坐标系的“心智模型”

Canvas可能是我见过学生最兴奋的HTML5 API，因为它真的可以“画画”。你可以把它想象成一个真实世界的画布：HTML里的<canvas>标签定义了画布区域，JS通过getContext('2d')拿到画笔，然后所有绘图操作都是“拿着画笔在画布上按坐标下笔”。

坐标系是Canvas第一个必须理解的概念。左上角是原点(0, 0)，往右是X轴正方向，往下是Y轴正方向。这和数学课的坐标系习惯不太一样，拿Flash画过图的人更有亲切感。所有绘制指令，比如fillRect(x, y, width, height)、arc(cx, cy, radius, angle)，都依赖这个坐标体系。

一个最基础的红色矩形只要三行代码：

const canvas = document.getElementById('demoCanvas'); const ctx = canvas.getContext('2d'); ctx.fillStyle = 'red'; ctx.fillRect(20, 20, 150, 80);

fillStyle相当于选颜色，fillRect相当于用当前颜色画一个方块。后面接触的路径、渐变、贝塞尔曲线，都是在这个“选色-下笔-填充”的框架里变化出来的。

5.2 实战：涂鸦画板的核心逻辑

涂鸦画板是最好复现的Canvas案例，它同时用到了鼠标事件和Canvas绘制指令。核心思路是：按下鼠标时开始绘制，移动鼠标时划线，松开鼠标时结束绘制。

const canvas = document.getElementById('board'); const ctx = canvas.getContext('2d'); let drawing = false; canvas.addEventListener('mousedown', function (e) { drawing = true; ctx.beginPath(); ctx.moveTo(e.offsetX, e.offsetY); }); canvas.addEventListener('mousemove', function (e) { if (!drawing) return; ctx.lineTo(e.offsetX, e.offsetY); ctx.stroke(); }); canvas.addEventListener('mouseup', function () { drawing = false; });

这里有几个细节。一是offsetX和offsetY是鼠标相对canvas的坐标，不是clientX/clientY，后者是浏览器窗口坐标，直接画会导致笔迹错位。二是每次松开鼠标后，下一笔要重新beginPath()，否则线会连到一起，没法形成独立笔迹。三是画笔样式可以通过lineWidth、strokeStyle、lineCap等属性调整，把lineCap设置成round，画出来的线条头尾就是圆的，不会出现刺眼的直角。

这个画板后续还能扩展，比如加橡皮擦、换颜色、清屏、把canvas内容导成图片。导出图片用canvas.toDataURL('image/png')，可以生成一个base64的图片地址，a标签直接下载或者回传给服务器都行，这也是很多在线签名、在线批注功能的核心原理。

5.3 高清屏适配与性能优化经验

Canvas最容易被骂“画出来糊”的，是高分屏适配问题。原因不复杂：CSS把canvas的显示尺寸设成了某个宽度，但canvas内部默认像素宽度是另一个值。比如你去CSS里写width: 300px，但canvas的width属性没设置，内部的绘图分辨率就是默认的300像素，在Retina屏幕上显示时被拉伸到物理像素，自然就糊了。

我的处理办法是，用设备像素比（window.devicePixelRatio）把canvas内部尺寸放大，再通过CSS把显示尺寸压缩回来。

const dpr = window.devicePixelRatio || 1; const rect = canvas.getBoundingClientRect(); canvas.width = rect.width * dpr; canvas.height = rect.height * dpr; canvas.style.width = rect.width + 'px'; canvas.style.height = rect.height + 'px'; ctx.scale(dpr, dpr);

这段代码的意思是：实际绘制像素翻倍，但展示时还是原来的CSS尺寸，等于用高分辨率画面去填低分辨率框，视觉上就清晰了。性能方面，如果做动画，千万不要用setInterval去画循环，用requestAnimationFrame。它会在浏览器即将重绘时统一执行回调，比定时器节省性能，动画也更流畅。还有一个小技巧，静态背景如果不需要变化，可以先画到一个离屏canvas里，主循环只需要重绘动态部分，性能能差好几十倍。

6. Fetch API：网页与服务器的“对话”基础

6.1 从XMLHttpRequest到Fetch：异步交互的进化

网页交互的另一大块，是异步请求。过去大家用XMLHttpRequest（XHR），代码要多写好几层回调，稍不注意就进入“回调地狱”。HTML5时代的fetch()基于Promise，代码结构清晰得多，现在的浏览器也全部支持。前端从服务器要数据、提交表单、上传文件，都绕不开它。

一个最简单的GET请求长这样：

const response = await fetch('https://api.example.com/articles'); const data = await response.json(); console.log(data);

需要说明的是，fetch()返回的response对象里，.json()也是个异步方法，所以要再await一次。如果你单纯想看有没有请求成功，可以看response.ok，它是status在200到299之间的布尔值。注意，fetch()只在完全请求失败（比如网络断开）时才reject，返回一个HTTP 404页面并不会走catch，很多人第一次写这个都会懵。

6.2 GET、POST、JSON与文件上传

POST接口稍微复杂一点，要在第二个参数里告诉fetch方法、请求头和请求体：

const response = await fetch('/api/save', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ title: '第八课笔记', content: 'HTML5 API 教程' }) }); const result = await response.json();

body必须是字符串，直接传对象会报错，所以要先用JSON.stringify转一下。这是新手报错率最高的点之一。如果后端接收的是表单格式，比如application/x-www-form-urlencoded，可以用URLSearchParams直接生成查询字符串，或者用FormData。

文件上传是移动端和后台系统里非常常见的功能。用FormData天然支持二进制内容，上传多文件、附带普通字段都方便。

const fileInput = document.getElementById('fileInput'); const fd = new FormData(); fd.append('file', fileInput.files[0]); fd.append('userid', '12345'); const response = await fetch('/api/upload', { method: 'POST', body: fd });

这段代码里不需要自己设置Content-Type，浏览器会自动加上multipart/form-data; boundary=...。如果手动加了反而会出错，这是我在课上反复强调的：FormData请求不要手动指定Header类型。

6.3 错误处理与跨域问题的实际应对

Fetch的错误处理，我给出的实战模板是：

let res; try { res = await fetch(url); } catch (e) { showToast('网络请求失败，请检查网络'); return; } if (!res.ok) { const errText = await res.text(); console.error('HTTP错误', res.status, errText); showToast('服务器返回错误'); return; } const data = await res.json();

先把网络层异常用try catch兜住，再把HTTP状态码问题单独处理。两个层次分开，排查问题会轻松很多。

跨域问题（CORS）是前后端分离开发避不开的坎。浏览器为了安全，禁止一个域名下的脚本读取另一个域名的接口，除非后端在响应头里允许。开发环境下最常见的解决方法是“代理”：前端开发服务器把/api开头的请求转发到真正的后端地址，浏览器看着是同域的，就不存在跨域。Vite、Webpack的devServer都支持配置proxy，改几行配置就能解决。至于线上环境，正确的做法是让后端配置CORS白名单，而不是用任何浏览器插件绕过，这才是干净且规范的处理方式。

7. 更多HTML5 API串联：视频倍速、表单验证与历史管理

7.1 video.playbackRate：几行代码搞个倍速播放

很多在线课堂都需要倍速播放功能，这个功能用HTML5的媒体API实现起来简单到不可思议。<video>元素原生支持playbackRate属性，指定播放速率，0.5是一半速度，2是二倍速。你只要在页面里加几个按钮，绑定这个属性就完事了。

document.getElementById('rate2').addEventListener('click', function () { const video = document.getElementById('myVideo'); video.playbackRate = 2; }); document.getElementById('rateNormal').addEventListener('click', function () { document.getElementById('myVideo').playbackRate = 1; });

媒体API还提供了volume、currentTime、requestPictureInPicture()等方法，可以很容易做出自定义播放器。以前要这种能力都得找Flash或引入大型播放器库，现在原生就给了。这也是HTML5 API最典型的魅力：很多看起来很高级的功能，其实只是调用一个属性的事。

7.2 表单校验API与History API的实用场景

HTML5新增的表单验证API也值得单独提一笔。比如required、minlength、pattern这些属性，直接在HTML上声明规则，浏览器就会根据规则自动拦截非法提交。但默认的弹层提示样式又丑又难统一，这时候可以用JS调setCustomValidity自定义错误文案，或者监听invalid事件自己渲染提示。做复杂表单系统时，我会把“原生校验”和“自定义UI”配合，既保留浏览器强大的规则引擎，又能控制视觉细节。

History API则解决“单页应用页面不刷新也能改变地址”的问题。history.pushState可以往地址栏里塞一条历史记录，popstate事件监听浏览器前进后退。现在很多前端框架的“路由”本质都是这个API。作为入门课我不展开太多，但你需要知道：HTML5不只是标签和表单，它还把单页应用的地基都铺好了。

8. 常见问题速查：开发中的高频报错与解决思路

8.1 问题排查实录

日常写代码时，我收集了几类高频问题，先给你一张速查表：

这些坑都不是代码逻辑多复杂，而是对API行为习惯不熟悉。把表存下来，遇到问题先对号入座，能省下大量无头绪调试的时间。

8.2 浏览器兼容性处理

HTML5 API的兼容性整体已经很好，像localStorage、Fetch、Canvas在主流现代浏览器上都能直接用，不用额外处理。真正需要留意的是老版本的IE，它连fetch、Canvas、Drag and Drop的支持都不完整。如果你的项目必须兼容IE11，要么加入对应的polyfill，要么接受部分功能降级。我的建议很简单：先明确你们的用户画像，如果后台管理系统的用户还用着老旧浏览器，就在关键路径上做一个“浏览器不支持的能力检测”，给出友好提示；如果用户都升级到了现代浏览器，就没必要为了极少数人牺牲开发效率。

前端这个领域，“遇到问题会查”比“背下所有API”更重要。浏览器的MDN文档是最权威的参考，我在课上一直强调：不要追着零散的博客问答看二手信息，遇到不确定的属性，先去MDN查一眼规范，再回自己代码里验证，效率比想象中高得多。

最后再分享一个我平时调试API的小习惯：直接在浏览器控制台里用fetch请求后端接口，查看返回结果。这样能快速区分“后端返回问题”和“前端代码问题”。每次上课我都会让学员先打开F12，把一个fetch贴进控制台，看返回的JSON再写页面逻辑。这个习惯看着小，却能在开发阶段省掉大量联调时间。HTML5的API其实就是这么一回事，不用怕，多试多拆，自然就熟了。