Web API 不能直接封装成 HTML 组件接口，因为 HTML 本身无网络能力；必须通过 Custom Elements + fetch 在生命周期钩子（如 connectedCallback）中发起请求，并用属性、事件、slot 映射状态与数据，同时处理跨域、缓存、卸载中断等边界问题。
不能直接把 Web API 封装成 HTML 组件接口——HTML 本身不提供网络请求能力，所谓“封装”其实是用 Custom Elements + fetch 或 XMLHttpRequest 在组件内部发起请求，并把参数、状态、错误、响应结果映射为属性、事件和 slot 内容。
为什么不能在 <template> 里写 fetch
<template> 只是 DOM 片段容器，不执行脚本；它里面放 <script> 标签也不会运行。常见错误是把 API 调用逻辑塞进模板字符串或 innerHTML 里，结果请求根本不会触发。
- 所有异步逻辑必须写在 Custom Element 类的生命周期钩子中，比如
connectedCallback或自定义方法里 - 若用
template声明结构，需在 JS 中克隆后手动注入数据，不能指望模板自动“拉数据” - 直接在
shadowRoot.innerHTML = `...${await fetch(...)}`会报错：模板字符串求值发生在同步阶段，await不合法
customElements.define() 中如何安全发起请求
组件注册后，实例化时（如 <api-user id="123"></api-user>）应立即读取属性并触发请求，但必须防重复调用、防未挂载就请求、防属性未就绪。
- 在
connectedCallback中检查this.hasAttribute('id')，避免空属性触发 404 - 用
AbortController绑定组件生命周期：在disconnectedCallback中调用abort()，防止组件卸载后 still pending 的 promise 更新已销毁的 shadowRoot - 不要在
constructor里发请求——此时this.getAttribute()可能返回null，且 shadowRoot 还未创建 - 错误处理必须显式写：
catch后设置内部状态（如this.error = 'Network failed'），再触发this.render()或 dispatcherror事件
如何暴露 API 结果给外部使用
组件不是黑盒，外部需要知道数据何时可用、怎么取、怎么监听变化。靠属性、事件、slot 三种机制配合。
立即学习“前端免费学习笔记（深入）”；
- 响应结果建议存为
this.data，并用Object.defineProperty或get访问器暴露只读属性，避免外部误改 - 关键状态变更（如 loading → success）必须 dispatch 自定义事件：
this.dispatchEvent(new CustomEvent('load', { detail: this.data })) - 用
<slot>分发内容时，别直接塞原始 JSON 字符串；应在render()中解析后插入<slot>的 fallback 内容，或通过slotchange事件监听用户传入的自定义模板 - 如果组件支持多次请求（如搜索框），应提供
refresh()方法供外部主动触发，而不是仅依赖属性变更
容易忽略的跨域与缓存问题
浏览器对 fetch 的跨域限制和缓存策略，在组件内不会自动绕过，反而更隐蔽——因为错误常表现为“没反应”，而非控制台红字。
- 默认
fetch不带 credentials，遇到需要 Cookie 登录的 API 会 401；必须显式加{ credentials: 'include' } - GET 请求默认可被缓存，连续请求同一 URL 可能返回旧数据；加
cache: 'no-cache'或拼时间戳参数（如?t=${Date.now()}） - 服务端若返回
Content-Type: application/json但实际是 HTML（如登录跳转页），response.json()会直接抛错；务必先response.ok判断状态码，再按response.headers.get('content-type')分支处理 - 本地开发时，Chrome 禁止
file://协议下跨域请求，直接双击 HTML 打开必失败；必须起一个本地 server（如npx serve）
真正难的不是发请求，而是让组件在各种边界条件下仍保持状态一致：属性乱序设置、网络中断重试、父组件反复移除/插入、多个实例共享同一 API 端点。这些都得靠细粒度的生命周期控制和明确的通信契约，而不是堆代码。
