两列布局在添加 margin 后总宽度超过 100%，原因在于 margin 不计入 width 计算，实际占用空间会变成 50% + 50% + 20px；更合理的 CSS 处理方式，是通过 calc((100% - 20px) / 2) 先扣除固定间距，再平均分配两列宽度。
为什么两列加 margin 后总宽超 100%
这并不是浏览器计算出错，而是因为 margin 本来就不会参与 width 的宽度计算。当你写下 .col-1 { width: 50%; margin-right: 20px; } 和 .col-2 { width: 50%; } 时，两列内容区域相加确实等于 100%，但额外的 20px 外边距会继续叠加在整体宽度之外。换句话说，实际占用空间 = 50% + 50% + 20px，因此页面布局超出父容器是必然结果。
这种 CSS 两列布局超宽问题常见的表现包括：第二列被挤到下一行、页面意外出现水平滚动条、右侧按钮或内容被裁切。
- 父容器未设置
box-sizing: border-box，而子元素又包含padding或border，会让宽度误差进一步放大 - 使用了
float却没有及时清除浮动，可能导致渲染顺序混乱，进而影响布局判断 - 在 Flex 容器中仍然依赖
margin拉开列间距，而没有直接使用原生gap
calc() 两列均分（含固定间距）的正确写法
核心思路很简单：先把“固定间距”从总宽度中预先扣除，再将剩余空间平均分给两列。假设两列之间需要保留 20px 的水平间距，那么每一列的宽度就应该写成 (100% - 20px) / 2。
标准写法必须是：width: calc((100% - 20px) / 2);
- 括号不能省略：
100% - 20px / 2会被浏览器解析成100% - 10px，这并不是预期中的两列平分效果 - 运算符前后必须保留空格：
calc((100% - 20px) / 2)✅，calc((100%-20px)/2)❌（在 IE9+ 中可能直接失效） - 如果列本身还设置了
padding: 12px或border: 1px solid，并且希望最终视觉宽度完全一致，建议同时加上box-sizing: border-box
兼容旧版浏览器时的 fallback 策略
在旧版浏览器兼容场景中需要特别注意：IE9–11 并不支持 / 和 * 运算，所以 calc((100% - 20px) / 2) 在这些环境下会被直接判定为无效声明，最终回退成 width: auto，导致整个两列布局错乱甚至完全失效。
- 最简单的 fallback 方案：使用整数百分比配合
max-width限制，例如width: 48%; max-width: 480px; - 更稳定的方案：改用
display: flex替代 float 或 inline-block，并设置gap: 20px—— 虽然 Flex gap 在 IE11 中不受支持，但现代浏览器已经基本全面兼容；如果必须兼容 IE11，可继续使用margin+:last-child { margin-right: 0; }手动处理间距 - 尽量避免嵌套 calc：
calc(calc(100% / 2) - 10px)在多数浏览器中都不可靠，只会增加调试成本
和 Flex/Grid 比，calc() 在两列间距场景下的真实代价
calc() 的优势在于它能精确“算出一个宽度值”，但它无法主动应对运行时内容变化，例如文字换行、图片加载失败、字体延迟加载等情况。一旦某一列因为超长单词未断行，或者图片未设置 max-width: 100% 而被撑开，整行内容就很容易溢出。相比之下，flex-wrap: wrap 或 grid-template-columns: repeat(auto-fit, minmax(...))) 则能更自然地实现自动换行和自适应布局。
gap是更语义化的列间距控制方式，它不会侵占子项的width，也不会破坏box-sizing的计算逻辑，后期维护成本更低calc()本质上写死的是“像素差值”，如果设计稿把间距从20px改成24px，你通常需要手动同步修改多个位置：两个width值，以及可能存在的margin- 真正适合使用 calc() 的场景，是那些无法直接通过布局系统表达的尺寸微调，例如 fixed 弹窗避开系统状态栏、输入框与 label 高度精确对齐等
