微前端中dom事件需主动设计分发路径和作用域边界，子应用必须限定在自有容器内监听事件，禁用全局绑定；跨应用通信应通过框架机制而非原生dom事件流；全局事件由主应用统一收口并按需分发；shadow dom下需显式设置composed:true才能穿透边界。
微前端中 DOM 事件不能靠“自动隔离”，必须主动设计分发路径和作用域边界。子应用若直接绑定 window 或 document 上的全局事件，或监听跨容器的点击/键盘行为，极易污染主应用、触发重复逻辑，甚至导致事件丢失或冒泡错乱。
事件监听必须限定在子应用自有容器内
子应用初始化时，应只对自身挂载节点（如 document.getElementById('app1-root')）及其后代进行事件委托或直接绑定，禁止使用 document.addEventListener('click', ...) 这类无边界监听。
- 推荐写法：
container.addEventListener('click', handler, { capture: true })，其中container是子应用专属 DOM 节点 - 避免写法：
document.body.addEventListener('input', ...)、window.addEventListener('keydown', ...) - 框架级约束：qiankun 和 micro-app 在 mount 阶段会自动将子应用的
document和window指向沙箱代理对象，但原生addEventListener若未被重写或拦截，仍可能逃逸到真实全局对象
跨应用通信不走原生 DOM 事件流，改用框架通信机制
子应用之间、子应用与主应用之间的业务事件（如“用户登出”“订单提交成功”），不应依赖 CustomEvent 在 document 上 dispatch 后靠冒泡传递——这既不可控，也违背微前端的契约通信原则。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 主子通信：通过 props 透传回调函数，或调用主应用暴露的
props.onGlobalEvent接口 - 子子通信：统一经由主应用中转，或使用事件总线（如
mitt实例由主应用创建并共享给各子应用） - micro-app 提供
dispatchCustomEvent方法，但该方法只在子应用内部生效，不会泄漏到主文档，适合封装组件级事件
全局事件需显式桥接，且由主应用统一收口
少数必须响应的全局行为（如 beforeunload、visibilitychange、键盘快捷键），应由主应用统一监听，并按需分发给当前激活的子应用。
- 主应用监听
window.addEventListener('keydown', e => { if (e.ctrlKey && e.key === 's') activeApp?.handleSave(); }) - 子应用只暴露
handleSave等语义化方法，不自行注册全局快捷键 - 沙箱若启用 strict mode，原生
window.addEventListener调用会被代理拦截，实际注册到虚拟 window 实例上，主应用可通过沙箱 API 主动同步关键事件状态
CSS 与 Shadow DOM 对事件传播的影响要提前验证
当使用 Shadow DOM 做样式隔离时，事件默认不会穿透 shadow boundary，除非显式设置 composed: true。这意味着子应用在 shadow root 内 dispatch 的事件，主应用无法直接监听到。
- 若需穿透：使用
new CustomEvent('my-event', { bubbles: true, composed: true }) - 若不希望穿透（更安全）：保持默认
composed: false，改用消息通信替代 - 注意：qiankun 默认不启用 Shadow DOM，micro-app 可配置
useShadowDOM，启用后需同步检查所有事件监听位置是否适配
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
