生成式卡片的响应式布局：断点应该看容器，不只看窗口

同一张订单卡片放进全宽工作台没有问题嵌入右侧抽屉却被挤成一团。浏览器窗口没有变窄媒体查询自然不会替你解释这个局部变化。生成式UI把卡片放到越来越多的宿主里布局的边界也应该跟着宿主走。CSS Containment Level 3给出了容器查询相关机制。这里用它解决一个具体问题卡片自身不知道会被放到哪里但它可以根据可用的内联尺寸改变字段列数。容器与被查询元素不要混在同一层给外层建立查询容器在里面调整卡片布局。先提供不依赖查询的单列样式再让支持相关能力的浏览器增强为多列。断点只是这个示例的设计选择不是行业标准。下面是一个完整HTML页面可以直接保存后打开。拖动浏览器窗口或修改.host的宽度即可观察列数。这里只放固定内容用来检查布局真实流式协议应单独接入。!doctype html html langzh-CN meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title容器内的生成式卡片/title style body { margin: 24px; font: 16px/1.6 system-ui; } .host { container-type: inline-size; max-width: 70rem; } .card { display: grid; gap: 1rem; padding: 1rem; border: 1px solid #456; border-radius: 8px; } label { min-width: 0; } input { display: block; box-sizing: border-box; width: 100%; min-width: 0; padding: .5rem; font: inherit; } container (min-width: 32rem) { .card { grid-template-columns: repeat(2, minmax(0, 1fr)); } } container (min-width: 52rem) { .card { grid-template-columns: repeat(3, minmax(0, 1fr)); } } /style main classhost form classcard label姓名input namename autocompletename/label label城市input namecity autocompleteaddress-level2/label label备注input namenote/label /form /main /htmlminmax(0, 1fr)和控件的min-width: 0是为了让长内容有收缩空间不是为内容截断免责。错误提示、长地名和较大字号也需要进入测试。业务关键文字不应为了维持一张“整齐卡片”而被隐藏。流式到达与布局变化是两条轴10月更新的WebMCP文档仍强调可见的网页交互。无论内容由Agent还是用户触发新增字段都不应夺走正在输入的焦点。保持稳定字段ID避免把整张表单销毁重建尚未到达的字段可以保留合理占位但不要承诺一个无法预测的固定总高度。图片尚未下载时预留宽高比文字自然增长时允许页面延展用户已经向上阅读时停止自动跟随。容器查询解决的是空间分配不负责这些交互状态也不保证CLS必然为零。这份HTML未在浏览器中实际打开或完成无障碍测试未验证各浏览器版本的兼容矩阵。它没有真实模型、翻译和流式网络依赖接入生产前仍需覆盖窄容器、放大字号、键盘焦点和长文本。