技术选型：vue3.6+vite6+pinia+js+iframe
- 选择vite6主要是因为希望能有更快的打包构建速度，相对于webpack的优点已经在另一篇文章里面说明了，之所以选择这个版本，主要是@vitejs/plugin-basic-ssl需要保底vite6+vue3.6
@vitejs/plugin-basic-ssl是 Vite 生态中简化本地 HTTPS 开发的核心插件，核心价值是 “零配置快速启用 HTTPS，无需手动管理证书”。该插件专为 Vite 本地开发设计，自动生成自签名 SSL 证书，一键启用 HTTPS 服务，解决本地开发中 “HTTP 环境不兼容 HTTPS 接口、浏览器安全特性限制” 等问题。
主要是因为系统管理主页面使用的是https，如果iframe微前端使用http，整个项目无法启动，微前端必须保证整个项目使用同一套协议，但是本地开发一般走的都是http环境，所以希望实现接口https，但是实际是http的状态。
- 选择pinia的主要原因在于一方面现在vue生态环境已经全面投入到pinia，不再更新vuex了，另外还有一个重要的原因是现在的pinia的编写方式更加像一个对象。可以实现类似于单例模式的框架设计，将单个菜单/业务看作为一整个对象，我们更改该菜单/业务看作更改该对象的属性，一切的数据流向都是由pinia对象流向实际菜单/业务内部的实体。
虽然后续没有遇到一个合适的场景复刻我记忆中前司react的"prefetch"概念（至于为什么是记忆中，因为呆的时间很短，那时候基础也很薄弱，并没有深刻思索"prefetch"这个概念最开始是由什么数据控制节点开启的）
大致是说将整个页面（指单页面应用）看作一个object，页面与页面之间的链接，则可以看作A->object->B，如果出现了一种特殊的object页面，他要被打开必须通过A页面，而且经过A页面一定会流向object页面（比如首屏广告页，后面一定是衔接首页），那么就会出现一种可以应用"prefetch"这个概念的case，也就是A页面打开的时候直接通知object页向后端拉取数据，放到pinia仓库对象中，实际到达object页面的时候就可以直接快速打开，省去了接口加载耗时。
配置vite.config.js
最基础的配置：
- server的代理域名，用于处理跨域问题
- plugin: basicSsl 用于处理本地对应的https的问题
- resolve文件简写重定向，比如src，比如通用仓库
- 打包输出文件夹
- optimization不打包部分文件（console.log等）
- 没配置splitchunk，因为感觉vite已经实现了splitchunk
安装必须的包，配置main.js，改造App.vue
router，组件库，axios等等，想起哪个安哪个
在main.js里面引用一下
配置全局css+tailwindcss
css没啥说的，我直接copy大法/ai大法，如果有现有已经成熟的config可以直接搬过来，没必要自己写
配置router，编写layout布局
- router的需要跳转的页面路由
- 路由跳转的router.beforeeach和aftereach一般都按照最低能起项目来配置，后续遇到什么问题再加
- 布局业务栏和导航栏以及我们平台的租户群组组件以及实际路由跳转展示页面
配置iframe主系统的消息接收处理文件
主要处理两种场景：
- iframe已经实例化，通知系统管理
- iframe接收到系统管理处理之后链接，已经顺利拼接主系统的路由导航参数
记得引入到App.vue，全局监听
配置axios接口通信
- 请求拦截器针对请求进行config的信息处理，增加某些系统级别的接口必传参数
- 开启abortController，对重复请求进行控制，避免请求多次触发
- 响应拦截器针对部分通用错误进行拦截，比如权限问题
配置pinia仓库
主要分为两种，一个是业务页面分属自己的仓库，一个是系统级别单仓库，个人倾向于一整个业务看成一整个仓库
