HTML插槽（）是运行时Shadow DOM内容投影机制，不参与HTML解析、SSR或静态分析，无法被CDN缓存、SEO提取或服务端识别；其内容须由父组件显式提供，仅在客户端水合后生效，对首屏性能和SEO有实质影响。
HTML插槽（<slot></slot>）本身不兼容传统内容分发
Web Components 中的 <slot></slot> 是运行时内容分发机制，依赖 Shadow DOM 的渲染逻辑。它不参与 HTML 解析阶段的内容迁移，也不被服务端（如 SSR 框架、CDN 预渲染）或静态分析工具识别为“可分发内容容器”。所谓“内容分发策略”若指 CDN 缓存粒度、SEO 内容提取、或服务端动态注入，<slot></slot> 无法直接适配。
常见错误现象：document.querySelector('slot') 取不到插槽内容；搜索引擎只索引宿主元素的空标签；SSR 输出中 <slot></slot> 内部内容丢失或错位。
-
<slot></slot>的内容必须由父组件在 DOM 树中显式提供（即 light DOM 子节点），且仅在组件 attach 到文档后、Shadow DOM 渲染时才被“投影”，不是 DOM 移动，而是视觉重定位 - 没有
slot属性的子节点默认投射到匿名插槽；有name的需严格匹配，大小写敏感，且不支持通配或正则 - 服务端无法执行 JS，因此无法触发 slot 分发逻辑——这意味着所有基于
<slot></slot>的布局/文案都属于客户端水合后才可见内容，对首屏 SEO 和 LCP 有实质影响
想让插槽内容参与 SSR 或 CDN 分发，得绕过 <slot></slot> 原生行为
真正可行的做法是：放弃把内容“塞进 slot”再靠浏览器分发，转而用服务端可控的方式提前生成等效结构。
- 使用属性传值（如
heading-text、body-html）替代 slot，服务端可直接渲染为普通 DOM 节点，CDN 缓存友好，也避免水合 mismatch - 若必须保留 Web Components 封装，可在构建时用工具（如
@web/dev-server+lit-dev-server-ssr）预执行组件并展开 slot 投影，输出纯 HTML - 对 SEO 敏感区域（如文章标题、摘要），宁可用
<div slot="title"> + 服务端模板条件判断是否渲染该 div，也不要依赖 slot 自动分发 <h3> <code><slot></slot>的 fallback 内容不会被分发，仅作占位提示写在
<slot></slot>标签内的内容（如<slot>Default text</slot>）是 fallback，仅当无匹配 light DOM 节点时才显示。它不属于“可分发内容”，也不会出现在 slot 的assignedNodes()结果中，更不会被提取为元数据或缓存键的一部分。
Wechat Article Html下载将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- fallback 文本无法被翻译系统扫描（i18n 工具通常跳过 slot 内部文本）
- 若通过 CSS
display: none隐藏了外部传入的内容，fallback 不会自动激活——slot 不做运行时存在性检测，只看初始 assigned 状态 - 服务端渲染时，fallback 文本可能被当作真实内容输出，造成与客户端水合后内容不一致（hydration error）
复杂点在于“分发”定义模糊：你到底想分发给谁？
如果目标是 CDN 缓存，
<slot></slot>内容必须固化为 HTML 字符串；如果是 SEO，内容得在初始 HTML 中可见且语义正确；如果是微前端间通信，应改用 props/events 而非 slot 投影。Slot 是 UI 组合原语，不是内容交付协议。它解决的是“同一个组件在不同父上下文中复用模板”的问题，不是“如何把一段内容高效推送到边缘节点”的问题。最容易被忽略的是：开发者常把
<slot></slot>当成include或partial来用，但它的执行时机、作用域隔离、以及与 hydration 的耦合，远比模板包含复杂得多。
