先记住这个答案
现代浏览器普遍具备尺寸容器查询，但项目仍可能运行在旧版内嵌浏览器。最稳的做法是先写可读的默认布局，再添加 container-type 和 @container 规则，让支持该特性的环境获得更精细的布局；不认识的查询规则会被忽略。不要只背某个浏览器版本号，按项目目标环境实测。
- 先写可用的默认布局
- 容器查询负责增强宽容器
- 老环境会忽略不认识的
@container - 用目标浏览器测试而非硬背版本号
默认单栏先保证内容可读
一张卡片的标题、说明和操作按钮即使没有新特性也应完整显示。宽容器里再增强成图文双栏，是布局优化，不应成为阅读内容的前提。
.card__body { display: block; }
.card { container-type: inline-size; }
@container (min-width: 28rem) {
.card__body { display: grid; grid-template-columns: 10rem 1fr; }
}旧环境如果不认识 @container，会保留 .card__body 的默认单栏。即便 container-type 也不支持，内容仍在正常文档流里，不会因为增强规则缺失而消失。
如果样式在新旧浏览器中都需要一定宽度约束，可再为旧环境加媒体查询回退；但媒体查询看视口，不能完全等价替代容器查询。
验证要覆盖真实嵌入环境
桌面浏览器最新版通过，不代表 App 内的 WebView 也通过。验收时在目标环境打开主栏和窄侧栏两种容器宽度，检查文本是否可读、按钮是否仍可操作、宽组件是否正确切换。
浏览器兼容表可帮助确定范围，但最终仍以项目支持矩阵和实际测试为准。对样式查询、滚动状态查询等更细的容器查询能力，不能因为“尺寸查询可用”就推断全部可用。
回退样式也要在窄空间真实走一遍。默认单栏若只在全宽页面里看过，放进旧 WebView 的侧栏时仍可能被固定宽图片或长链接撑破。给媒体资源加 max-width: 100%，让文字可换行，再测试按钮是否能点到；这样即便增强规则完全被忽略，用户仍可完成阅读和操作。兼容性验收看的应是功能，而不是“有没有两列”。
容易答错的地方
- 把增强规则写成唯一可用布局
- 旧环境忽略
@container后可能留下拥挤或隐藏的内容。默认样式应能独立工作。 - 用浏览器名称代替功能验证
- 同一浏览器的不同版本、WebView 和用户关闭的实验特性可能不同。用实际目标环境检验。
面试官还会怎么问？
可以用 @supports 检测容器能力吗？
可以按需要测试相关 CSS 声明，再包裹增强规则；默认样式仍应放在外面，确保无论检测结果如何都能阅读。
旧浏览器能用 @media 模拟吗？
可做近似回退，但媒体查询依赖视口，宽桌面上的窄侧栏可能判断错误。
容器查询不起效先查什么？
先看是否有合格祖先、容器实际尺寸、规则是否被识别，再查层叠覆盖。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。