标准写法是<meta name="viewport" content="width=device-width, initial-scale=1.0">，其中width=device-width使页面宽度匹配设备逻辑像素，initial-scale=1.0确保初始缩放为1避免字体过小，而user-scalable=no虽禁双指缩放但影响可访问性，故推荐省略以兼顾无障碍需求。
viewport meta 标签的标准写法
移动端页面不缩放、不双击放大、适配不同屏幕宽度，核心就靠这行 <meta name="viewport" >。它不是可选配置，而是现代响应式页面的起点。
最常用且兼容性最好的固定写法是：
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">
-
width=device-width：让页面宽度严格等于设备屏幕逻辑像素宽度（比如 iPhone 14 的 viewport 宽度是 390px），而不是默认的 980px -
initial-scale=1.0：页面加载时缩放比例为 1，避免 iOS Safari 自动缩放导致文字过小 -
user-scalable=no：禁用双指缩放——注意：部分安卓浏览器或无障碍需求场景下可能被忽略，且 WCAG 不推荐完全禁用
为什么不能只写 width=device-width
单独写 <meta name="viewport" content="width=device-width"> 看似够用，但实际容易出问题：
- iOS Safari 在横屏切换时可能重置缩放，导致字体突然变小或布局错位
- 某些 Android 浏览器（如旧版 Samsung Internet）会忽略缺失
initial-scale的声明，回退到默认缩放 - 没有
initial-scale=1.0，width=device-width在部分 WebView 中行为不一致，尤其在 hybrid App 内嵌页中
user-scalable=no 的真实影响和替代方案
这个参数看似“防误操作”，但实际带来不少副作用：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 关闭缩放后，视力障碍用户无法放大页面，违反基本可访问性要求
- 微信内置浏览器、QQ 浏览器等对
user-scalable=no支持不稳定，有时仍可双击放大 - 若真需限制缩放，更稳妥的做法是用 CSS 控制：
body { touch-action: pan-x pan-y; }，既阻止 pinch-zoom，又保留滑动和点击
多数业务场景建议改为：content="width=device-width, initial-scale=1.0" —— 允许用户主动缩放，同时保证初始渲染正确。
不同框架或构建工具里的常见陷阱
Vue CLI、Next.js、Vite 默认模板通常已注入 viewport，但容易被二次覆盖：
- 在 Vue 单文件组件的
<template>里重复写<meta>，会导致 HTML head 中出现两条 viewport，后者可能被忽略 - Next.js 的
next/head或 App Router 的metadata配置中，若未显式设置viewport，会 fallback 到默认值（通常是width=device-width，缺initial-scale） - Vite + unocss 等工具链如果启用了自动注入，再手动加 meta 可能引发冲突，建议统一在
index.html中维护
最稳的方式：只在项目根目录的 index.html 中写一次，且确保它位于 <head> 最前面，不被其他脚本动态替换。
