✨ single-spa:
-  js-entry 
 通过es-module 或 umd 动态插入 js 脚本 ,在主应用中发送请求,来获取子应用的包,
 该子应用的包singleSpa.registerApplication({ name: 'app1', app: () => import('http://localhost:8080/app1.js'), activeWhen: '/app1' });主应用直接执行 app: () => import('http://localhost:8080/app1.js')该脚本,拿到子应用包。该包中暴露了主应用规定的那几个生命周期函数,
🎨 qiankun:
1. html-entry
qiankun 库的核心插件
 
import-html-entry 是 qiankun 实现 HTML Entry 模式的关键工具,具体功能包括:
- 请求并解析 HTML 文件
 从 HTML 中提取所有<script>和<link>标签的资源路径(包括外链和内联脚本)。
- 资源分类与处理
 将资源分为 JS、CSS 和 入口脚本,并处理资源路径(如相对路径转绝对路径)。
- 生成加载队列
 根据资源类型和依赖关系生成加载队列,确保资源按正确顺序加载。
- 执行入口脚本并获取生命周期
 import-html-entry通过劫持全局变量或模块系统,获取子应用导出的生命周期方法。
- 执行环境隔离
 提供沙箱机制(如 Proxy),隔离子应用的 JS 执行环境。
  
2. js沙箱
防止js全局污染
 当在主应用环境中,开始加载子应用的 JS 文件(或内联脚本)时
 qiankun 会通过 es6 Proxy 为该子应用创建一个 代理的window,
	// 创建一个虚拟的全局对象
    const fakeWindow = {};
    // 保存子应用对全局变量的修改
    this.modifiedProps = new Map();
    
