想象这样一个场景：你的团队要打造一款新车，真正的创新之作。它得与众不同，得传递出大胆和前卫的品牌信号。到了选轮毂的环节，你们盯着市面上那些圆滚滚的轮胎——太普通了，太 predictable 了。圆轮是行业标准，能跑，但毫无个性。

然后有人灵光一闪：咱们的品牌徽章是八边形的，够独特，够现代。要是轮毂也做成八边形呢？视觉统一，辨识度拉满。团队兴奋了，调研一番，确认没人这么干过。设计、制造、发布。车确实好看，惊艳。

打开网易新闻 查看精彩图片

直到用户真的开上路。

"有点抖。""这颠簸是故意的吗？"

八边形车轮滚动起来并不平顺。解决方案？引入合作伙伴做减震层，额外加一层缓冲来抹平颠簸。优雅的技术补丁，几个月后问题"解决"了。团队很满意。

紧接着下一波反馈：换不了胎。标准工具用不了。团队再次调整优先级，开发适配器，培训维修点，重建物流体系。

这还没完。前悬架异响、高速磨损严重、座舱噪音、制动不匀……每个问题都可解，但每个解法都在原有系统上再叠一层。时间、资源、复杂度，层层累积。

读到这你可能发现了：这不是在说车。

这是在说我们怎么造东西。标准之所以存在，不是为了扼杀创意，而是因为它们经受过无数轮迭代，确实能用。圆轮是现成的，可靠、兼容、免维护。八边形轮毂是我们为了"更像自己"而造的，代价是用大量时间让它追上原本就有的体验。

网页开发同理。HTML 内置的组件不是浏览器的限制，而是优势——它们健壮、经测试、用户熟悉。每当我们选择重写一个已有解法，往往承担了比预期更重的责任。

省下来的时间可以投向真正创造价值的地方：

1. 性能优化

2. 安全加固

3. 搜索引擎适配

4. 可用性测试

5. 错误处理

6. 文档完善

7. 自动化测试

8. 边界情况覆盖

9. 技术债务清理

八边形车轮的故事当然夸张。但现实中，自定义 UI 库重复实现浏览器原生功能的情况，比想象中常见。作为设计师、开发者、产品经理，我们可以在流程更早阶段问自己：这东西，真的需要重新造吗？