Appearance
轻量框架与 Web Components
轻量框架通常用于特定问题：更小的运行时、更细粒度的响应式、更接近 Web 标准、或在既有页面中增加少量交互。它们不一定适合作为所有业务系统的默认选择，但在合适边界内能明显降低复杂度。
主流方向
| 工具 | 定位 | 适用场景 |
|---|---|---|
| Preact | React API 的轻量替代 | 追求小体积、兼容 React 组件模型 |
| Solid | 细粒度响应式 UI 框架 | 高交互、性能敏感、希望避免虚拟 DOM |
| Qwik | 面向可恢复性和延迟加载 | 首屏性能敏感、复杂页面渐进激活 |
| Lit | Web Components 开发库 | 设计系统、跨框架组件、标准 Web 组件 |
| Alpine.js | HTML 增强式轻量交互 | 服务端模板、活动页、少量交互 |
适用边界
轻量框架适合“局部复杂、整体简单”的页面，例如后台系统中的嵌入式小组件、传统服务端模板中的交互增强、跨框架复用的组件库、对首屏 JavaScript 体积极其敏感的页面。
如果项目需要大量业务页面、复杂路由、成熟 UI 组件库、招聘和长期维护，React、Vue 或 Angular 通常更稳。轻量框架不是不能做大型应用，而是需要团队承担生态和工程规范建设成本。
Web Components
Web Components 适合跨技术栈复用组件，例如设计系统同时服务 React、Vue 和原生页面。Lit 可以降低直接编写 Custom Elements 的样板代码。需要注意的是，Web Components 与框架的事件、表单、样式隔离和服务端渲染集成并不总是零成本。
排查入口
| 现象 | 检查点 |
|---|---|
| 组件在某框架里事件不触发 | 自定义事件、事件冒泡和框架封装差异 |
| 样式无法覆盖 | Shadow DOM、CSS 变量、样式穿透策略 |
| 包体积没有下降 | 是否引入了大型组件库或 polyfill |
| 团队维护困难 | 是否缺少统一脚手架、测试和组件规范 |