先记住这个答案
常见的 768px、1024px 只是历史上便于讨论的宽度，不是响应式布局必须采用的标准。真正的断点应由内容决定：在浏览器里缓慢改变宽度，找到导航开始挤压、正文行长不合适、卡片列宽不足的位置，再写媒体查询。页面层看视口，复用组件还应考虑自己实际得到的容器宽度。
- 断点由内容失效点决定
- 先保证窄屏可读再扩展
- 断点不是某款设备的专属宽度
- 组件可优先考虑容器查询
从内容失效点找断点
先从最窄的可用布局做起，让正文、按钮和表单不用横向滚动。逐渐放大窗口，观察什么时候能容纳侧栏或第二列卡片。这个转折宽度就是断点候选，而不是先挑一台热门设备的标称尺寸。
.page { display: grid; grid-template-columns: minmax(0, 1fr); }
@media (min-width: 56rem) {
.page { grid-template-columns: minmax(0, 1fr) 16rem; gap: 2rem; }
}示例中的 56rem 只是这个页面的设计选择：主内容达到可读宽度且还能留给侧栏 16rem 时，才切成双栏。换了字体、文案或侧栏内容，应重新观察，而不是机械复用数值。
用浏览器缩放和长文案测试也很重要。固定设备宽度下，字体变大或本地化文本变长，导航可能更早拥挤。断点应服务内容，而不是服务设备清单。
页面断点与组件断点
同一张卡可能出现在全宽页面，也可能出现在半宽侧栏。视口明明很宽，侧栏卡片却仍然很窄。用全局媒体查询判断卡片布局，就会把“宽桌面上的窄卡”误判成宽卡。
页面骨架仍可用 @media，但独立组件的内部排布更适合 @container 或天然能伸缩的 Grid/Flex 规则。能用 minmax() 和自动重复平滑伸缩时，也不必为每个宽度增加断点。
定断点时可以把开发工具的宽度停在“刚好坏掉”的位置，记录究竟是哪一项不够放：是导航文字换行、表格被截断，还是两列卡片的最小宽度被破坏。然后向宽处或窄处留一点余量，再验证字号放大和长标题。这样以后设计改了按钮文案，团队知道应重新测量的是哪段内容，而不是守着一个来源不明的 768px。
容易答错的地方
- 把断点等同于设备型号
- 分屏、浏览器侧栏和桌面窗口缩放都会改变可用宽度。同一个设备也可能跨越多个布局状态。
- 为每个尺寸加一个断点
- 断点过密会让规则互相覆盖。先用弹性尺寸解决连续变化，只在结构确实需要切换时增加查询。
面试官还会怎么问？
移动优先的媒体查询怎么写？
先写窄屏默认样式，空间足够时用 @media (min-width: ...) 加双栏或更宽的导航。
为什么用 rem 写断点？
它与根字号相关，用户调大默认字体时布局有机会更早切换；关键仍是实际测试内容是否拥挤。
组件在侧栏里也要响应式怎么办？
让组件的外层成为查询容器，用 @container 根据可用宽度换内部排布。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。