1.性能不应该作为第一考虑因素，"开发容易，使用简单，便于维护“是第一原则

2.选择团队中大部分人熟悉的语言、框架、理念

•     减少新框架、新语言引入过程中需要踩的大量坑，这个往往会delay计划排期，而且是大大地delay。
•     杜绝采用新技术新框架模块在交接时的困难，只有少数人懂的技术、语言非常难以交接
• 技术创新应该被鼓励，但是要慎重，和当前的解决方案比较，突出优势是什么，是否有效解决技术问题，是否便于维护。

3.对于开源组件的态度，如果产品在验证期，需要快速上线，那么开源组件是不错的选择，但开源组件要用好用稳定不容易，在产品成熟期应该尽量自实现。

4.盲目最求新技术、热技术而频繁替换线上稳定系统，是糟糕的开发体验，不要为了技术而技术，而忘记是否真正有效解决问题

5.技术选型一个重要前提是把握业务细节、了解业务目标，没有万能的框架，万能的方案，只有适合业务的框架和方案，需求都不了解的情况下讨论技术选型没意义。

6.不要陷入“设计灾难”的怪圈，一开始设计大而全的系统往往会失败，因为大而全往往是“想当然”想出来的，应该使用简单有效的方案，解决大部分问题。

•     产品初期，需求总是不够明确不够清晰的，简单的方案易于调整和扩展。而“大而全”方案一旦后期发现不适合业务特定，将非常难以调整。
•     简单方案易于版本迭代，可以快速实现系统的最小化可用上线。