新的一篇，大概梳理一下django的url路由流程与runserver的启动流程。

（小公举小姐姐们，求赞求转发，要抱抱）
分析代码首先找到分析入口，根据由入口开始的处理流程，定位到要分析的节点。
一般调试运行django使用manager命令：

def get_response(self, request):
    """Return an HttpResponse object for the given HttpRequest."""
    # Setup default url resolver for this thread
    set_urlconf(settings.ROOT_URLCONF)

    response = self._middleware_chain(request)

    # This block is only needed for legacy MIDDLEWARE_CLASSES; if
    # MIDDLEWARE is used, self._response_middleware will be empty.
    try:
        # Apply response middleware, regardless of the response
        for middleware_method in self._response_middleware:
            response = middleware_method(request, response)
            # Complain if the response middleware returned None (a common error).
            if response is None:
                raise ValueError(
                    "%s.process_response didn't return an "
                    "HttpResponse object. It returned None instead."
                    % (middleware_method.__self__.__class__.__name__))
    except Exception:  # Any exception should be gathered and handled
        signals.got_request_exception.send(sender=self.__class__, request=request)
        response = self.handle_uncaught_exception(request, get_resolver(get_urlconf()), sys.exc_info())

    response._closable_objects.append(request)

    # If the exception handler returns a TemplateResponse that has not
    # been rendered, force it to be rendered.
    if not getattr(response, 'is_rendered', True) and callable(getattr(response, 'render', None)):
        response = response.render()

    if response.status_code == 404:
        logger.warning(
            'Not Found: %s', request.path,
            extra={'status_code': 404, 'request': request},
        )

    return response

get_response函数第一行就开始加载setting中的urlconfig，紧接着调用
response = self._middleware_chain(request)处理请求，所以可见，相应request请求的诸多操作都是经由一个个middleware处理之后的来的，那么猜一下就知道，加载url路由响应请求自然应该是在加载middleware的操作中完成的了。跟踪代码找到加载middleware函数的位置，最后定位到WSGIHandler的_get_response函数，可以发现其中的这几行代码：

if hasattr(request, 'urlconf'):
    urlconf = request.urlconf
    set_urlconf(urlconf)
    resolver = get_resolver(urlconf)
else:
    resolver = get_resolver()

resolver_match = resolver.resolve(request.path_info)
callback, callback_args, callback_kwargs = resolver_match
request.resolver_match = resolver_match

往后继续读不难发现，callback函数就是我们在view模块中定义的响应函数，用来相应客户端的请求。所以自然可以推断出get_resolver()函数是获取路由解析类的，而resolver_match则是根据用户请求获取的路由结果，callback则是针对request.path_info的相应函数。
路由加载：

@lru_cache.lru_cache(maxsize=None)
def get_resolver(urlconf=None):
    if urlconf is None:
        from django.conf import settings
        urlconf = settings.ROOT_URLCONF
    return RegexURLResolver(r'^/', urlconf)

路由：

def resolve(self, path):
    path = force_text(path)  # path may be a reverse_lazy object
    tried = []
    match = self.regex.search(path)
    if match:
        new_path = path[match.end():]
        for pattern in self.url_patterns:
            try:
                sub_match = pattern.resolve(new_path)
            except Resolver404 as e:
                sub_tried = e.args[0].get('tried')
                if sub_tried is not None:
                    tried.extend([pattern] + t for t in sub_tried)
                else:
                    tried.append([pattern])
            else:
                if sub_match:
                    # Merge captured arguments in match with submatch
                    sub_match_dict = dict(match.groupdict(), **self.default_kwargs)
                    sub_match_dict.update(sub_match.kwargs)

                    # If there are *any* named groups, ignore all non-named groups.
                    # Otherwise, pass all non-named arguments as positional arguments.
                    sub_match_args = sub_match.args
                    if not sub_match_dict:
                        sub_match_args = match.groups() + sub_match.args

                    return ResolverMatch(
                        sub_match.func,
                        sub_match_args,
                        sub_match_dict,
                        sub_match.url_name,
                        [self.app_name] + sub_match.app_names,
                        [self.namespace] + sub_match.namespaces,
                    )
                tried.append([pattern])
        raise Resolver404({'tried': tried, 'path': new_path})
    raise Resolver404({'path': path})

resolve函数解析request.path_info请求，match为匹配结果，如果匹配失败则抛出404异常，如果匹配成功则进行下一步的url解析，匹配剩余url字符（new_path = path[match.end():]），之后的代码为类似循环嵌套调用（for pattern in self.url_patterns），不断尝试匹配url_patterns中的正则规则，如果最终没有匹配项，抛出404异常，如果最终匹配成功，则返回ResolverMatch实例:
*注意：self.url_patterns可能是两种值，一种是RegexURLResolver，另外一种是RegexURLPattern。

if sub_match:
    # Merge captured arguments in match with submatch
    sub_match_dict = dict(match.groupdict(), **self.default_kwargs)
    sub_match_dict.update(sub_match.kwargs)

    # If there are *any* named groups, ignore all non-named groups.
    # Otherwise, pass all non-named arguments as positional arguments.
    sub_match_args = sub_match.args
    if not sub_match_dict:
        sub_match_args = match.groups() + sub_match.args

    return ResolverMatch(
        sub_match.func,
        sub_match_args,
        sub_match_dict,
        sub_match.url_name,
        [self.app_name] + sub_match.app_names,
        [self.namespace] + sub_match.namespaces,
    )

ResolverMatch中的sub_match.func即为view层的响应函数,至此路由完成。