user-scalable=no 已不推荐，因ios safari 10.3+无视该值、损害可访问性；应改用 width=device-width、maximum-scale=2.0、initial-scale=1.0 等组合，并辅以 js 拦截和 touch-action: manipulation 作兜底。
为什么 user-scalable=no 在现代移动端已不推荐
它确实能阻止用户双指缩放，但代价是损害可访问性与基础体验——iOS Safari 从 10.3 起就无视该值，Android Chrome 也逐步弱化支持；更关键的是，屏幕阅读器、视力障碍用户依赖缩放调整文字大小，硬禁用等于直接拒绝这部分用户。
替代方案：用 viewport 的合理取值保功能又控体验
真正可控且被广泛尊重的是 maximum-scale 和 initial-scale 组合，而非粗暴禁用缩放：
-
width=device-width必须设置，否则scale类参数可能失效 -
maximum-scale=2.0比user-scalable=no更稳妥：允许必要缩放，又防页面被拉得过大变形 -
initial-scale=1.0配合minimum-scale=1.0可避免首次加载时意外缩放 - 不要写
user-scalable=0或user-scalable=false—— 这些值不被标准认可，浏览器行为不一致
真要禁用缩放？优先考虑 JS 层防御而非 viewport
某些表单页或游戏界面确有强交互约束，此时 viewport 已不可靠，需配合运行时拦截：
- 监听
touchstart事件，检测多点触控（event.touches.length > 1），然后event.preventDefault() - 注意：必须在
body或根容器上绑定，且不能阻止默认行为后又触发滚动，否则 iOS 会卡死 - 别忘了加
touch-action: manipulationCSS，减少延迟并明确手势意图 - 这种 JS 方式仅作兜底，无法替代语义正确的 viewport 配置
检查是否生效的三个实际动作
光写对没用，得验证真实设备表现：
- 在 iOS 真机 Safari 中双指张开，看是否还能放大；若能，说明
user-scalable=no已被忽略，需切回maximum-scale方案 - 用 Chrome DevTools 的 Device Mode 切换到 “Responsive” 模式，勾选 “Disable touch emulation”，再试缩放 —— 某些模拟器会错误地执行
user-scalable - 打开系统「辅助功能 → 显示与文字大小 → 更大字体」，观察页面文字是否仍可随系统设置放大；若不能，说明你误伤了可访问性链路
viewport 缩放控制从来不是非黑即白的开关，而是权衡可访问性、兼容性和交互需求的微调。最常被忽略的一点：哪怕你 JS 拦截了双指，系统级字体缩放依然有效，而这个能力不该被覆盖。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
