Django URL Dispatcher机制深度解析：从路由映射到URL反解

URL Dispatcher的核心功能是根据请求的URL，将其分发至对应的处理函数。这本质上是URL与View之间的一种映射关系，其实现原理基于正则表达式匹配：预先定义好正则规则及对应的View函数，当请求URL符合该规则时，系统将请求分发至相应的View进行处理。

基于上述基础，我们需要提前思考几个关键问题：

第一，这些映射关系定义在何处？当映射规则众多时，如何高效组织它们？

第二，如何从URL中提取参数，并将其传递给View函数？

第三，如何在View函数或Template模板中反向解析出对应的URL？

首先，通过一个简单示例来直观理解：

from django.conf.urls import patterns, url, include
urlpatterns = patterns('',
  url(r'^articles/2003/$', 'news.views.special_case_2003'),
  url(r'^articles/(\d{4})/$', 'news.views.year_archive'),
)
urlpatterns += patterns('',
  url(r'^articles/(?P<year>\d{4})/(?P<month>\d{2})/$', 'news.views.month_archive'),
  url(r'model/', include('model_test.urls')),
)

上述代码展示了一个URL Dispatcher的具体实现。在Django中，这种包含URL路径与处理方法映射关系的Python模块被称为URLconf，它实际上是通过Python代码编写的配置文件。Django采用“树”状结构来管理URLconf之间的关系。主配置文件中存在一个名为ROOT_URL_CONF的配置项，用于指定根URLconf。系统从根URLconf开始逐条匹配，直至找到匹配项，这回答了第一个问题，后续将对此进行详细剖析。

在示例中，可以看到三个核心方法：patterns、url和include。其中，url方法用于构建URL到View的映射对象；patterns方法将这些映射对象组织成Python列表；而include方法则是“树”状结构的关键连接者，用于将其他URLconf关联到当前URLconf（即子节点）。整个URL Dispatcher体系由这三个方法构建，下文将重点解析这三个方法，理清后整个映射机制便一目了然。

def patterns(prefix, *args):
  pass
def url(regex, view, kwargs=None, name=None, prefix=''):
  pass
def include(arg, namespace=None, app_name=None):
  pass

url()函数解析

首先分析最核心的url()函数。其第一个参数regex为URL的正则表达式，第二个参数指定对应的View。此外，可通过kwargs参数为View指定默认的关键字参数，通过name参数为URL命名（主要用于URL反解），而prefix参数作用较小，此处略过。

url()函数最终构造出一个对象，可称为URL映射对象。当首次访问该对象以匹配URL时，它会将正则表达式编译一次并缓存于对象中，后续匹配将直接使用缓存，从而避免重复编译，提升效率。正则匹配底层依赖Python的re模块，大致流程如下：

# 第一次访问时，编译，然后保存在url对象中
regex = re.compile(regex_str, re.UNICODE)
# 每次URL访问时，进行正则匹配
match = regex.search(path)
kwargs = match.groupdict()
args = match.groups()

此处涉及前述第二个问题：URL参数的获取与传递机制。Django通过re模块中的命名组（named groups）和非命名组（non-named groups）概念来获取参数。match.groupdict()返回命名组，即一个字典，其键为URL中指定的名称，该字典作为kwargs参数传递给View；match.groups()返回非命名组，即元组（tuple），作为args参数传递给View。需要注意的是，args和kwargs不能同时存在：若kwargs非空，args将被置空；若kwargs为空，则使用args。此外，传递给View的kwargs仅包含url()中指定的默认kwargs。换言之，若URL使用了命名组，非命名组将被忽略；若仅使用非命名组，则作为args传递。

接下来解析前述示例，假设存在如下URL与View定义：

URL定义：

url(r'^articles/(\d{4})/$', 'news.views.year_archive')
url(r'^articles/(?P<year>\d{4})/(?P<month>\d{2})/$', 'news.views.month_archive')

View定义：

def year_archive(request, *args, **kwargs):
  pass
def month_archive(request, *args, **kwargs):
  pass

当访问“articles/2014/”路径时，解析过程如下：

>>> import re
>>> regex = re.compile(r'^articles/(\d{4})/$', re.UNICODE)
>>> match = regex.search("articles/2014/")
>>> match.groupdict()
{}
>>> match.groups()
('2014',)

因此，最终传递给year_archive()方法的参数如下：

(Pdb) pp args
(u'2014',)
(Pdb) pp kwargs
{}

当访问“articles/2014/11”路径时，解析过程如下：

>>> import re
>>> regex = re.compile(r'^articles/(?P<year>\d{4})/(?P<month>\d{2})/$', re.UNICODE)
>>> match = regex.search("articles/2014/11/")
>>> match.groupdict()
{'year': '2014', 'month': '11'}
>>> match.groups()
('2014', '11')

因此，最终传递给month_archive()方法的参数如下：

(Pdb) pp args
()
(Pdb) pp kwargs
{'month': u'11', 'year': u'2014'}

补充说明，url()可指定kwargs参数，作为关联View的默认kwargs。若url()中指定了kwargs，其内容将合并传递至View方法的kwargs中。

至此，url()函数及第二个问题（参数传递）已清晰。至于name参数，将在后续URL反解部分详细解释。

patterns()函数解析

接下来分析patterns()函数，其功能较为简单，即返回由url()构造的URL映射对象组成的列表。该函数有一个必填参数prefix，用于指定所包含View的公共前缀，旨在避免代码重复。例如：

urlpatterns = patterns('',
  url(r'^articles/(\d{4})/$', 'news.views.year_archive'),
  url(r'^articles/(\d{4})/(\d{2})/$', 'news.views.month_archive'),
  url(r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),
)

