maximum-scale 是硬性缩放上限，需与 user-scalable=yes 和 minimum-scale 配合使用；单独设为 1.0 或搭配 user-scalable=no 会导致缩放被禁用；ios 10+ 弱化其约束，android 需 setsupportzoom(true) 才生效。
直接用 maximum-scale 控制最大缩放，看似简单，实则容易踩坑。它必须和 user-scalable=yes、minimum-scale 配合使用才有效，单独写或设为 1.0 往往导致缩放被完全锁死，反而无法双指操作。
maximum-scale 的作用机制
它不是“建议值”，而是硬性上限：用户双指放大时，页面缩放比例一旦达到该数值，手势就会停止响应。但这个限制只在缩放功能本身被启用的前提下生效。
-
maximum-scale=5.0表示允许放大到原始尺寸的 5 倍 - 若同时设
user-scalable=no，则maximum-scale被忽略，缩放整体失效 - 若只写
maximum-scale=1.0（不配minimum-scale），iOS 会默认将缩放范围锁定在 1.0，等效于禁用缩放
正确写法与常见错误对比
✅ 推荐写法（开启缩放并设合理范围）：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
❌ 典型错误写法：
-
maximum-scale=1.0单独存在 → 页面彻底不能放大，连辅助阅读缩放也被屏蔽 -
user-scalable=no和maximum-scale同时出现 → 后者无效，且失去所有缩放能力 -
maximum-scale=10但没写minimum-scale→ 在部分 Android WebView 中可能被降级处理，行为不稳定
不同平台对 maximum-scale 的实际表现
iOS（WKWebView）从 iOS 10 起已弱化对 maximum-scale 的强制约束，尤其在辅助功能开启时；而 Android WebView 默认更严格，但需原生层先调用 setSupportZoom(true) 才会让该属性起作用。
- 鸿蒙 Web 组件支持
maximum-scale，但若设为1.0，同样会抑制双指手势识别 - Chrome for Android 以
user-scalable=yes为前提，maximum-scale才参与计算缩放边界 - 不要依赖它做“防误触”——真正需要禁用缩放，应结合 CSS
touch-action: manipulation或原生层拦截
替代思路：比 maximum-scale 更稳妥的控制方式
如果目标是“允许适度放大但防止过度拉伸”，与其强依赖 maximum-scale，不如：
- 用 CSS
transform: scale()+ 容器overflow: hidden实现可控局部缩放 - 监听
visualViewport的scale属性，在 JS 中动态限制（适用于复杂交互场景） - 在原生层（如 Capacitor 插件）统一管理缩放开关，HTML 层只保留基础 viewport 声明
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
