技术选型除性能指标外，还要评估学习资料、招聘和单点依赖等"软指标"

OpenResty的早期使用者坦言，虽然它的性能足以比肩甚至超过其他所有高性能解决方案，但依然会担心几个和性能无关的问题：缺少足够的学习资料（早期几乎找不到系统的中文教程）、招不到熟悉这门技术的人、缺少可以交流的社区，以及更深层的担忧——万一某天核心维护者（这里指OpenResty的作者章亦春）不再维护这个项目，整个技术栈是不是就此陷入停滞。这些担忧不是杞人忧天：小米抢购系统的真实案例里，团队虽然验证了OpenResty的性能完全满足需求，但因为团队里熟悉OpenResty的人太少，最终还是把系统改成了用Golang实现——性能达标并不足以让一项技术在团队里真正扎根。这个案例提示了一条容易被技术人员忽视的选型原则：架构师做技术决策时，除了衡量吞吐、延迟这类看得见的性能指标，同样要认真评估这门技术的”软指标”——学习曲线和现成资料是否充足、招聘市场上是否有足够的人才储备、社区是否活跃、项目的可持续性是否过度依赖某个或某几个核心个人。一项技术性能再好，如果团队招不到人维护、新人学习成本过高、或者存在关键个人的单点依赖风险，都会在实际落地和长期维护中付出比性能优化更大的代价——这类风险往往在技术选型阶段的性能测试中完全体现不出来，必须被单独、主动地纳入评估维度。