当你开始对 URL 的“精度”提出要求时，普通的 path() 就不够用了。
如果只是匹配整数、字符串，转换器已经足够。但当需求变成：
- 只能匹配一到两位数
- 必须严格区分日期顺序
- 必须精确控制匹配边界
这时，Django 提供的真正利器是：
re_path
这篇文章，我们系统讲清楚：
- 为什么普通 path 不够用
- re_path 的匹配原理
- 如何用命名分组传参
- 两个完整实战案例
- 使用 re_path 时的工程注意事项
目录
- 为什么普通 path 不够精准
- re_path 的本质与参数结构
- 正则命名分组与关键字传参机制
- 实战一：限制一到两位数运算
- re_path 与普通 path 的匹配顺序关系
- 实战二：生日日期双格式匹配
- re_path 使用场景与工程边界
1. 为什么普通 path 不够精准
我们之前用 path 和转换器实现了一个小计算器：
/10/add/5/
路由写法：
path("<int:a>/<str:op>/<int:b>/", views.cal_view)
问题来了。
如果现在需求变成：
只允许一到两位数，三位数及以上不允许。
int 转换器只能判断“是否是整数”，但无法控制位数。
也就是说：
/100/add/5/
依然会被匹配。
此时，普通 path 转换器已经无法满足精度要求。
2. re_path 的本质与参数结构
使用方式：
from django.urls import path, re_path
re_path 与 path 在源码中是平级存在的。
结构：
re_path(regex, view, name=None)
区别在于：
- 第一个参数是正则表达式
- 必须使用命名分组
- 匹配成功后按关键字传参
3. 正则命名分组与关键字传参机制
Django 要求使用：
(?P<变量名>正则规则)
示例：
(?P<x>\d{1,2})
含义：
- 命名分组 x
- 匹配 1 到 2 位数字
匹配成功后：
Django 会把 x 作为关键字参数传入视图函数。
视图函数必须写成：
def view(request, x):
变量名必须一致。
4. 实战一：限制一到两位数运算
目标：
- 只允许一到两位数
- 操作符必须是字母
- 格式必须严格匹配
路由配置
re_path(
r"^(?P<x>\d{1,2})/(?P<op>[a-zA-Z]+)/(?P<y>\d{1,2})/$",
views.cal2_view
)
关键点：
- 使用原始字符串 r""
- ^ 表示必须从开头匹配
- $ 表示必须匹配到结尾
- \d{1,2} 限制位数
- 使用命名分组
视图函数
def cal2_view(request, x, op, y):
return HttpResponse(f"x={x}, op={op}, y={y}")
测试：
/10/add/5/ → 匹配
/9/sub/2/ → 匹配
/100/add/5/ → 不匹配
三位数不会进入该路由。
这就是精准匹配的价值。
5. re_path 与普通 path 的匹配顺序关系
Django 依然遵循：
自上而下匹配规则
因此：
urlpatterns = [
re_path(...),
path(...),
]
当访问三位数时：
- re_path 不匹配
- 自动进入普通 path
这是一种典型的“精确优先，宽松兜底”的结构。
实际项目中，这种组合是非常常见的设计方式。
6. 实战二：生日日期双格式匹配
需求：
支持两种格式：
/birthday/2023/7/15/→ 年月日/birthday/7/15/2023/→ 月日年
普通 path 转换器无法区分：
因为都是 int。
只能在视图里做逻辑判断，但这属于“后置修补”，不是优雅设计。
第一种格式
re_path(
r"^birthday/(?P<y>\d{4})/(?P<m>\d{1,2})/(?P<d>\d{1,2})/$",
views.birthday
)
第二种格式
re_path(
r"^birthday/(?P<m>\d{1,2})/(?P<d>\d{1,2})/(?P<y>\d{4})/$",
views.birthday
)
两个路由都指向同一个视图函数。
视图函数
def birthday(request, y, m, d):
return HttpResponse(f"生日为 {y}-{m}-{d}")
测试：
/birthday/2023/7/15/
/birthday/7/15/2023/
都能正确解析。
这是 path 转换器无法实现的精准区分。
7. re_path 使用场景与工程边界
什么时候必须用 re_path？
- 位数限制
- 严格格式校验
- 多种顺序结构区分
- 特殊字符规则控制
什么时候不建议用？
- 规则简单时
- 只需要类型匹配时
- 项目成员不熟悉正则时
因为：
正则一旦写复杂，可读性会下降。
工程设计的原则是：
能用 path 解决就别上正则 需要精准规则时再使用 re_path
总体能力沉淀
这一节真正掌握的不是“会写正则”，而是理解：
- Django 路由匹配的两种层级工具
- path 是结构化匹配
- re_path 是正则级精准匹配
- 命名分组是参数传递核心
- 匹配顺序决定执行路径
从工程角度看：
path 是常规武器 re_path 是狙击步枪
当业务规则变得严丝合缝时，re_path 才能让路由真正“严丝合缝”。
理解这一层，你的 Django 路由体系就已经进入可控状态。
关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。
学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。
我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。
在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。
同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。
