viewport标签必须置于HTML最开头且唯一，标准写法为<meta name="viewport" content="width=device-width, initial-scale=1.0">，仅此组合兼容2026年所有主流移动端浏览器。
viewport 标签必须放在 最开头，且只能有一个
浏览器一解析到 <meta name="viewport"> 就立刻重设 layout viewport；晚了，首屏已经按默认 980px 渲染完成，再补或改只会缩放抖动、重排，甚至完全无效。
常见翻车点包括：
-
<meta charset>后面被 SSR 模板注入的注释、<script>占位符或框架注释挤开，导致实际生效位置偏移 - 用 JavaScript 动态创建并
document.head.appendChild()—— iOS Safari 和多数安卓 WebView 直接忽略 - 误写在
<body>里，Chrome 和 Safari 都不认 - 多个
<meta name="viewport">并存，浏览器只取第一个，其余静默丢弃
验证方式：Chrome DevTools 切 iPhone 模拟器 → Elements 面板看 <html> 的 clientWidth —— iPhone 13 应接近 390，不是 980。
content 值只写 width=device-width, initial-scale=1.0 就够了
这是 2026 年所有主流移动端浏览器（iOS Safari、Chrome for Android、Samsung Internet）实测通过的最小有效组合。多一个参数，就多一分兼容性风险。
立即学习“前端免费学习笔记（深入）”；
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
关键细节：
- 只写
width=device-width：老版 iOS（如 iOS 9）可能 fallback 到 980px 缩放逻辑 - 只写
initial-scale=1.0：部分安卓 WebView 忽略，文字照旧小得看不清 - 加
maximum-scale=1.0或user-scalable=no：违反 WCAG 2.1，系统「更大字体」设置失效，iOS 输入框还可能强制放大 - 写死
width=375：横屏时直接崩，Pixel 系列或 iPad 上完全错位
标准写法就是：<meta name="viewport" content="width=device-width, initial-scale=1.0">
写了 viewport 还横向滚动或文字糊？真凶在 CSS
<meta name="viewport"> 只管“画布怎么铺开”，不解决布局、字体、图片的具体适配。页面错乱往往出在这里：
- CSS 里写了
width: 375px或font-size: 16px这类硬编码——该用%、rem、vw的地方没换 - 图片没加
max-width: 100%; height: auto;，直接撑爆容器引发横向滚动 - 媒体查询用了
@media (max-width: 767px)却忘了在大屏样式里重置display或flex-direction，导致小屏规则残留覆盖 - 断点数值照搬别人家的
768/1024，实际内容在640px就已挤不开，却还在等768px才响应
字体和图片的响应式配套不能省
viewport 设置好后，font-size 和图片仍需独立适配：
- 硬写
font-size: 32px是最典型的反模式：无视系统字体偏好、绕过 iOS 动态类型、在缩放辅助功能下完全失效 - 推荐组合：
html { font-size: clamp(14px, 2.5vw, 18px); }—— 下限保可读，上限防溢出，中间随视口线性变化 - 图片必须加
max-width: 100%; height: auto;，否则无论 viewport 多准，一张图就能撑破视口 - 高 DPR 设备可叠加
@media (-webkit-min-device-pixel-ratio: 2)微调 rootfont-size，但别依赖它作为主逻辑
viewport 是开关，不是胶水。它开了，不代表布局自动粘合；漏掉任一配套点，都会在真机上露出缝隙。
