自动多模块路由不加载中间件，因其绕过route/app.php直接解析URL并PSR-4加载，需为模块单独配置app/{module}/middleware.php和app/{module}/route/{module}.php并显式绑定中间件。
自动多模块路由不加载中间件，是因为它根本不走 route/app.php
ThinkPHP 的「自动多模块路由」（即未显式定义、靠 URL 自动解析模块名的模式）不会触发 route/app.php 中的任何路由注册逻辑，自然也不会执行你在该文件里写的 ->middleware() 链式调用。它绕过了你手动配置的路由层，直接根据 URL 拆解出模块/控制器/方法，再靠 PSR-4 自动加载类——中间件链在此完全缺席。
常见错误现象：http://site.com/admin/user/index 能访问，但 AuthCheck 中间件完全没执行；app/middleware.php 里明明注册了，route/app.php 也绑了，就是不生效。
- 自动模块路由只依赖 URL 解析 + 命名空间映射 + PSR-4 加载，不经过路由定义文件
- 它默认不读取
route/app.php，也不识别其中的middleware()调用 - 如果你启用了多应用模式（如
app/multi_app），模块级中间件必须放在对应应用目录下，比如app/admin/middleware.php，全局的app/middleware.php对其无效
想让 admin 模块自动路由走中间件，必须显式绑定到模块自己的路由文件
不是改配置、不是加钩子，而是把模块当“独立小应用”来对待：每个模块要有自己的路由入口，并在其中显式声明中间件。TP6+ 支持按模块组织路由文件，路径是 app/{module}/route/{module}.php（如 app/admin/route/admin.php），框架会在请求命中该模块时自动加载它。
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 确保模块路由文件存在且被正确命名，例如
app/admin/route/admin.php - 在该文件中用
Route::group()包裹所有模块内路由，并链式调用->middleware('auth') - 中间件别名（如
'auth'）必须已在该模块的app/admin/middleware.php中注册，不能复用全局配置 - 别在
route/app.php里写Route::group('admin', ...)并指望它覆盖自动路由——它只对显式定义的路由有效
中间件注册位置错，模块路由就永远找不到它
多模块场景下，app/middleware.php 是全局中间件入口，仅对根应用（main app）生效；每个模块若要拥有专属中间件，必须在模块目录下单独提供 middleware.php 文件，并返回数组。框架会按请求所属模块，优先加载对应路径下的这个文件。
立即学习“PHP免费学习笔记（深入）”；
- 模块中间件注册文件路径必须是
app/{module}/middleware.php，不能是app/middleware/{module}.php - 该文件必须返回一个数组，例如：
return [\app\admin\middleware\AuthCheck::class]; - 命名空间必须与路径严格匹配：模块目录
app/admin→ 类命名空间app\admin\middleware - 如果模块目录下没有
middleware.php，即使类文件存在、app/middleware.php里写了该类，模块路由也不会加载它
别用 bind() 或 domain() 混合路由分组来“曲线救国”
有人试图用 Route::bind('admin', 'app\admin\controller')->group('admin', ...)->middleware('auth') 来兜底自动路由，这行不通。因为 bind() 只影响变量路由（如 :id）的类型约束和默认值，它不接管模块名解析，也不改变路由匹配顺序。此时 ->middleware() 实际绑定到了 bind() 配置上，而非路由分组，属于无效挂载。
-
bind()和group()是两个互不感知的机制，禁止链式混用 - 自动模块路由的解析发生在路由调度早期，远早于
bind()的介入时机 - 真正可控的切入点只有模块专属路由文件（
app/{module}/route/*.php）和模块专属中间件注册文件（app/{module}/middleware.php）
