应使用include()分层管理路由。在各应用下建urls.py并设app_name，主urls.py用path('prefix/', include('app.urls', namespace='app'))引入；子路由勿用^$锚点，urlpatterns须为列表而非函数。
为什么直接在主urls.py里写所有路由会出问题
路由堆在urls.py里超过 50 行，就会开始出现几个实际困扰：改一个路径要翻半天、团队协作时频繁冲突、新成员看不懂哪个 URL 属于哪个功能模块。Django 的 include() 不是“可选技巧”，而是应对真实项目规模的必要分层手段。
怎么用include()把路由拆到各应用里
核心就两步：在每个应用下新建 urls.py，再在主 urls.py 中用 include() 引入。注意不是 import 模块，而是传路径字符串给 include()。
常见错误现象：NoReverseMatch 或 404 —— 多半是忘了在子 urls.py 里加 app_name，或者 include() 时没带命名空间。
- 每个应用的
urls.py开头必须定义app_name = 'blog'（值要和应用名一致） - 主
urls.py中写path('blog/', include('blog.urls', namespace='blog')) -
include()第二个参数namespace必须显式传，否则{% url 'post_detail' %}这类模板调用会失败 - 子路由里的
path()不需要重复写前缀，比如blog/已由主路由定义，子路由只写path('posts/<pk>/', ...)</pk>
include() 的参数陷阱和兼容性细节
Django 2.0+ 要求子 urls.py 返回一个 urlpatterns 列表，且必须是模块级变量；老版本允许返回函数，现在会报 TypeError: 'function' object is not iterable。
另一个易忽略点：如果子路由用了 re_path() 或正则捕获组，而主路由又套了一层 path() 前缀（比如 path('api/v1/', include(...))），那正则中的 ^ 和 $ 会导致匹配失败——因为 include() 会把前缀拼进完整路径，正则应去掉行首行尾锚点。
- 子
urls.py必须有urlpatterns = [...]，不能只写函数 - 避免在子路由中用
^和$，除非你明确在做全路径匹配 -
include()支持传入kwargs，可用于向所有子视图注入公共参数（如company_id），但慎用——会增加调试难度
什么时候不该用include()拆分
单应用小项目（比如只有 home 和 contact 两个页面）、原型验证阶段、或路由逻辑高度耦合（比如多个应用共用同一组动态前缀），硬拆反而增加跳转层级和维护成本。
更隐蔽的问题是过度拆分：为每个模型建一个应用，每个应用再配一套 urls.py，结果导致 include('user_profile.urls')、include('user_settings.urls')、include('user_api.urls') 并列存在——这其实暴露的是领域建模问题，不是路由问题。
真正该警惕的信号是：你开始给 include() 写嵌套三层以上，或者在模板里频繁写 {% url 'user_profile:settings:api:save' %} 这种长命名空间。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
