django 为什么不能在生产用runsnerver启动那个部署，flask为什么不能在生产环境使用app.run部署的精确本质原因？

网上一般人都回答不好，回答的是结果不是原因都是人云亦云的，没有精确到本质原因。

这就和中医不求甚解只能卖弄玄学一样，只有西医能力精确到本质分子结构才能让人信服，所以大家初中就要学现代生物课，为什么不学老祖宗的本草纲目？

为什么不能用那个自带的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部署也能支撑瞬间高并发。

反正网上回答人云亦云，没说到本质，回答牛头不对马嘴。