本文是2023年技术复盘文章之一。

复盘带来思考，通过思考取其精华，精进自我，提升赚钱能力。

平时对django的源码饶有兴趣，时不时翻看源码。本篇总结重在梳理django启动流程，了解在该过程中，到底发生了哪些事，用了哪些值得学习的方法。

注：生产环境和开发环境，仅入口文件及前面的某些流程有别而已，所以就以开发服务器启动的流程来分析。另外，我制作了一张启动的流程图，如想获取，移步文末看获取的方法。

第一步：入口文件启动

在上一篇django是如何加载settings的复盘中已有描述，manage.py会启动一个命令行管理工具类，命令行工具名为MangemenUtility类，执行它的execute方法会进入到启动流程。

django.core.management.__init__.py

def execute_from_command_line(argv=None):
    """Run a ManagementUtility."""
    utility = ManagementUtility(argv)
    utility.execute()

第二步 ：载入配置文件、载入django模块

这里不再赘述，可看上一篇文章django是如何加载settings的：

在载入配置文件后，会继续载入django的各模块，加载内置的和开发者自定义的模型类：

django.core.management.__init__.py

class ManagementUtility:
    # 省略其他代码
    def exexute(self):
        # 省略其他代码
        django.setup()
        # 省略其他代码
    # 省略其他代码

对django.setup()感兴趣的可自行查看源码。

只要运行了django.setup()，就能在当前进程中使用django的模块了，这也是我们要在子进程中使用django时，需要使用该方法的原因。如：

当然，这个步骤还有不少琐碎之事，如：

• 解析命令行参数和选项
• 热重载时语法检查（闭包函数实现）

第三步：调用Command类运行命令

需要先行注明的是，该环节有点绕，涉及到三个类，分别是：

1、当前Command类（该步骤所说的当前类均指该类），位于：

django.contrib.staticfiles.management.commands.runserver文件中

2、父类Command类（子类和它同名，??，该步骤所说的父类均指该类），位于：

django.core.management.commands.runserver文件中

3、祖父类BaseCommand该步骤所说的当祖父类均指该类），位于：

django.core.management.base文件中

走入这个绕脑袋的流程，就从self.fetch_command(subcommand).run_from_argv(self.argv)开始

class ManagementUtility:
    # 省略其他代码
    def exexute(self):
        # 省略其他代码
        django.setup()
        # 省略其他代码
        self.fetch_command(subcommand).run_from_argv(self.argv)
    # 省略其他代码

subcommand就是一个当前的Command类实例，由它去调用run_from_argv方法，这个方法，在祖父类中才有：

1、跳转到祖父类中的run_from_argv方法，在该方法中又执行了execute方法；

def run_from_argv(self, argv):
	# 省略其他代码
    try:
        self.execute(*args, **cmd_options)
    except CommandError as e:
        if options.traceback:
            raise
	# 省略其他代码

2、当前类中并没有execute方法，其父类中有，但也没干什么特别的事，又super().execute()跑回祖父类的execute方法了，

def execute(self, *args, **options):
	# 省略其他代码
    # 一灯注：检查迁移文件
    if self.requires_migrations_checks:
        self.check_migrations()
    # 一灯注：handle是个非常重要的节点的入口
    output = self.handle(*args, **options)
    # 一灯注：连接数据库
    if output:
        if self.output_transaction:
            connection = connections[options.get("database", DEFAULT_DB_ALIAS)]
            output = "%s
%s
%s" % (
                self.style.SQL_KEYWORD(connection.ops.start_transaction_sql()),
                output,
                self.style.SQL_KEYWORD(connection.ops.end_transaction_sql()),
            )
        self.stdout.write(output)
    return output

3、self.handle是个非常重要的节点入口，父类中声明了该方法必须在子类中重写，当前类并无handle方法，那么它一定在父类中实现了：

def handle(self, *args, **options):
    if not settings.DEBUG and not settings.ALLOWED_HOSTS:
        raise CommandError("You must set settings.ALLOWED_HOSTS if DEBUG is False.")
    # 省略其他代码
    self.run(**options)

4、self.run方法在当前类中也没有，在父类中有，self.run又迅速跳转到self.run_inner方法，同样的，该方法依然在父类中：

def inner_run(self, *args, **options):
    # 省略其他代码
    # 一灯注：检查迁移文件，和上面的检查迁移文件是二选一，即总会有一个节点是要检查的
    self.check_migrations()

    try:
        handler = self.get_handler(*args, **options)
        # 一灯注 run函数入参，传入了handler
        run(
            self.addr,
            int(self.port),
            handler,
            ipv6=self.use_ipv6,
            threading=threading,
            on_bind=self.on_bind,
            server_cls=self.server_cls,
        )
    except OSError as e:
        # 省略其他代码
        pass

这里是一个重要的分水岭，在该代码中，handler = self.get_handler(*args, **options)能获取到一个WSGIHandler的实例，它专门用来处理请求和响应的，即让请求和响应进入到django的内部中。既然是分水岭，那它到底分了什么呢？重点如下：

