Web Components：原生组件化开发新趋势？我在大厂踩过的坑与思考
去年十月的一个周五晚上，浦东张江的秋雨淅淅沥沥下个不停。我和女朋友小林刚吃完外卖——又是黄焖鸡米饭，她吐槽我连续吃了三天，我说“这比公司裁员通知还稳定”。那会儿我还在上一家大厂做前端，项目正卡在一个奇怪的瓶颈：明明用了最时髦的 React + TypeScript + 微前端架构，但每次产品提一个看似简单的“跨团队复用按钮”，技术方案能吵三个会，最后还得靠人力硬搬代码。
那天晚上十一点，我瘫在沙发上刷知乎，突然看到一条推送：“Amazon Q 发布，AI Agent 自动重构遗留系统”。我冷笑一声：“又来画饼？”结果点进去一看，还真有团队用它把一堆 jQuery 组件自动转成了 Web Components。我一下子坐直了——这玩意儿，不是早就被我们当成“过时的玩具”了吗？
曾经看不起 Web Components 的我，现在打脸了
六年前刚入行那会儿，我在一家中型互联网公司实习，带我的 mentor 是个老派工程师，总念叨：“浏览器原生支持的东西，永远比框架靠谱。”他力推 Web Components，但我当时嗤之以鼻。那时正是 React 和 Vue 狂飙突进的年代，谁还用 <template>、<slot> 这种看起来像 2005 年遗物的 API？
后来跳槽进了大厂，月薪从 15k 涨到 22k，住进了浦东这个月租 3500 的合租房（两人分摊，但依然肉疼）。团队用的是 React + Ant Design + 内部微前端框架，一切看起来光鲜亮丽。直到去年 Q3，公司突然启动“降本增效”，我们组被砍掉一半人，剩下的既要维护老项目，又要接新业务。更糟的是，产品团队开始疯狂推进 AI Agent 相关功能——比如智能表单、动态流程编排，要求 UI 能动态加载、组合、甚至由 GPT-4 输出结构。
问题来了：React 组件是强依赖运行时的，而我们的某些页面需要嵌入到第三方系统（比如合作伙伴的后台），对方连 JS 都不一定允许执行。这时候，产品经理小王在会上悠悠地说：“能不能做个纯 HTML 的组件，扔过去就能用？”
全组沉默。那一刻，我脑子里突然闪过 mentor 当年的话。
技术选型对比：为什么这次 Web Components 成了我的救命稻草？
冷静下来后，我拉了个表格，认真对比了几种组件化方案：
| 维度 | React/Vue 组件 | Web Components | Stencil | Lit |
|---|---|---|---|---|
| 运行时依赖 | 必须打包 React/Vue 运行时（~40KB+） | 无（原生浏览器支持） | 需要 polyfill（IE 不支持） | 极轻量（~5KB） |
| 跨框架复用 | 困难（需桥接层） | 天然支持（标准 Custom Elements） | 支持（输出标准 WC） | 支持 |
| SSR 友好性 | 好（Hydration） | 原生支持（无需 hydration） | 需额外配置 | 较好 |
| 学习成本 | 高（JSX/响应式原理） | 中（需理解 Shadow DOM） | 中高（类 Angular） | 低（类 React hooks） |
| AI Agent 集成潜力 | 依赖 AST 解析，复杂 | 结构简单，GPT-4 可直接生成 | 同左 | 同左 |
关键转折点出现在上周三。我尝试用 GPT-4 写一个“动态评分组件”——用户输入“五星好评”，AI 直接输出一段合法的 Web Component 代码，包含 template、style 和事件绑定。我复制粘贴到 HTML 文件里，刷新，居然跑起来了！换成 React？GPT-4 生成的代码要么缺 key，要么状态管理混乱，还得人工 Debug。
更让我震惊的是 Amazon Q 的演示：它扫描一个老后台系统，自动识别出可复用的 UI 模块，然后批量转换成 Web Components，并生成对应的 JSON Schema。这意味着未来 AI Agent 不仅能“理解”UI，还能“生产”UI——而 Web Components 因其标准化、无运行时、DOM 原生的特性，成了最理想的载体。
真实项目落地：从怀疑到真香
上个月，我偷偷在新项目里试水 Web Components。场景很简单：做一个“智能提示框”，由 GPT-4 根据上下文动态生成提示文案，并通过 Web Component 渲染。
class AITip extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' });
const style = document.createElement('style');
style.textContent = `
.tip {
background: #f0f9ff;
border-left: 4px solid #3b82f6;
padding: 12px;
margin: 16px 0;
font-size: 14px;
}
`;
const div = document.createElement('div');
div.className = 'tip';
div.innerHTML = this.getAttribute('content') || 'Loading...';
this.shadowRoot.append(style, div);
}
}
customElements.define('ai-tip', AITip);
然后在 HTML 里直接用：
<ai-tip content="根据您的历史记录，推荐尝试新功能：AI 自动填表"></ai-tip>
产品同事看到后眼睛一亮：“这个能嵌到客户官网吗？”我说：“只要他们用现代浏览器，连 JS 都不用改。”她当场拍板：“下周就上线！”
那一刻，我忽然明白了 Web Components 的真正价值：它不是为了替代 React，而是为了填补框架无法覆盖的空白地带——跨团队、跨系统、跨时代的 UI 复用。
吐槽与反思：别神话，也别贬低
当然，Web Components 也不是银弹。Shadow DOM 的样式隔离虽然强大，但也导致调试困难；事件穿透需要手动处理；性能在大量动态更新时不如 Virtual DOM 优化得好。而且，国内很多老项目还在 IE 上跑（别笑，是真的），你跟老板说“我们要拥抱 Web Standards”，他只会问：“兼容吗？”
我也曾和小林聊过这事。她说：“你们程序员总在‘造轮子’和‘追新潮’之间反复横跳。”我苦笑：“可现实是，有时候旧轮子反而最稳。”
但这次不一样。AI 时代的到来，让“标准化”、“可解析”、“无依赖”的组件形态变得前所未有的重要。GPT-4 和 Amazon Q 这类 AI Agent，本质上是在“理解人类意图并生成可执行结构”——而 Web Components 提供了一种接近 HTML 原语的表达方式，天然适合被 AI 理解和生成。
给同行的建议：别站队，要融合
如果你还在纠结“该不该学 Web Components”，我的建议是：别把它当成框架对手，而当成工具箱里的新扳手。
具体怎么做？
- 渐进式引入：在现有 React/Vue 项目中，用 Web Components 封装那些需要跨系统复用的部分。比如登录框、通知条、数据卡片。
- 结合 Lit 库：Lit（由 Google Polymer 团队打造）极大简化了 Web Components 开发，支持 reactive props 和模板语法，写起来像 Vue。
- 为 AI 时代准备：设计组件时，尽量用标准属性（attributes）而非复杂对象传递数据，这样 GPT-4 或 Amazon Q 才能轻松解析和生成。
- 别碰 IE：真的，放过自己。除非老板愿意多付你 5k 月薪专门搞 polyfill。
我现在的新工作，就是负责搭建公司的“AI 前端中间层”——用 Web Components 作为 UI 原子单元，由后端 AI Agent 动态组合生成页面。面试时 HR 问我期望薪资，我说“至少 28k”，她犹豫了一下说“可以谈”，我知道，这次赌对了。
最后一点真心话
写这篇文章时，窗外又下雨了。小林在厨房煮面，说“别总熬夜写技术博客，对身体不好”。我笑了笑，关掉 VS Code，打开记事本写了这段话。
六年前那个看不起 Web Components 的实习生，如今在上海一间 35 平的出租屋里，靠着重新理解“原生”二字，躲过了裁员潮，拿到了新 offer。技术没有新旧，只有合适不合适。当 AI 开始接管代码生成，我们程序员的价值，或许不再是“写得多快”，而是“想得多远”。
Web Components 不是终点，但它可能是通往下一个十年的一座桥。而我，决定先走上去看看。
—— 一个还在浦东还房贷的普通程序员，2024年深秋
评论 0