一、冲突是怎么来的
时间在 2024 年中。
我们团队有 20 个项目，历史包袱太重，成了一人一坑
- Vue 8
- React 10
- 内部运营工具
这几个项目，同时有时都需要制作图形
👉 可视化编辑能力
一开始大家的做法很一致：
- Vue 项目 → Vue 实现
- React 项目 → React 实现
问题很快爆出来
大概一个月后，我们遇到了三个非常现实的问题：
❌ 同一套能力，写三遍
拖拽、缩放、撤销：
👉 每个项目各写一套
👉 不能复用，不能迁移
❌ 功能越来越难加
当产品开始提：
- 多选
- 分组
- 旋转
- 撤销
👉 每个项目都在“重造轮子”
二、第一次评审：我直接否了继续做下去
当时评审会上，其实大多数人意见是：
“继续做吧，反正都写一半了”
我当时是唯一一个反对的。
我直接说了一句比较“重”的话：
“这个方向再做下去，三个月内一定会推倒重来。”
现场其实有点安静。
因为这意味着一件事：
👉 要停掉现在的方案
三、我为什么敢这么说？
不是拍脑袋，而是三个判断：
1️⃣ 这是“编辑器”，不是页面
一旦涉及：
- 拖拽
- 缩放
- 组合
- 撤销
- 图层管理
- 动画 👉 本质已经变了
2️⃣ 复杂度是指数级增长
你现在只看到 3 个功能，后面一定会变成：
- 10 个
- 20 个
- 甚至更多
3️⃣ Vue / React 扛不住这个复杂度（不是能力问题，是边界问题）
我当时说得很直接：
Vue / React 适合做页面，不适合做“编辑器内核”
四、老板当时的反应
很真实。
第一反应不是支持，而是：
“那你打算怎么做？”
这其实是一个典型信号：
👉 你要开始背责任了
五、我当场给了一个方案（关键）
我没有讲技术细节，只讲三点：
1️⃣ 我们要做的不是组件，而是 SDK
👉 一次开发，多项目复用
2️⃣ 必须脱离框架
👉 Vue / React 都不能绑死
3️⃣ 数据必须统一
👉 不然永远无法复用
然后我补了一句：
“这件事现在不做，后面成本至少翻三倍。”
六、转折点：我主动要了主导权
老板最后问了一句：
“那你来做？”
我没有犹豫，直接答：
“我来定架构，我来兜底。”
这句话其实很关键。
👉 你不只是提方案，而是接责任
七、技术决策：为什么我选了 Web Components + Lit？
注意，这里不是“选 Lit”，而是：
👉 先选方向，再选工具
为什么不用 Vue / React？
我当时的原话是：
“我们的问题不是怎么写，而是怎么复用。”
Vue 的问题
👉 React 用不了
React 的问题
👉 Vue 用不了
两套都写？
👉 技术债直接翻倍
最终结论
必须用 Web Components 做中间层
为什么选 Lit？
因为它满足一个关键条件：
不干扰你的架构
👉 只做一件事：帮你写 Web Component
八、架构我怎么定的
我只定了一条铁律：
UI 层不允许有业务逻辑
整体结构：
Core（纯逻辑）
↓
Scene（数据）
↓
Command（操作）
↓
Renderer（渲染）
↓
Web Component（UI）
最关键的一点
唯一数据源：Scene Graph
所有操作必须走：
用户操作 → Command → Scene → UI更新
👉 UI 只是“显示器”，不是“决策者”
九、真正难的不是技术，是推进
说实话，代码不是最难的。
最难的是：
👉 让团队相信这件事是对的
阻力 1：觉得太重
很多人说：
“不就是个编辑功能吗？”
我的做法
我花了两天时间写了一个 Demo：
- 拖拽
- 缩放
- 撤销
然后直接对比：
👉 旧方案 vs 新方案
结果很明显：
新方案更简单、更稳定
阻力 2：学习成本
Scene、Command 这些概念对很多人是新的。
我的解决方案
👉 做了两件事：
- 简化 API
- 封装复杂逻辑
目标很明确：
让 80% 的人只用 API，不用懂底层
十、结果（这才是你说服人的底气）
上线之后
✅ 多项项目可以统一调用
- Vue ✔
- React ✔
✅ 功能复用率大幅提升
拖拽、缩放、撤销：
👉 一次开发，多处使用
✅ 数据完全打通
- 模板可以跨项目复用
- 可以做平台能力
十一、这件事我最大的收获
不是技术，而是这三点：
1️⃣ 技术判断要够早
👉 等问题爆炸再做，已经晚了
2️⃣ 架构必须有人拍板
👉 否则一定走向混乱
3️⃣ 要敢接责任
👉 你不兜底，没人会信你
🔥 心得
大多数前端工程师，停留在“把功能做出来”。
但真正拉开差距的，是你能不能在混乱中做出正确决策。
技术从来不是最难的，
难的是——你敢不敢拍板。
