移动端max-width设为750px是因设计稿多以iphone 6/7/8的375px逻辑宽为基准，2x倍图对应750px物理像素；该值在ipad mini（768px）上不溢出，在更大屏上也不显空旷，是兼顾兼容性与视觉密度的合理上限锚点。
移动端 max-width 为什么设成 750px 是常见起点
因为多数 H5 设计稿以 iPhone 6/7/8 的 375px 屏宽为基准，2x 倍图对应物理像素就是 750px；这个值在 iPad mini（768px 宽）上刚好不溢出，在 iPad Air（820px）或折叠屏横屏（≥1024px）上也不会留大片空白。它不是绝对标准，但作为「上限锚点」足够平衡兼容性与视觉密度。
实际使用时别只写 max-width: 750px——小屏下它会让内容缩在中间，左右空出大块。必须配合 width: 100% 和 margin: 0 auto，确保窄屏占满、宽屏卡住。
-
max-width: 750px单独存在 ≠ 限制有效，它只是上限，不控制定位 - 若父容器是
display: flex，margin: 0 auto会失效，得改用justify-content: center - 写了
padding: 20px却没设box-sizing: border-box，实际内容区会比预期窄40px，影响行长判断
用 min() 函数替代媒体查询更轻量
现代 iOS/Android 浏览器（Safari 15.4+、Chrome 79+）都支持 min(750px, 100vw)。这个值在手机上取 100vw（铺满），在 iPad 横屏或桌面端自动回落到 750px，一行字符数稳定在 60~70 个英文字符区间，阅读节奏不被打断。
相比传统媒体查询三段式写法（@media (max-width: 768px) / @media (min-width: 769px)…），min() 写法代码量少、无断点缝隙、维护成本低。
- 旧安卓 WebView（如 Android 4.4）不支持
min()，需加降级：max-width: 750px; max-width: min(750px, 100vw) - 别用
%替代，比如max-width: 80%—— 它依赖父容器宽度，而很多 H5 的根容器没设宽，结果就是失效 -
min(750px, 100vw)在折叠屏半开状态（比如 540px 宽）下仍取100vw，符合直觉；媒体查询容易漏掉这种中间态
margin: 0 auto 在 H5 里经常不居中？先查这三处
H5 页面里 margin: 0 auto 看似简单，但失效频率极高。核心原因：它只对常规文档流中的块级元素起作用，而 H5 布局常主动打破这个前提。
- 父容器用了
display: flex或display: grid—— 子元素的margin: 0 auto被忽略，换justify-content: center - 目标元素被加了
float: left或position: absolute—— 这两类定位会让margin: 0 auto失效 - 容器内部有
transform（比如轮播图动画），且父容器设了overflow: hidden—— iOS Safari 可能导致偏移，加will-change: transform缓解
最稳妥的检查方式：临时给目标元素加 background: red，看色块是否居中；如果不是，再逐层往上查父容器的 display 和 position 值。
字号、行高、max-width 必须联动调整
只调 max-width 不动 font-size 和 line-height，在 iPad Pro 12.9 寸（2048px 宽）上依然会显得稀疏。行长变长后，同样 line-height: 1.6 的视觉间距会被拉得更大。
推荐做法：用媒体查询或 clamp() 同步微调字号，并保持无单位 line-height（如 line-height: 1.55）。
- 在
1200px断点把正文font-size从16px提到17px，既提升可读性，又避免行高被过度拉伸 - 避免用
vw直接驱动正文字号（如font-size: 2.5vw），它在超宽屏下会失控，更适合标题 - 如果用了 REM 方案，建议根字号按设备宽度动态算，而不是固定
html { font-size: 62.5% }—— 那在 iPad 上反而会让字过小
真正难的是三者比例关系：大屏下哪怕只多出 100px 宽度，如果字号没跟上，line-height 就会暴露失衡。调试时最好在真机上横竖屏反复切，看段落呼吸感是否一致。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
