html-loader的sources选项需用对象配置，在list中显式声明自定义标签/属性规则（如{tag:"my-component",attribute:"data-image"}），配合urlfilter过滤cdn路径，并为srcset单独设type:"srcset"规则。
html-loader 的 sources 选项怎么配才不漏资源又不误加载
Webpack 构建中，HTML 文件里自定义标签或非标属性（比如 <my-card></my-card>）默认不会被 html-loader 处理，导致资源无法转为模块引用、路径不被解析、构建后 404。关键不是“开不开”，而是“开哪些、怎么筛”。
默认 sources: true 只覆盖标准属性：img[src]、script[src]、link[href]（仅限 rel="stylesheet"）、video[src] 等。一旦用到 data-* 、srcset（含响应式图片）、或 Web Component 自定义属性，就必须显式声明。
- 用对象形式配置
sources，在list中追加规则，例如处理data-image：
sources: {
list: [
{ tag: "img", attribute: "src", type: "src" },
{ tag: "my-component", attribute: "data-image", type: "src" }
]
}
- 加
urlFilter过滤掉不需要处理的路径，比如排除 CDN 上的外部资源：
urlFilter: (attribute, relativePath) => !relativePath.startsWith("https://")
- 注意
type: "srcset"要单独配一条规则，srcset不会自动从src规则继承 - 如果启用了
scriptingEnabled: true，<script></script>内联代码里的字符串字面量（如"./data.json"）也会被尝试解析——容易误伤，生产环境建议保持false
Shiny 应用里怎么安全挂载第三方 JS/CSS 依赖
在 Shiny 中硬写 <script src="..."></script> 或用 includeScript() 很容易引发冲突：重复加载、执行顺序错乱、CSS 覆盖失效。根本问题是缺乏依赖生命周期管理。
htmltools::htmlDependency() 是唯一能带版本、作用域和加载时序控制的方案。它生成一个可复用、可嵌套、可去重的依赖对象，attachDependencies() 保证只在首次出现时注入，且按依赖图拓扑排序。
- 必须显式指定
package和version，否则htmltools无法做去重判断，同一依赖多次引入会导致 JS 初始化两次、CSS 样式叠加异常 - JS 文件优先用
script类型并设eval = FALSE（避免 R 解析报错），CSS 用stylesheet类型 - 不要把
htmlDependency()放在server()函数里——它属于 UI 层声明，放 server 会导致每次 session 重建都重注册，触发重复注入 - 若依赖需动态路径（如用户上传的配置文件），改用
tagList()+onRender()在客户端 JS 里 fetch，避开服务端路径解析
loading="lazy" 在组件化 HTML 中的兼容性陷阱
原生懒加载看似省事，但在组件化场景下极易失效：Web Components 的 shadow DOM 不触发 Intersection Observer；自定义元素未 upgrade 完成前，img 标签可能已被浏览器预解析并提前加载；Safari 15.4 以下完全忽略 loading 属性。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
更隐蔽的问题是：组件模板中若同时存在 src 和 loading="lazy"，Chrome 会立即发起 src 请求（即使不在视口），等滚动到位置再触发懒加载逻辑——造成重复请求。
- 对 Web Components 内部的图片，必须用 JS 方案：监听
slotchange或connectedCallback后，手动调用IntersectionObserver，并把src移到data-src - 首屏必现的图片（如 logo、hero banner）务必显式写
loading="eager"，不能依赖默认值，否则部分 Chromium 版本会 fallback 到 lazy 行为 - 使用
picture+srcset时，loading只作用于最外层img，内部source不受控——此时应统一用 JS 懒加载方案 - 所有懒加载图片必须带
width和height，否则组件渲染时尺寸未知，触发 CLS（Cumulative Layout Shift），Core Web Vitals 直接扣分
为什么 @import 在组件 CSS 中是性能地雷
组件级 CSS 文件若用 @import 引入工具类或变量，等于给整个组件树加了一层同步阻塞：浏览器必须下载、解析完被 import 的文件，才能继续编译当前 CSS，且无法与其他 link 并行。
尤其当多个组件各自 @import 同一个 variables.css，Webpack 会分别打包进每个组件 CSS，导致重复内容、缓存失效、体积膨胀——这不是复用，是污染。
- 所有
@import必须出现在 CSS 文件最顶部，否则整条语句被忽略（连 warning 都不抛） - 构建阶段用 PostCSS 插件（如
postcss-import）内联@import，但要注意：路径解析基于入口文件，不是被 import 文件自身位置 - 真正需要条件加载（如暗色主题）时，用
<link rel="stylesheet" media="(prefers-color-scheme: dark)">，而非在 CSS 里写@import套 media 查询 - 组件库作者应提供已预处理的 CSS bundle（含全部依赖），而不是让用户自己拼
@import链——后者等于把构建复杂度甩给下游
实际项目里，最常被忽略的是资源加载的作用域边界：webpack 的 sources 只管 HTML 字符串层面，Shiny 的 htmlDependency 只管 R 层声明，而浏览器原生 loading 和 @import 又各自跑在不同阶段。三者不协同，优化就变成补丁叠补丁。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
