Bootstrap的.container宽度切换依赖CSS媒体查询而非JS计算，通过预设的min-width断点匹配max-width值实现响应式；直接内联max-width会破坏小屏适配，应通过同断点媒体查询覆盖；.container-sm等类名仅改变max-width生效时机而非实际宽度。
Container的宽度切换靠的是max-width媒体查询，不是JS计算
bootstrap的.container在不同断点下“自动切换”宽度，本质是浏览器根据预设的@media规则匹配max-width值，不是运行时js算出来的。你看到的xs→sm→md→lg→xl→xxl阶梯式变化，背后就是5组独立的媒体查询，比如@media (min-width: 1200px)对应xl断点下的max-width: 1140px（v5中为1140px，v5.3+为1200px）。
常见错误是以为加个style="max-width: 1200px"就能覆盖——它只在当前元素生效，且会破坏所有小屏断点逻辑，导致手机上也强制1200px而横向溢出。
- 断点阈值和对应宽度值是硬编码在Bootstrap CSS里的，不能靠改HTML类名“触发”切换
- 你写的
.container本身没有width声明，只有width: 100%，真正起限制作用的是各断点下的max-width - DevTools里检查Computed面板，能看到哪条
max-width被最终应用，方便定位是否被其他CSS覆盖
直接覆盖媒体查询是最稳妥的修改方式
如果你用的是CDN或已编译CSS，没法动Sass源码，就在项目自定义CSS文件末尾（确保加载顺序在Bootstrap之后）写对应断点的重写规则：
@media (min-width: 1200px) {
.container {
max-width: 1280px;
}
}
@media (min-width: 1400px) {
.container {
max-width: 1440px;
}
}
关键点：
- 必须用和Bootstrap完全一致的
min-width值，比如v5中xl是1200px，不能写成1199px或1201px，否则断点不触发 - 别加
!important——只要CSS加载顺序正确、选择器没降权（比如别写成div .container），就能覆盖原生规则 - 只改你需要的断点，其他保持默认，响应式阶梯不会断裂
.container-sm这类类名不是“改宽度”，而是“改生效时机”
.container-sm不会让容器变窄，它只是把“启用max-width限制”的起点提前到sm断点（≥576px）。在xs（width: 100%，等同于.container-fluid；到了sm及以上，才开始套用$container-max-widths里sm对应的值（如540px）。
适用场景：
- 登录页希望手机全宽、PC端才限制宽度 → 用
.container-sm - 某个区块需要比正文更早进入宽屏布局 → 用
.container-md，不用动全局配置 - 它不改变栅格列行为，也不影响
.row的负margin逻辑，副作用极小
想局部突破宽度限制？用.container-fluid嵌套更安全
如果只是某一块区域（比如首页Banner）需要撑满视口，但正文仍走标准断点，硬改.container全局宽度反而容易连带影响导航栏居中、卡片间距等细节。这时推荐结构上分层：
<div class="container-fluid">
<div class="container py-5">
<h1>这个区域仍按默认断点控制宽度</h1>
</div>
</div>
优势：
-
.container-fluid始终width: 100%，无max-width，适合做全宽背景、遮罩层 - 内层
.container照常响应断点，内容可读性不受影响 - 不需要额外CSS，兼容所有Bootstrap 4/5版本，包括纯CDN引入场景
真正容易被忽略的是：很多所谓“改宽度”的需求，其实本质是“视觉留白不够”，这时候用.container-fluid px-5调大左右padding，比硬调max-width更轻量、更可控。
