学 JavaScript 时，很多人会把注意力集中在语言本身，等真正做项目后才发现，浏览器提供的 Web API 才是把语言能力变成产品能力的关键。从滚动懒加载到文件上传预览，从图形绘制到复杂计算卸载，从视口观察到离屏处理，很多“像是产品功能”的东西，底层其实都在调用浏览器能力。
这一篇选几个很有代表性的 Web API 来讲，不是为了列全能力清单，而是为了让你建立一个认识：JavaScript 的价值不只是写逻辑，还在于它能调动宿主环境提供的能力，而这些能力在项目里都伴随着性能、兼容性和职责边界判断。
Canvas：为什么它不是“画图 API”这么简单？
Canvas 最直接的用途当然是绘制图形，但项目里它经常出现在更复杂的场景里，例如图表、签名板、截图处理、图片编辑、可视化面板等。它的关键特点在于：你不是像操作 DOM 那样维护结构，而是在一块画布上按像素或绘图指令输出结果。
这意味着 Canvas 特别适合大量视觉绘制、动态绘图和结构不必由 DOM 表达的场景，但它也带来不同的成本：调试方式不同、无障碍语义较弱、状态恢复和交互命中逻辑更依赖你自己维护。选择它时，重点不是“酷不酷”，而是是否真的适合当前问题。
Web Worker：为什么它能缓解主线程压力？
前面讲事件循环时说过，主线程如果长期被占用，页面就会卡顿。Web Worker 提供了一种把部分计算放到独立线程环境处理的方式，适合大数据处理、复杂计算、格式转换等不适合卡住 UI 的任务。
但 Worker 也不是随手可用的性能神器。它的适用前提是：
- 任务确实足够重，值得拆出去；
- 主线程和 Worker 之间的数据通信成本可接受；
- 这部分逻辑不依赖 DOM 直接操作；
- 你能接受多线程协作带来的状态同步复杂度。
换句话说，Worker 解决的是“主线程压力”，不是“所有慢问题”。
Worker 落地时最容易忽略什么？
最容易忽略的是“通信本身也有成本”。很多人一看到复杂计算就想丢给 Worker，但如果主线程和 Worker 之间需要频繁交换大对象、同步很多中间状态，收益可能会被通信成本抵消。真正适合 Worker 的，通常是计算相对独立、输入输出边界清晰的任务。
Intersection Observer：为什么懒加载和曝光统计离不开它？
滚动监听曾经是很多前端功能的常见做法，但频繁监听滚动并手动计算元素是否进入视口，既麻烦也容易带来性能问题。Intersection Observer 提供了更现代、更稳定的观察方式，特别适合图片懒加载、列表分段加载、曝光埋点和可见性驱动的交互。
它的重要性在于：很多浏览器协作问题，不一定要靠你自己写复杂逻辑去“算”，而可以交给更适合的宿主能力来处理。这是一种非常典型的工程思维升级。
文件处理为什么越来越常见？
现代 Web 应用越来越多地承担文件能力：上传图片、导出报表、拖拽导入、读取本地文件、预览文档、客户端压缩处理等。JavaScript 在这里既要和浏览器文件 API 协作，也要和后端上传、鉴权、格式校验、安全策略配合。
文件处理最容易被低估的地方在于，它不是“拿到文件就发出去”：
- 文件类型和大小要校验；
- 预览和实际上传可能是两条链；
- 上传中断、失败重试和状态恢复要考虑；
- 敏感文件处理要注意安全边界；
- 大文件和批量上传要关注性能和体验。
文件上传为什么总会把前后端边界一起拉出来？
因为上传链路通常不是单点动作，而是一串协作：前端负责选择、预校验、预览和状态展示，后端负责存储、权限、大小限制、格式校验和返回结果。只要这条链上任何一环没说清楚，前端很快就会陷入各种临时兼容，例如大小校验前后不一致、失败原因无法解释、重试后状态错乱、预览成功但真正上传失败。
所以文件处理其实是一个非常适合练“浏览器能力 + 接口协作 + 用户体验”三层联动的主题。
Web API 的工程思路
这类 API 在项目中最大的误区，是“某篇文章看到了，就直接往业务里塞”。更稳妥的思路是：
- 先看问题本质是什么；
- 再判断浏览器是否已有合适原生能力；
- 最后评估兼容性、性能成本和封装方式。
很多优秀前端实现，并不是“用了多少高级 API”，而是知道什么时候该用浏览器原生能力，什么时候该交给框架，什么时候该维持简单实现。
兼容性和封装为什么必须一起考虑？
因为很多 Web API 并不是所有环境都表现完全一致。哪怕现代浏览器支持度已经不错，团队也仍然需要考虑目标环境、降级策略和封装位置。如果每个页面都自己直接调用细节 API，后面一旦要兼容特殊环境或调整行为，成本会很高。把能力适度收口成稳定接口，通常比到处直连 API 更稳。
常见误区
这一章常见问题包括：
- 为了“高级感”滥用 Canvas 或 Worker；
- 只看到 API 能力，不评估通信和状态维护成本；
- 该用浏览器观察能力的场景，仍旧靠高频轮询或滚动监听硬算；
- 文件处理只做前端展示，不考虑上传链路和失败恢复；
- 发现新 API 就直接进业务，没有做合理封装。
和后续章节的关系
下一篇我们会进入与服务端协作，这会把请求、状态码、错误码和鉴权流程进一步拉回工程语境。今天这一篇更像是在提醒你：JavaScript 的能力边界，远远不止“语言本身”。
写在最后
浏览器提供的 Web API 让 JavaScript 真正具备了产品交付能力。你越早建立“语言 + 宿主能力 + 工程判断”这三层联动，越不容易把功能做成零散技巧堆砌。下一篇我们继续进入前后端协作这条主线。