网上一般人都回答不好，回答的是结果不是原因都是人云亦云的，没有精确到本质原因。
这就和中医不求甚解只能卖弄玄学一样，只有西医能力精确到本质分子结构才能让人信服，所以大家初中就要学现代生物课，为什么不学老祖宗的本草纲目？
为什么不能用那个自带的runserver部署，也必须要精确原因呢才行。
先看看网上人云亦云的回答。
这些回答都是说了个寂寞呢，别人想知道原因，你回答的是结果，都是回答说性能更好更稳定，线上一定要用uwsgi来不用自带的runserver。
本质原因是uwsgi在配置 多线程可以绕过io阻塞 + 多进程充分利用多核。
现在先不要想你是在做一个web服务了，先来看看下面一个简单的函数
import time
def view_func(x):
time.sleep(60)
return x * 10
函数即使接受入参x，然后返回结果是入参的10倍。但是函数耗时60秒。
假设100个人每人调用一次这个函数，相当于把这个函数调用哪个了100次，那么总的耗时是6000秒，假设同一秒钟有100人调用函数，那么第一个人需要60每秒后得到结果，第100个打开浏览器调用这个函数的人需要等6000秒后才能得到结果。
第一个人还能忍受，第100个打开浏览器的用户情绪简直是崩溃了，差不多要等2小时得到结果。
如果要加快速度，那么利用threadpoolexecutor线程池来运行函数，pool.submit(view_func，x)，假设线程池大小是500，开他娘的500线程，别说100人同一秒访问，就是300人同一秒访问，也可以在60秒内给所有人返回函数结果。
uwsgi的配置里面设置线程数量来运行web服务，和python用线程池来运行函数是一个道理，这才是本质啊，说那些稳不稳定这种玄学回答是没有说到本质点子上。
uwsgi除了多线程同时也是叠加多进程，多进程+多线程充分利用io和多核cpu。类似的gevent 和uwsgi也是很相似的功能。一般这些东西都是从配置里面就能看出来了，都是多进程+ 多线程(或者协程)。
不要说那些玄学，说uwsgi是什么c语言写的啊，c语言给django函数加速啊，扯这些有的没的没用，即使是python自带的线程池也能绕过io实现加速，只不过效率没c语言的好，但如果django视图函数耗时是秒级，那么c语言的调度并不会比python的调度快很多了。
之所以很多人在开发环境用runserver，自测没发现卡顿，主要是一个是开发自有自己一个人访问，很少瞬间内用浏览器同一秒打开几十个标签，而且开发环境那的数据库数据很少，视图函数本身只需要0.1毫秒就能计算出结果，即使是瞬间打开1万个浏览器标签，也不会感受到django服务的卡盾了。反正就是如果视图函数是0.几毫秒级，例如视图函数什么逻辑都没有直接return "hello"，那么不使用uwsgi gunicorn部署也能支撑瞬间高并发。
反正网上回答人云亦云，没说到本质，回答牛头不对马嘴。