@container在微前端中大概率不生效，是因为子应用挂载的DOM节点未显式声明container-type属性，主应用未提前为挂载点（如<div id="micro-app-1">）设置container-type="inline-size"，且该属性必须在HTML初始渲染时存在，而非JS动态添加；Shadow DOM、iframe及CSS-in-JS等场景也存在兼容限制。
为什么直接用 @container 在微前端里大概率不生效
@container 依赖容器查询（Container Queries），而它的前提条件是：目标元素必须被显式设为 container（通过 container-type 或 container-name）。微前端场景下，子应用通常由独立打包、沙箱隔离、动态挂载的 DOM 片段组成——这些节点往往没有设置容器类型，父容器也极少主动声明 container-type: inline-size，导致 @container 规则根本不会触发。
常见错误现象：@container (min-width: 400px) { ... } 写了但样式完全不应用，控制台也无报错；检查 computed styles 发现元素的 container 属性为 none。
- 子应用 CSS 是独立作用域，无法穿透修改宿主容器的
container-type - 主应用若未提前为插槽（如
<div id="micro-app-1">）设置container-type: inline-size，子应用内任何@container都无容器可查 - Shadow DOM 场景下（如 Web Components 封装的微前端子应用），
@container默认不可用，需显式启用container-type且仅对 light DOM 生效（目前多数浏览器不支持 Shadow DOM 容器查询）
主应用必须做的最小容器声明
不是在子应用里写 @container 就完事，而是主应用要为每个微前端挂载点“开闸”：
<div id="app-shell"> <div id="micro-app-cart" container-type="inline-size" container-name="cart"></div> <div id="micro-app-user" container-type="inline-size"></div> </div>
注意：container-type 必须是 inline-size（宽度查询）或 size（宽高都查），block-size 目前仅 Safari 支持，不要用。
立即学习“前端免费学习笔记（深入）”；
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 不能靠 JS 动态加
container-type后再挂载子应用——CSS 解析发生在 DOM ready 前，必须初始 HTML 就带该属性 - 如果子应用用 iframe 加载，
@container完全无效（iframe 不继承容器上下文） - 多个同名
container-name会冲突，建议按子应用 ID 命名，如cart-v2，避免 CSS 规则误匹配
子应用中 @container 的正确写法和限制
子应用可以安全使用 @container，但只能查它自己所在的容器（即主应用声明的那个 <div>），不能跨查父级布局容器（比如 flex 容器或 grid 区域）。
@container cart (min-width: 375px) {
.cart-header { font-size: 1.1rem; }
}
@container cart (min-width: 768px) {
.cart-items { display: grid; }
}
关键点：
- 必须用
@container <name>显式指定名称，否则默认查最近的匿名容器（容易错配） - 不支持嵌套容器查询（比如子组件再设
container-type并查自身尺寸），浏览器尚未实现 - 媒体查询（
@media）仍需保留作为降级方案——Chrome 105+、Firefox 119+、Safari 16.4+ 支持，旧版本直接忽略@container规则 - 不能用
em、rem等相对单位写断点值，只接受px、%、vw（但%指容器宽高比，非视口）
与微前端框架（qiankun / Module Federation）的实际协作要点
qiankun 默认不干预容器属性，Module Federation 的容器应用（host）也默认不设 container-type。你得手动补：
- qiankun：在
mount前，用document.getElementById('your-container').style.containerType = 'inline-size'不够——这只能设 style，不等于 HTML attribute，必须用setAttribute('container-type', 'inline-size') - Webpack Module Federation：host 应用的
Container组件渲染时，需确保其根 DOM 节点带container-type属性，不能只靠 CSS 类或 data 属性模拟 - 如果子应用用了 CSS-in-JS（如 Emotion），需确认其注入的
@container规则能被浏览器识别——部分库会把规则包裹进<style data-emotion>，只要没破坏语法结构就 OK - 服务端渲染（SSR）子应用时，
container-type属性必须同步输出到首屏 HTML，否则 hydration 后容器查询会延迟一帧甚至失效
真正卡住的地方往往不是语法，而是容器上下文在微前端生命周期里的“时间差”：DOM 插入、attribute 设置、CSS 解析、子应用样式注入，四者顺序稍有错乱，@container 就静默失效。调试时优先检查 computed panel 里的 container 字段，而不是反复改断点值。