可简化为：

urlpatterns = patterns('news.views',
  url(r'^articles/(\d{4})/$', 'year_archive'),
  url(r'^articles/(\d{4})/(\d{2})/$', 'month_archive'),
  url(r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'article_detail'),
)

需注意，由patterns()生成的列表必须赋值给urlpatterns变量，这是Django的约定。默认情况下，Django会在URLconf中查找该变量。虽然可通过配置更改此变量名，但通常不建议修改。

在Django 2.0版本中，该函数将被弃用，转而直接赋值给urlpatterns一个列表，此处不再赘述。

include()函数解析

include()是本文的难点，尤其在URL反解部分，Django官方文档表述不够清晰，且逻辑关系复杂，必须通过实际测试才能透彻理解。

如前所述，include()是“树”状结构的连接者，用于将其他URLconf关联到当前URLconf，使Django的URL设计更加灵活简洁。include()包含三个参数：第一个参数指定要包含的其他URLconf路径；关键在于后两个参数namespace和app_name。这两个参数与url()中的name参数共同构成了Django的URL命名空间，主要用于URL反解。什么是URL反解？即已知请求URL找到对应View的反向过程：在View或Template中，根据传递的参数解析出对应的URL。为何需要URL反解？为避免硬编码路径，便于后期维护。若将路径写死在HTML中，修改将极为麻烦。因此，通常将可变部分放入变量，程序中引用变量名，这是编程常识。因此，URL“树”既支持从上到下的解析，也支持从下到上的反解。

在Template中进行反解使用{%url%}标签，在View中进行反解则使用django.core.urlresolvers.reverse()方法。

首先看一个最简单的示例：

mydjango/urls.py：

urlpatterns = patterns('',
  url(r'model/', include('model_test.urls')),
)

model_test/urls.py：

urlpatterns = patterns('',
  url(r'^$', views.index, name='index'),
)

mydjango/urls.py为根URLconf，包含model_test的URLconf。model_test中的urlpatterns包含一个名为index的URL映射对象。

若想在Template中获取该View对应的真实URL路径，可使用Template的url标签：

{% url 'index' %}

结果即为：/model/。

同理，若在View方法中，则使用reverse()方法：

from django.core.urlresolvers import reverse
reverse("index")

结果同样为：/model/。

此例仅使用了url()中的name参数，未涉及命名空间。因情况简单，无混淆，无需使用命名空间。使用命名空间主要适用于以下两种情况：

项目中存在多个应用，且各应用定义的URL映射对象name可能重复，导致反解时Django无法确定具体应用。

项目中同一应用被部署多个实例，这些实例共享定义的name URL，反解时无法确定具体实例。

第一种情况较易解决，只需在应用的include()中指定不同的namespace参数即可，例如：

mydjango/urls.py：

urlpatterns = patterns('',
  url(r'model/', include('model_test.urls', namespace='model')),
)

此时，在Template或reverse中，需在name前加上namespace进行反解：

{% 'model:index' %}
or 
reverse("model:index")

即可准确反解至model_test应用。

第二种情况，“同一应用被部署多个实例”指：

urlpatterns = patterns('',
  url(r'model1/', include('model_test.urls')),
  url(r'model2/', include('model_test.urls')),
)

不同路径下引用同一应用，即同一应用被实例化两次。如何区分？虽可在include中指定不同namespace解决，但不推荐。因为引用同一应用意味着代码相同，在同一份代码中通过if/else判断反解至哪个namespace，违背Django的DRY（Don't Repeat Yourself）原则，极不优雅。

Django通过app_name + namespace + current_app机制解决此问题。namespace和app_name分别为include()的第二个和第三个参数。app_name指定应用名称，namespace指定该应用某实例的URL命名空间，current_app则根据请求路径解析出该URL的命名空间（即namespace）。反解时，动态将current_app传递给反解函数，函数据此确定反解至哪个实例。同一应用的多个实例app_name应相同，namespace应不同。可能略显复杂，举例说明：

mydjango/urls.py：

urlpatterns = patterns('',
  url(r'model1/', include('model_test.urls', namespace='model_1', app_name="app")),
  url(r'model2/', include('model_test.urls', namespace='model_2', app_name="app")),
)

model_test/urls.py：

urlpatterns = patterns('',
  url(r'^$', views.index, name='index'),
)

model_test/views.py：

from django.shortcuts import render
from django.core.urlresolvers import reverse

def index(request):
  current_app = request.resolver_match.namespace
  print reverse("app:index", current_app=current_app)
  return render(request, 'model/index.html', current_app=current_app)

model_test/templates/model/index.html：

{% url 'app:index' %}

在View中，首先获取当前namespace，并通过current_app传递给reverse()，reverse即可知应解析至哪个实例。同理，Template中也需传递current_app。如此即可动态反解URL：

当请求路径为/model1/时，current_app为model_1，结合app_name，准确反解URL为：/model1/。 若请求路径为/model2/，则current_app为model_2，反解路径为/model2/。

虽然情况复杂，但使用频率较低。经长时间搜索才大致理清，理解或有偏差，待后续实践检验。当前关键在于理解该机制的思想。

全文完，更多详细内容请参阅Django官方文档：https://docs.djangoproject.com/en/1.6/topics/http/urls/

总结

本文全面解析了Python探索之URL Dispatcher实例详解，希望有所帮助。感兴趣的朋友可继续参阅本站：Python探索之Metaclass初步了解、Python编程之Re模块下的函数介绍等。如有不足之处，欢迎留言指出。感谢朋友们对本站的支持。