你有没有过这样的经历？
- 在Unity里，手动用坐标判断两个物体是否碰撞，写了几十行边界检测逻辑，结果朋友一句“你为什么不用Collider？”让你愣在原地；
- 在Cocos2d-x中，手搓了一套策略模式来实现组件功能切换，后来才发现cocos2d::Component早就内置了完整的组件系统；
- 在Vue项目里，一层层emit传状态，父子孙曾组件通信像打电报，直到某天听说了Pinia，才意识到“原来状态可以集中管理”；
- 甚至更经典的：C语言初学者写了100行的printf(“1”)、printf(“2”)……却从未想过“循环”这种东西存在。 我们不是能力不足，也不是不愿学习——而是根本不知道“这个问题已经被优雅地解决了”。
这种“我不知道我不知道”的状态，在认知科学中被称为 “未知的未知”（Unknown Unknowns）。它比“已知的未知”更危险，因为你连提问的方向都没有。
为什么我们总在重复造轮子#
1. 问题没有被明确定义，就没有办法搜索解决方案#
明确的定义一个问题并不是非常自然的做法，因为定义问题意味着去抽象和界定，它需要保持很大的清醒，而这种状态往往是很难得的。所以面对问题时，我们大部分时间是没有足够清醒到去明确定义它的。
就像我们在刚开始写vue的时候，我们在使用emit时心里想的是把子组件的数据传给父组件，乃至后面让曾孙组件把数据给孙组件，再让孙组件把数据给子组件，再父组件…我们可能会觉得这样写很难受，但是我们的状态没有清醒到能意识到这是一个“全局状态管理问题”，也就没有想法去搜索全局状态管理，从而认识pinia。
2. 大脑本身具有“舒适区”#
心理学上有个概念叫 “功能固着”：人倾向于用熟悉的方式解决问题，哪怕效率低下。
你已经学会了if-else，那么你遇到多分支就堆砌逻辑； 你熟悉emit，你需要通信就靠事件冒泡； 你会面向对象，遇到可替换行为就自己手写封装。
这不是懒惰，而是大脑的节能机制–调用已有技能比学习新范式更不需要打破舒适区。
3. 学习路径缺失#
很多技术都缺少合适的学习资源，所以自己探索时总是会漏过很多内容，产生很多“未知的未知”。
即使是比较热门的技术，其入门教程往往也只教让非常简易的项目跑起来，而不是工程实践中到底怎么用
我们只学了最基础的用法，当我们初次去做项目时，也只会用最简单的用法。
结果就是：我们在小 demo 阶段养成习惯，等项目复杂了才意识到问题，但重构成本已高。
4. 框架的轮子藏的太深#
就像cocos2dx的cocos2d::Component组件一样，在cocos官方的教程中一嘴都没提，如果不是查cocos2dx api我根本不知到这个东西的存在。
如何训练自己看见轮子#
训练问题敏感度和抽象能力#
在开发过程中做一个“讲究人”，一旦遇到不舒服的情况立马总结不舒服的原因，并且查问题。
例子：
使用传统MVC模式发现不得不写很多胶水代码，核心业务不聚焦，耦合高=>不舒服=>设计模式问题，MVC不舒服的解法=>认识MVVM架构，采用前后端分离MVVM+RESTful API=>解决问题，认知拓宽
写了很多层emit和props，组件里各种通信变量太乱=>不顺眼=>变量和函数的全局状态管理=>了解pinia，引入pinia，项目大大优化，认识增加
养成先问再写好习惯#
在开始处理这个模块之前，先问自己
- 这个功能有没有前人提供好的工程实践；
- 业界通常怎么做；
- 有没有官方或者社区公认的最佳实践。
有时候五分钟的搜索可以省下五小时的弯路。
理解框架的设计哲学#
- Unity 信奉 “组合优于继承” → 多用 Component，少写继承树
- Vue 3 + Pinia 倡导 “状态集中 + 响应式” → 少用深层 emit
- React 鼓励 “状态提升 + 自定义 Hook” → 避免 prop drilling
理解框架的思想，就知道和这些思想冲突的实践通常都有更好的做法
多实践，多交流#
多多实践，多做工程，渐渐地见识就会广大，知识就会丰富，很多一开始“未知的未知”，也就成了常识般的“已知”。
多交流则是说多和领域错开的，或是同领域做的更深入的人交流，从而从其他人身上吸收最佳实践，形成“问题-方案”映射库。
结语#
人要善于调用人类集体的智慧，不只是写代码。“从零开始干”，“从头创造”常常被人赞扬，但是真正的智慧者，应当是在识别问题模式之后，精确地调用已有的高效解决方案。
很多时候我们缺的不是能力，而是“知道这个问题已经被解决过”的元认知。
下次当你在工程中准备手写一个通用功能时，不妨先停下来，想一想：
这个轮子，是不是早有人造好了？
如果答案是“是”—恭喜你，又省下了一个周末
愿我们少造轮子，多造世界。
以上观点仅针对工程实践，歌颂所有造轮子的贡献者。