// 代理 window 对象
this.proxy = new Proxy(fakeWindow, {
      get: (target, prop) => {
        // 优先从子应用的修改中读取,否则从真实的 window 读取
        return this.modifiedProps.has(prop) 
          ? this.modifiedProps.get(prop)
          : window[prop];
      },
      set: (target, prop, value) => {
        // 所有对 window 的修改记录到 modifiedProps,不影响真实 window
        this.modifiedProps.set(prop, value);
        return true;
      },
- 读操作:子应用读取 window.xxx 时,优先从 modifiedProps 中获取子应用自己修改的值;若未修改,则从真实 window 读取。
- 写操作:子应用修改 window.xxx 时,值被记录到 modifiedProps,不会影响真实 window。
3. 样式隔离
-  严格样式隔离(Shadow DOM):==创建一个封闭的 DOM 树,外部样式无法影响内部,内部样式也不会泄漏到外部。 
  - 配置方式:
 
 什么是Shadow DOM?是 Web Components 技术中的一部分start({ sandbox: { strictStyleIsolation: true, // 启用 Shadow DOM }, })
 传统 DOM 是全局可见的,而 Shadow DOM 允许在组件内部创建一个私有的 DOM 子树,独立于主文档树。外部样式和脚本无法直接访问 Shadow DOM 内部的内容。
通过 element.attachShadow({ mode }) 方法创建:
const host = document.createElement('div');
// mode 可选 'open' 或 'closed'
// 是否允许外部通过 host.shadowRoot 访问 Shadow DOM。
const shadow = host.attachShadow({ mode: 'open' }); 
shadow.innerHTML = `
  <style>button { background: black; }</style>
  <button>Shadow DOM 按钮</button>
`;
// 添加到页面后,按钮的样式不会受外部 CSS 影响
- 优点:完全隔离,最严格的样式保护。
- 缺点:
 兼容性问题(部分旧浏览器不支持)。
 子应用需适配 Shadow DOM 环境(如事件冒泡路径变化)
-  动态样式隔离(Scoped CSS) 
 为子应用的 CSS 选择器添加唯一前缀,限制其作用域。- 配置方式:
 start({ sandbox: { experimentalStyleIsolation: true, // 启用动态作用域 }, })原理: 
 子应用的根容器会被自动添加唯一属性(如 data-qiankun=“childApp”):<div data-qiankun="childApp"> <!-- 子应用 DOM --> <button class="button">Submit</button> </div>子应用的所有 CSS选择器(如 .button)添加上具有唯一属性: .button { background: red; } /* 重写后 */ [data-qiankun="childApp"] .button { background: red; }
- 优点:无需破坏子应用原有逻辑,兼容性好。
- 缺点:
 无法处理全局样式(如 body 或 html 的样式)。
 CSS-in-JS 或动态生成的样式可能需要额外处理。
如果子应用使用了 CSS-in-JS、内联样式或第三方 UI 库,可以结合以下方式彻底避免冲突:
- 子应用使用 CSS Modules 自动生成唯一的类名:
// 子应用组件
import styles from './App.module.css';
function App() {
  return <div className={styles.title}>Child App</div>;
}
- CSS-in-JS
 通过 Styled-components 或 Emotion 生成作用域样式:
const Title = styled.div`
  color: red;
`;
// 生成唯一的 class 名称(如 .css-1x2y3)
- UI 库前缀
 修改第三方 UI 库的类名前缀(如 Ant Design):// 子应用中修改 less 变量 @ant-prefix: 'custom-prefix';
4. 路由(基于single-spa)
single-spa 对原生浏览器路由 做了以下事情;
-  监听的路由事件: hashchange 和 popstate hashchange 和 popstate 是唯一原生支持无刷新路由的事件。 
 单页应用(SPA)和微前端架构中的路由切换 依靠这两个api具体来说,监听这两个事件有以下几个关键目的: - 拦截路由变化 :
 当用户在浏览器中导航(如点击前进/后退按钮、修改 URL hash、或通过 History API 进行导航)时,single-spa 需要知道这些变化,以便决定哪些微前端应用需要被加载、挂载或卸载。
- 控制事件触发顺序 :
 通过捕获这些事件的监听器,single-spa 可以确保在完成应用的挂载/卸载操作后,才将这些事件传递给各个微前端应用,避免应用在不适当的时机接收到路由事件。
- 协调多个应用 :
 当路由变化时,可能需要卸载一些应用并挂载其他应用。通过监听这些事件,single-spa 可以协调这个过程,确保应用之间的平滑切换。
- 统一的路由处理机制 :
 无论是 hash 路由还是 history 路由,single-spa 都能通过监听这两个事件来处理,为不同类型的路由提供统一的处理机制。
 
- 拦截路由变化 :
-  修补 History API 
 具体来说,修补 History API 有以下几个关键目的:- 修补 pushState 或 replaceState 方法
 这两个方法修改了URL,默认不触发 popstate,通过修补这些方法,single-spa 可以在它们被调用后手动触发一个人工的 popstate 事件,确保所有应用都能感知到路由变化。
 
- 修补 pushState 或 replaceState 方法
总的来说
- 完善原生 URL的路由响应机制
- 协调 子应用在不同URL间的挂载卸载
5. publicPath
静态文件在浏览器中被请求时的基础 URL 路径。
 eg:
module.exports = {
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'), // 与服务器无关,仅决定本地输出位置。
    publicPath: '/assets/', // 浏览器访问路径 需在前面加上 /assets
  },
};
若部署在服务器根目录,访问资源时会请求:http://xxx.com/assets/bundle.js。
在微应用中:
 当子应用被主应用加载时,其资源路径可能相对于主应用的 URL,而非子应用的真实部署路径。
- 示例:子应用部署在 http://child.com/sub-app/,但主应用在 http://main.com/ 加载子应用,此时子应用的 JS/CSS 可能错误地从 http://main.com/js/app.js 加载(404 错误)。
通过配置 publicPath,子应用可以区分当前是独立运行还是被主应用加载,动态修正资源路径。
⚠️ 且需要与子应用路由配置的协同:
问题场景:
 如果子应用不配置路由的 basename(基础路径),当主应用通过 /sub-app 加载子应用时,
 子应用的路由会直接拼接在 请求地址的根路径(/)下,导致路径匹配丢失。例如:
- 主应用匹配子应用路径:http://main.com/sub-app
- 子应用内部路由:/user/list
- 访问子应用实际路径:http://main.com/user/list(错误,跳出了主应用的上下文)
- 预期路径:http://main.com/sub-app/user/list(正确)
总结:为什么必须协同?
 静态资源路径(publicPath)和 路由路径(basename)共同决定了子应用的完整上下文:
- publicPath 解决资源从哪里加载。
- basename 解决路由在哪里生效。
两者缺一不可,否则会导致:
- 资源加载成功,但页面渲染错位。
- 路由跳转正确,但资源加载失败。



















