必须在<head>最前面加<meta name="viewport" content="width=device-width, initial-scale=1.0">，width=device-width和initial-scale=1.0缺一不可，否则浏览器默认以约980px桌面视口渲染，@media规则永不触发。
viewport没写对，@media根本不会触发
浏览器默认用约980px的桌面视口渲染移动端HTML。哪怕你写了@media (max-width: 768px)，设备实际报告的宽度仍是980px，媒体查询永远不匹配。
必须在<head>最前面加这行：
<meta name="viewport" content="width=device-width, initial-scale=1.0">
-
width=device-width和initial-scale=1.0必须同时存在，缺一不可 - 不能写成
width=375或width=1200——硬编码会锁死缩放，断点失效 - 别漏掉
initial-scale=1.0，否则iOS Safari可能自动缩放到0.8左右 - 动态插入（比如Vue的
<client-only>、JS执行document.head.appendChild()）无效，Safari和多数Android WebView直接忽略
为什么写了viewport还是横向滚动或字体发虚
真因不是viewport本身，而是内容撑破了视口。iOS Safari遇到未设max-width的图片、没约束的<table>、或长单词时，会无视initial-scale=1.0，强制缩小整个画布来“适配”内容。
- 检查
document.documentElement.clientWidth是否远小于window.screen.width，确认是否被缩放 - 临时加
* { outline: 1px solid red; }快速定位溢出元素 - 给所有图片加
img { max-width: 100%; height: auto; } - 表格加
table { width: 100%; table-layout: fixed; } -
width: 100vw加上padding或border会导致实际超宽，改用width: 100%或box-sizing: border-box
user-scalable=no现在还安全吗
不安全。iOS 16+已明确弱化对user-scalable=no的支持，Safari会无视它；Android各厂商WebView行为不一致，有的照办，有的跳过。更严重的是，它违反WCAG 2.1可访问性标准，老年用户和视障用户无法放大阅读。
立即学习“前端免费学习笔记（深入）”；
- 禁用缩放组合
user-scalable=no, maximum-scale=1.0, minimum-scale=1.0属于高危写法，应彻底删除 - 如确需限制缩放（如Kiosk终端），必须由native层统一接管，Web端不再依赖该属性
- 控制局部区域手势，或用CSS限制特定容器可缩放，而非全局锁死
断点值该按iPhone尺寸写，还是按内容写
按内容写。所谓“iPhone 14是390px”这类数据毫无意义——真实断点是文字开始换行、导航栏挤成两行、图片被裁切的那一刻的视口宽度。
- 打开Chrome DevTools，勾选“Toggle device toolbar”，拖动宽度滑块，观察布局断裂点
- 记录下精确像素值，比如
482px、769px，而不是四舍五入成480px或768px - 优先用
@media (min-width: 768px)配合移动优先策略，基础样式写在媒体查询外 - 避免混用
min-width和max-width，否则可能产生1px缝隙，DPR=2设备上易触发渲染抖动
viewport只是画布，画布歪了，再精细的CSS也会偏。但画布正了，内容溢出、断点错位、缩放异常这些真正的问题，才开始浮现——它们藏在CSS里，不在meta标签中。
