Umi Max 中如何基于服务端菜单响应实现运行时动态路由？

[Unique-work]

我们当前项目使用 Umi Max 4 + React 18，想在保留 Umi 路由体系的前提下，实现“服务端菜单驱动前端动态路由”。
当前需求和约束如下：
不希望完全放弃 Umi 路由系统，也不想改成原生 React Router。
登录后或页面刷新时，请求服务端当前用户菜单。
服务端菜单返回 path、componentKey、componentPath 等字段。
前端根据菜单响应动态生成业务路由。
基础静态路由仍保留，例如：/login
/
/home
/404
/*

动态业务路由来自服务端菜单，例如：/system/user
/system/role
/system/menu
/monitor/online

前端不能直接信任服务端返回的任意组件路径，需要通过 import.meta.glob('@/pages/**/*.tsx') 做白名单匹配。
希望配合 Umi runtime hooks 使用：render
patchClientRoutes
onRouteChange

当前思路是：在 render(oldRender) 中先根据 token 请求服务端菜单
菜单写入 Zustand store
根据菜单构建动态路由
再调用 oldRender()
在 patchClientRoutes 中把动态路由插入到 Umi 客户端路由中，并放在 /* 之前

目前想确认几个问题：
Umi Max 4 中，render 里异步请求菜单，然后通过模块级变量传给 patchClientRoutes，是否是推荐或可接受的方案？
patchClientRoutes 是否适合用来注入服务端菜单生成的业务路由？
对于服务端返回的 componentPath，使用 import.meta.glob 做白名单解析是否是合适的安全方案？
动态路由应该替换同 path 的静态占位路由，还是应该彻底移除配置里的业务静态路由？
如果用户权限变化或菜单变化，Umi 是否支持在不刷新页面的情况下重新 patch 路由？还是推荐重新加载应用？
在 Umi Max 4 中，动态路由对象更推荐使用 element，还是仍然应该维护 routeComponents 映射？
如果 catch-all /* 已存在，动态路由插入到它之前是否有潜在问题？
希望了解 Umi 官方推荐的运行时动态路由实践，尤其是“服务端菜单 + 前端组件白名单 + Umi runtime hooks”的组合方式是否合理。