根本原因是字体小于16px触发iOS系统级缩放；仅设viewport无效，必须配合input、textarea、select、[contenteditable]的font-size:16px!important生效。
直接结论：iOS 表单元素 focus 时页面放大，根本原因是字体小于 16px 触发了系统级缩放逻辑；仅靠 viewport 设置无法根治，必须配合 font-size: 16px 强制生效。
为什么只设 viewport 无效
iOS 的自动放大行为和 user-scalable=no 是两套机制：前者是 Safari 内部对小字体输入框的“可访问性优化”，后者只是禁用用户双指手势。实测中，即使 maximum-scale=1 + user-scalable=no 全开，只要 input 或 textarea 的计算后 font-size ＜ 16px（比如继承了 14px 或被 rem 算成 15.2px），放大仍会发生。
-
initial-scale=1、minimum-scale=1属于冗余项，现代 iOS（截至 2026 年）不依赖它们抑制聚焦放大 -
shrink-to-fit=yes已废弃，Safari 不识别，加了反而可能干扰渲染 -
apple-mobile-web-app-capable=yes只影响是否隐藏 Safari UI，和缩放无关
font-size: 16px 必须作用在哪些元素上
不是只写 input { font-size: 16px } 就够——iOS 会检查所有可能触发键盘的焦点元素的实际渲染字号：
- 显式声明：
input、textarea、select、带contenteditable属性的元素（如富文本编辑器容器） - 必须覆盖伪类：
input:focus、textarea:focus等不能意外重置字号 - 注意继承链：如果父级设了
font-size: 14px，子元素用em或无单位值会继续缩小，建议统一用px或rem配合根字体校准
推荐写法：
input, textarea, select, [contenteditable] { font-size: 16px !important; }
常见踩坑点：你以为设了 16px，其实没生效
以下情况会导致 font-size 实际未达 16px，放大照旧：
- CSS 优先级被更高权重规则覆盖（比如组件库内联样式、
!important冲突） - 使用了
transform: scale()缩放过整个表单区域，导致字体物理像素变小 - 媒体查询中在某些断点把
font-size改成了14px，而该断点恰好匹配当前设备 - 通过 JS 动态修改了
style.fontSize，但未同步更新到:focus状态
验证方法：真机调试时，在 Safari 开发者工具中选中输入框，查看 Computed 标签页下的 font-size 值，确认是精确的 16px（不是 15.99px 或 16.0000000001px）。
要不要加 JavaScript 补丁
绝大多数场景下不需要。JS 方案（如监听 gesturestart 或动态改 viewport content）属于兜底手段，问题在于：
- 改
viewport属性会触发页面重排，可能造成视觉闪动 - 部分 iOS 版本对动态修改
viewport的响应不一致（尤其 iOS 17+） - 若用户已开启“辅助功能 → 更大字体”，强制设
16px可能违背其系统偏好
真正需要 JS 的只有两类例外：一是遗留项目无法修改全局 CSS；二是必须支持极小字号设计（如仪表盘紧凑表单），此时才考虑用 document.addEventListener('focusin', ...) 暂时禁用缩放，失焦后恢复。
最稳妥的做法永远是：确保所有可聚焦表单控件的最终渲染 font-size ≥ 16px，且 viewport 中保留 maximum-scale=1 和 user-scalable=no 作为辅助防线。其他花哨技巧，基本是给没调通 CSS 的人准备的备用方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