self.get_handler方法在当前类和父类都有，我们是通过当前类进来的，那么它当然会使用当前类的get_handler方法：

def get_handler(self, *args, **options):
    """
    Return the static files serving handler wrapping the default handler,
    if static files should be served. Otherwise return the default handler.
    """
    handler = super().get_handler(*args, **options)
    use_static_handler = options["use_static_handler"]
    insecure_serving = options["insecure_serving"]
    if use_static_handler and (settings.DEBUG or insecure_serving):
        return StaticFilesHandler(handler)
    return handler

StaticFilesHandler的源码就不贴了，它的功能是，在开发服务器环境下，包装WSGIHandler类，增加了静态文件处理的方法。故当我们使用python manage.py runserver 启动开发服务器时，之所以能处理静态文件，关键点就在这了。请注意，在上面 run函数中，传入了StaticFilesHandler类实例，形参为：handler。

再来说说，父类的get_handler方法，比当前类的更简单，它直接获取了一个WSGIHandler的实例，DEBUG = False时，会使用父类的get_handler，我们在开发服务器上设置DEBUG = False时会无法处理静态文件，样式文件、js文件统统丢失。

注：

1、WSGIHandler有__call__方法，上面的流程，获取到的都是它的类实例，这个类实例最后会交给底层服务器，由底层服务器调用实例，也就是调用__call__方法；

2、它在实例化时，自动加载一次中间件，并把所有中间件可调用的方法组合成一个中间件链（middleware_chain），供后面所使用。

再回头看看handler = self.get_handler(*args, **options)下方的run函数，它由外部文件引入，运行run方法后，启动流程就基本结束了。

第五步：运行run函数

该方法在django的服务器模块中：

def run(
    addr,
    port,
    wsgi_handler,
    ipv6=False,
    threading=False,
    on_bind=None,
    server_cls=WSGIServer,
):
    server_address = (addr, port)
    if threading:
        httpd_cls = type("WSGIServer", (socketserver.ThreadingMixIn, server_cls), {})
    else:
        httpd_cls = server_cls
    httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)
    if on_bind is not None:
        on_bind(getattr(httpd, "server_port", port))
    if threading:
        httpd.daemon_threads = True
    httpd.set_app(wsgi_handler)
    httpd.serve_forever()

这一步，我们只关注重点：

1、httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)，启动了一个WSGIServer服务器，再往下看就追溯到底层了：socketserver服务；

2、httpd.set_app(wsgi_handler)把WSGIHandler或子类StaticFilesHandler设置为底层服务socketserver的application

3、在底层中，如果有请求，就会调用application即applicaiton()，把请求转交给WSGIHandler或子类StaticFilesHandler的__call__方法；

4、在httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)中，入参WSGIRequestHandler，它继承与wsgiref，看源码功推测应该是把原始的请求 包装成django的规范，以便请求进入到WSGIHandler或子类StaticFilesHandler的__call__方法时，就可以直接使用了，也就是我们在视图中经常接触到的HttpReqeust和HttpReponse对象。

至此，整个启动流程就结束了。

题外话

WSGIHandler或子类StaticFilesHandler的__call__方法是django处理请求响应的开始，从这里开始，流程如下：

• 加载中间件
• 控制请求逐一经过请求中间件
• 解析url，获取视图
• 请求经过视图，生成响应
• 控制响应逐一经过中间件
• 响应传递给底层服务器

这里就不展开了，内容真的很多。

总结

1、整个流程似乎没看到什么异步操作，毕竟上下文联系得很紧凑，完成一步才能走到下一步流程

2、OOP的继承特性发挥到极致了，但也带来一些问题，阅读源码真的不容易，除了看不懂的，思路跟着流程在各个子类、父类、祖父类之间上蹿下跳也是一个大挑战；

3、不过继承特性也有好处，至少在django的启动流程中，开发服务器的启动和生产服务器走的流程，使用继承特性来满足分支需求显得非常容易；

4、会想起刚接触编程没多久，强行将各种不同功能函数揉成一个类，而各种教程也非常喜欢使用Person 、Car之类的案例来讲述类的作用，随着经验见长，不断地阅读优秀的代码之后，对类才有了一些体会，在上面的Person和Car的基础上，增加一点个人拙见：

一个类，旨在完成一项工作，一项工作需要很多细节，如果几项工作的细节雷同，那么可以抽象一个基类了，N项工作都能继承该基类，如果方式相同，但细节不同，也可以抽象基类，子类可实现各自的细节。

问题

在WSGIhandler中，为何要设计一个__call__来处理请求和响应呢？普通类成员方法也是可调用的，只能靠猜测了：

1、可能底层服务要求入参的handler必须是一个类实例

2、该类实例必须可调用

最后

个人水平有限，不当之处还请指出，感激不尽。
另外，我也将上面的流程绘制成了流程图，需要的可在评论区留言。