有想法，可以随时评论，感谢大家
思考：
中后台页面如何
-
精致开发？
-
可以吹牛皮：我们团队做的 & 我做的，好东西，经历考验的，用过的都说好！
-
标准 & 规范？
-
体验好？
-
交互佳？
-
可推广？
-
-
快速交付？
-
沉淀？
-
复用？
-
让团队有影响力？
-
让个人有成长？
-
让做的东西成为技术产品？
页面物料开发 + 消费思路
大概思路：
页面通过umd下发，动态下发&加载页面（这个和让晨宝上周做的umd技术分享也有一定的关系，算是给团队的小伙伴们进行了一次客服扫盲，铺垫了些基础），然后各大页面就可以和项目解耦了，独立发布
本地开发的时候，可以通过一个运行环境，注入相关内容，比如：sso、用户信息、权限等
-
-
之前和 小伙伴 聊过，一些通用外呼sdk，可以采用 umd 的格式来下发，然后有一个后台来管理各大后台消费sdk的版本（管理 页面umd 资源信息，比如 版本号、维护人等）
- ❎ 缺一个 umd + 业务页面 管理后台？
-
-
-
换个角度理解，我们将页面视作一个组件，按照物料方式进行开发，将其视作一个组件，发布为 umd 格式的组件（最后发布到cdn上）
- ❎页面开发脚手架 ？
-
-
- 工程项目通过 yarn add 进行安装，不过通过yarn add 会带来整体发布成本过高的问题
-
-
更适合的方式：主工程 加载对应页面 对应的 umd文件，然后挂载渲染即可 => umd 发布为 cdn，以保证稳定性
- ❎npm 包 + 物料 发布至 cdn ？
-
-
- 业务同学来开发页面级别组件你，作为 umd 即可
-
-
物料也算有了沉淀，正向循环
-
沉淀大前端页面级别模板
-
❎VS Code 插件，快速集成该页面模板
-
-
工程项目消费页面模板
- ❎公司脚手架项目 如何快速消费 ？ - ❎ umi 消费页面模板？
可以一起思考下，大概方向是：
页面通过umd下发，动态下发&加载页面（这个和组内小伙伴上周做的umd技术分享也有一定的关系，算是铺垫了些基础），然后各大页面就可以和项目解耦了，独立发布
本地开发的时候，可以通过一个运行环境，注入相关内容，比如：sso、用户信息、权限等
脑洞（微前端架构演进）
-
主工程，通过 loadPageUmdScript 来加载对应的时候，需要知道哪些信息？
-
A路径 要加载哪个 umd 资源？即要有一个 path 和 umd 的关系映射表
-
挂载到某个DOM节点？或者不需要挂载，应该有一个默认挂载点
-
各个umd之间进行隔离？？（简单点就不需要，复杂的需要考虑）
-
但好像各大业务工程目前其实没考虑 哈哈哈哈
-
按照上面的思路，其实你会发现，我们在做的东西，其实就是一个mini 微前端框架
-
-
我们上面讨论的内容，大部分还是理想主义，为何这样说？
-
我们上面在讨论的内容，你会发现，我们潜意识里认为一个需求是一个简单的 crud 页面
-
但是事实却不是如此，一个页面很有可能是多个页面组合而成的：最简单的就是列表 & 详情页
-
而列表 + 详情页 是需要两个path/路径的对吧
-
那么最上面大部分请求单文件 umd 的很多技术思考 + 架构都过于单薄，为何这样说？继续看下面
-
以 列表 + 详情页 为例，实际开发业务需求，一般是要有页面的路由跳转的
-
小需求的页面，要有独立的路由模式（不过这时候，也会倒逼我们思考🤔 jquery时代，有vue-router 吗？没有的话，怎么解决页面之间跳转的？独立页面，独立开发？独立发布？其实也就是传说中的各自开发各自的，多Tab打开而已吧）
-
这时候，你会发现，你可能真正需要去了解现代前端路由框架的实现原理
-
在我们的小需求umd（或者称为子应用吧）被引入到业务项目中的时候，在子应用路由跳转的时候，可以看一下实际跳转是效果是怎么样的？
-
如果没有猜错，子应用的路由跳转，因为没有和主项目有任何沟通，所以url估计#会进行变化下，但是刷新之后的，主应用如何知道这时候要去加载子应用hash的对应的哪个页面呢？这时候，就需要了解主应用如何对子应用进行路由拦截了
-
-
-
说了这么多，其实你会发现，上面说的其实就是一个微前端框架要做的事情，😮哈哈
-
现在应该能理解，为何会有微前端，以及微前端能带来啥了吧（某种意义上，它是基础建设的一个必要基石）
-
其实没怎么看过市面上微前端的核心思想 + 架构，算是自己结合在公司的中后台开发实际 + 想做的提效内容，一点点想法和思考，如果有不对的地方，欢迎大家拍板斧正
-
