做H5开发头两年，最让我头疼的就是页面被“自己放大”。开发工具里一切完美，真机上一碰就“放飞自我”：字大得离谱，按钮错位，滚动起来像有人在拖拽页面。后来排查下来发现，这根本不是布局问题，而是移动端浏览器的缩放机制在作怪。这篇就聊聊我在Vue H5项目里彻底解决“禁止缩放”的完整思路，包括viewport配置、JavaScript兜底拦截、组件级封装，以及几个只有上过真机才会明白的坑。
1. 先从viewport说起：移动端缩放问题的根源
移动浏览器之所以会缩放页面，核心在于它有一套“为PC网页服务”的默认规则。在没有viewport设置时，浏览器会把视口宽度设定成一个固定值，早年普遍是980px，然后整个页面像一幅大图一样被缩小显示。用户一旦双击或双指捏合，浏览器就会根据手势对页面进行缩放，这是浏览器层面的默认行为，和你的前端框架没有任何关系。很多H5项目之所以觉得“压不住”缩放，就是只注意到布局适配，没系统性地堵住这些默认手势通道。
1.1 一个简洁的viewport标准写法
要禁缩放，第一步一定是在index.html里把viewport配置完整。大多数项目里默认是这样一个基础版本：
<meta name="viewport" content="width=device-width, initial-scale=1.0">这个配置告诉浏览器：页面宽度跟随设备宽度，初始缩放比例为1。但仔细一看，它并没有限制用户后续的缩放操作。所以还需要把最大缩放比例固定住，并禁用用户缩放：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no">注意看，我在这里把minimum-scale也写了。很多同学只写maximum-scale和user-scalable，忽略了minimum-scale。当用户聚焦输入框，或者浏览器出于某种原因尝试把页面放大时，如果minimum-scale没有锁住，依然存在可放大空间。三个scale配合起来，等于告诉浏览器：横竖你都别想缩放，初始就是唯一状态。
不过这里有个容易误判的地方：width=device-width, initial-scale=1.0本身已经隐含了“布局视口等于设备宽度”的意思，但initial-scale=1.0只会约束首次加载时的缩放比例，并不会锁定后续手势缩放。这也是为什么很多项目明明写了viewport，用户还是能捏合缩放的原因之一。
1.2 为什么光写viewport还不够
如果项目只在内测环境里跑一跑，这个meta配置基本能应付。但它有一个很致命的盲区——浏览器和系统会根据自己的策略决定是否尊重这些参数。最典型的就是iOS Safari，从10.0版本开始，为了屏幕阅读器等无障碍工具的可用性，系统会完全忽略user-scalable=no这个字段，Safari上用户依然可以双指缩放。这是我在多个项目里实测过的现象，不是道听途说。
到这一步，就必须要靠JavaScript来拦截手势路径了。但先别急着写代码，我们得先搞明白不同系统的“性子”再动手，否则方案很容易做过头或做漏。
2. 系统差异：iOS和Android的“反缩放”博弈
其实不只是iOS，Android阵营更加“群雄割据”。原生浏览器、各厂商浏览器、WebView控件，对viewport私有实现的细节都不太一样。有的安卓浏览器即使写了user-scalable=no，用户双击时还是会放大；有的则在meta生效的同时，把页面渲染和CSS像素处理做得非常激进。如果内容团队只是让你“把缩放禁掉”，你最好先把目标系统范围确认清楚。
2.1 iOS Safari为什么会无视user-scalable
苹果的理由很简单：保证可访问性。出于无障碍设计，Safari从iOS 10开始不再允许网页通过meta标签完全禁止用户缩放。这也是很多同学在iPhone上“怎么禁都禁不掉”的直接原因。与iOS 9及更早版本不同，在iOS 10之后的Safari里，虽然maximum-scale和minimum-scale还有一定约束力，但“用户缩放”这个开关基本失效。换句话说，你不能指望Safari为了产品需求，牺牲系统层面的无障碍能力。
所以我的经验是：不要因为meta看起来“标准”，就觉得万事大吉。iOS上你还需要用手势事件和touch事件做拦截。但这个拦截又不能做得太粗暴，否则用户在Safari里放大文字的无障碍能力也会被一并干掉，这在部分合规要求严格的项目里反而会引出新问题。
2.2 Android厂商浏览器的默认行为差异
Android这边，情况则更依赖具体内核。比如微信内置浏览器、支付宝等App里的WebView，以及部分厂商自带的浏览器，对meta的解析并不完全一致。在Chrome桌面驱动的页面里，user-scalable=no通常有效，但在某些版本的内核中，事件默认行为是由内核先行处理的，页面里的preventDefault如果时机不对，照样拦不住。你必须在事件冒泡到最顶层之前，以passive: false的方式注册监听器，抢在内核默认行为之前把缩放事件按下去。
这些差异意味着“一刀切”地只靠单一meta配置，在真机上很容易出问题。所以完整方案一定是三层：viewport锁参数、CSS禁用双击语义、JavaScript拦截手势路径。接下来就聊聊JavaScript兜底部分，这是最核心、也最容易写错的一层。
3. JavaScript兜底拦截：从双指到双击的全量拦截
如果viewport是“门锁”，JavaScript拦截就是“安防报警器”。它强制在事件层面把可能导致缩放的手势路径全部拍死，这样即使浏览器内核不尊重meta，也接收不到完整的手势信号。
3.1 双指缩放拦截的正确写法
双指缩放是移动端最常见的缩放手势。要拦截它，最直接的办法是在touchmove里判断当前是否有多点触控：
document.addEventListener('touchmove', function (e) { if (e.touches.length > 1) { e.preventDefault(); } }, { passive: false });注意这里的第三参数，一定要传{ passive: false }。为什么？因为新版浏览器为了避免页面滚动卡顿，默认把touchmove、wheel这类事件视为passive，也就是监听器不打算调用preventDefault。如果你不主动声明passive为false，这个preventDefault就会被浏览器直接忽略，拦截等于白写。这个坑我踩过一次，当时排查了很久，最后发现不是逻辑问题，而是注册方式问题。
不过这样写会有一个副作用：双指滑动时，scroll也会被禁止，页面将无法滚动。所以在实战里我会额外加点判断，比如只拦截那些确实产生了缩放手势的情况，或者把拦截范围限制在非滚动区域。一个相对粗暴但稳妥的做法是，在touchstart阶段就拦截多点触控：
document.addEventListener('touchstart', function (e) { if (e.touches.length > 1) { e.preventDefault(); } }, { passive: false });但要注意，touchstart里preventDefault会连带取消后续的鼠标事件和点击事件，在某些场景下可能会影响按钮点击，需要实测权衡。我在项目中通常两种写法都保留，然后在具体页面里通过开关控制是否启用touchstart层面的拦截。
3.2 双击放大与300ms时间戳判断
双指拦截搞定之后，双击放大还是一条漏网之鱼。浏览器允许用户快速点击两次来放大页面，这个行为和普通single click的事件序列是不同的。处理方式是在touchend里记录时间戳，如果两次touchend的间隔小于300毫秒左右，就认定是双击缩放，直接preventDefault。
let lastTouchEnd = 0; document.addEventListener('touchend', function (e) { const now = Date.now(); if (now - lastTouchEnd <= 300) { e.preventDefault(); } lastTouchEnd = now; }, false);这里有个细节，很多人会写成“如果两次点击小于300ms就禁止”，结果正常用户快速双击按钮时也被挡了。实际上双击按钮的场景很少，为了滚动性能，多多少少可以接受。如果你不想误伤点击，可以配合记录touchstart的位置，判断两次触摸的坐标是否接近，只有位置相近才算双击放大。这个优化在高频操作按钮的页面上特别有用。
3.3 gesturestart：iOS上的一道补充
对于iOS Safari，还有一个独特的手势事件：gesturestart。双指在页面上张开时，Safari会触发这个事件，然后才进入全页面缩放。拦截它是最省力的做法：
document.addEventListener('gesturestart', function (e) { e.preventDefault(); });有些资料说gesturestart是iOS私有事件，在Android上不会触发，所以只需要放在iOS端即可。但为了维护简单，我在项目里都是无脑挂上，反正它不会影响Android环境。加上这条之后，iOS上的双指缩放基本也能压住。
3.4 CSS辅助：touch-action与text-size-adjust
除了JavaScript，还有两个CSS属性值得一起搭配。touch-action: manipulation可以告诉浏览器，双击操作不要触发缩放，点击的300ms延迟也会被移除。在支持它的浏览器里，双击放大问题能直接从浏览器语义层面解决。
html, body { touch-action: manipulation; -webkit-text-size-adjust: 100%; }-webkit-text-size-adjust看似和缩放无关，其实很关键。iOS Safari在横竖屏切换或者用户改变系统字体大小时，会尝试对网页文本做整体缩放。如果不禁用文本自动缩放，页面排版同样会出现异常。这里我一般设成100%，表示不允许浏览器自行调整文本尺寸。
4. Vue项目中的落地姿势：从全局到组件
上面这些代码看起来简单，放哪儿却很有讲究。尤其是Vue项目，不同页面可能对缩放策略有不同要求。接下来我给出几种我在项目中验证过的落地方式，并说明各自的适用场景。
4.1 全局拦截：在App.vue中统一处理
如果产品明确要求“所有页面都不能缩放”，最简单就是全局注册。我通常会在src目录下建一个utils/disableScale.js，然后把上面所有拦截逻辑收敛成两个函数：
// utils/disableScale.js let lastTouchEnd = 0; function handleTouchStart(e) { if (e.touches.length > 1) { e.preventDefault(); } } function handleTouchMove(e) { if (e.touches.length > 1) { e.preventDefault(); } } function handleTouchEnd(e) { const now = Date.now(); if (now - lastTouchEnd <= 300) { e.preventDefault(); } lastTouchEnd = now; } function handleGestureStart(e) { e.preventDefault(); } export function addScaleGuard() { document.addEventListener('touchstart', handleTouchStart, { passive: false }); document.addEventListener('touchmove', handleTouchMove, { passive: false }); document.addEventListener('touchend', handleTouchEnd, false); document.addEventListener('gesturestart', handleGestureStart); } export function removeScaleGuard() { document.removeEventListener('touchstart', handleTouchStart); document.removeEventListener('touchmove', handleTouchMove); document.removeEventListener('touchend', handleTouchEnd); document.removeEventListener('gesturestart', handleGestureStart); }这里有几个细节值得说明。一是移除监听时，需要传入相同的事件处理函数引用，所以我把它们都定义成了具名函数，而不是匿名函数。二是removeEventListener时不需要再关心passive: false，只需要保证capture标记一致即可，否则监听器匹配不上，移除会静默失败。
然后在App.vue里这样挂：
<template> <router-view /> </template> <script setup> import { onMounted, onBeforeUnmount } from 'vue'; import { addScaleGuard, removeScaleGuard } from '@/utils/disableScale'; onMounted(() => { addScaleGuard(); }); onBeforeUnmount(() => { removeScaleGuard(); }); </script>不过这里我要提醒一句：Vue项目通常是单页应用，App.vue里的onBeforeUnmount往往要到整个应用销毁时才触发。如果只是在路由切换时想恢复缩放，这个方案并不合适。全局方案更适合那种“整个应用生命周期内都不允许缩放”的强约束项目，比如某些内部业务系统的扫码登录页、表单填写页。
4.2 封装成Vue指令：让禁用缩放可复用
如果只有“订单页需要禁缩放，文章阅读页允许缩放”，全局方案就太笨重了。更优雅的做法是写一个自定义指令，按页面或组件粒度挂载。Vue 3里自定义指令的钩子基本和组件生命周期对齐：
// directives/noScale.js import { addScaleGuard, removeScaleGuard } from '@/utils/disableScale'; export default { mounted() { addScaleGuard(); }, unmounted() { removeScaleGuard(); } };在main.js里注册：
import { createApp } from 'vue'; import App from './App.vue'; import noScale from './directives/noScale'; const app = createApp(App); app.directive('no-scale', noScale); app.mount('#app');页面里的用法很直观：
<template> <div v-no-scale class="order-page"> <!-- 页面内容 --> </div> </template>指令在组件挂载时自动添加监听，组件卸载时自动移除，不需要手动管理生命周期。需要注意的是，这个指令实际上操作的是document级的事件监听，所以一个页面上多个组件同时挂指令会重复监听。好在实际场景里我们一般是在页面最外层挂，整棵组件树共用一个监听即可，避免在多个子组件里重复使用。
另外，unmounted钩子要确保在mounted成功执行后才调用，否则removeScaleGuard会尝试移除一组从未添加过的监听器。虽然对于removeEventListener来说，移除不存在的监听器不会报错，但为了心智清晰，最好还是让指令只挂在最外层容器上。
4.3 组内实践：按路由切换控制缩放
还有一种常见需求：同一个应用里，有两个页面，A页面禁缩放，B页面不禁缩放。如果用了全局方案，就得在B页面手动调用removeScaleGuard，再在离开B页面时加回来。这个思路容易因路由缓存、组件复用而出错。更稳妥的做法是利用路由meta来控制：
// router/index.js const routes = [ { path: '/order', component: OrderPage, meta: { disableScale: true } }, { path: '/article', component: ArticlePage, meta: { disableScale: false } } ];然后在App.vue里监听路由变化，根据meta自动启用或关闭守卫：
<script setup> import { watch } from 'vue'; import { useRoute } from 'vue-router'; import { addScaleGuard, removeScaleGuard } from '@/utils/disableScale'; const route = useRoute(); watch( () => route.fullPath, () => { if (route.meta.disableScale) { addScaleGuard(); } else { removeScaleGuard(); } }, { immediate: true } ); </script>这样做的好处是，缩放开关和路由深度绑定，即使页面里有弹窗、底部弹层，也不会因为组件的挂载卸载而误触发缩放控制。我后来在项目里基本都是这种写法，比单纯在页面里调用工具函数要省心得多。
5. 实战避坑：表单聚焦、图片预览与iframe
在真机测试时，最常翻车的往往不是手势拦截逻辑本身，而是几个和缩放相关的“周边问题”。这里单独列一节，基本全都踩过。
5.1 输入框聚焦触发页面自动放大
在iPhone上，如果输入框的font-size小于16px，Safari在输入框聚焦时会自动把页面放大，好让用户看得清楚。这个放大行为和手势缩放不同，preventDefault是拦不住的，因为它是系统在键盘弹出前主动发起的调整。解决办法有两个。
一是把输入框的字号直接设置成16px或以上，这是最推荐的做法。很多UI库的默认字号都是14px，在移动端就要手动覆盖，我一般会在全局样式里针对input、textarea统一设置：
input, textarea { font-size: 16px; }二是配合meta的minimum-scale=1.0，让系统没有可放大空间。但要注意，iOS 15之后部分系统行为又有变化，最终还是要以真机验证为准。我在项目里往往两招一起上，表单页的所有输入控件都统一字号为16px，然后把viewport里的minimum-scale固定好，这样输入过程基本不会跳动。
顺便提一句，Android上由于键盘弹出往往采取adjustResize或adjustPan模式，页面也可能被压缩或平移。这本质上不是缩放，但视觉上很相似。如果遇到，需要从系统WebView的windowSoftInputMode配置入手，前端能做的并不多。
5.2 图片预览和地图场景需要临时放开
如果页面只有普通内容，禁用缩放无可厚非。但一旦涉及图片预览、地图、画板这类本身就依赖多指手势的场景，全局禁用缩放就是给自己挖坑。我在某个模拟项目中，把禁用缩放的代码放到App.vue全局执行，结果几乎所有图片预览控件的双指缩放全部失效，产品同事立刻反馈“图片放大不了”。
解决思路很简单，不要在App级一刀切，而是把禁用缩放的开关粒度下沉到具体页面或路由。比如订单详情页禁缩放，商品详情页的图片预览区域允许双指缩放。这时用前面封装的自定义指令v-no-scale就很合适，只在需要的页面挂上，而不会干扰图片预览组件。
如果已经全局注册了，想临时恢复，可以借助removeScaleGuard。在某个页面onMounted时先移除，等离开时再加回来。但这里要小心页面之间的状态恢复，最好使用路由守卫统一处理，或者干脆一开始就别用全局方案。
5.3 iframe里的页面禁缩放管不住
还有一种让人头秃的场景：H5页面里嵌了iframe，比如用iframe加载某个富文本内容或内部系统页面。iframe是独立文档，外层页面哪怕把缩放禁得死死的，iframe内部依然可以由用户缩放。想管住它，只能在iframe的src对应的HTML里同样加上viewport配置和JS拦截。
如果是第三方提供的iframe，没法改对方的HTML，那能做的就很有限。最多用sandbox属性限制iframe的一些交互能力，但对已加载页面内的手势缩放无能为力。遇到这类需求，最好推动业务方在服务端输出HTML时统一处理，这也是我参与过的几个项目里最终采用的方案。
6. 验收不能只看开发工具，这套真机清单请收好
做移动端H5禁用缩放，最怕的是开发环境一切正常、真机一测就打回原形。Chrome DevTools的设备模拟虽然方便，但它只是模拟了viewport和部分触摸行为，并不能完整复现系统内核对手势的处理。我见过太多次“模拟器里没问题，真机上一放大就崩”的案例。
所以我习惯在验收阶段准备一张“缩放拦截测试清单”，至少覆盖这些场景：
- iOS Safari（老版本如iOS 14/15，以及新版本iOS 16/17/18）
- Android原生浏览器 / Chrome
- 微信内置浏览器
- 各主流App的WebView壳
- 输入框聚焦、双击、双指捏合三个动作分别验证
在这个清单上，还要加上“局部恢复”的用例：如果某个页面允许图片放大，那么页面本身不能缩放，但图片预览组件内应该能正常双指放大；如果测试发现二者相抵触，说明事件拦截粒度还需要再调整。
另外一个小技巧：做移动端手势调试时，真机不方便看console，我通常会在电脑上通过远程调试工具来观察事件是否被正确拦截，这比反复真机截图高效很多。比如Android可以用Chrome的远程调试，iOS可以用Safari的开发者菜单，配合事件监听日志，基本能定位出是拦截逻辑没生效，还是浏览器内核压根没把事件冒泡出来。
根据我个人的实际经验，禁用缩放绝不是加一个meta标签就完事的问题。理想闭环是viewport锁参数、CSS辅助禁用双击语义、JS拦截双指和双击路径，三层缺一不可。同时要把开关粒度控制好，避免误伤图片预览、地图等真正需要缩放的场景。我后来做项目时，都会先和产品确认“全站禁缩放”还是“指定页面禁缩放”，确认后再决定是全局方案还是路由级方案。这个前置确认能避免后期大量返工，也是我在好几个项目里总结出来最实用的经验。
