ios safari硬编码16px阈值是webkit内核的可访问性策略，用于确保小屏设备文字可读；只要input等元素最终渲染font-size＜16px（含15.99px），就强制放大视口，必须通过computed面板验证真实像素值。
为什么iOS Safari会硬编码检查16px这个阈值
iOS Safari 的缩放行为不是 bug，是 WebKit 内核写死的可访问性策略：只要 input、textarea、select 或带 contenteditable 属性的元素，其最终渲染的 font-size 小于 16px，就强制放大视口。它不看你的 CSS 声明，只认 Computed 面板里那个像素值——15.99px 就算触发，16px 才算过关。
哪些写法看似写了16px但实际无效
常见掉坑点全在「计算结果」上，不是你写了多少行 CSS，而是浏览器最终渲染出什么：
-
html { font-size: 14px }+input { font-size: 1.143rem }→ 实际 ≈ 15.99px（浮点误差被 Safari 判为 - 父容器设了
font-size: 0.875em，子input继承后直接掉到 14px -
font-size: clamp(14px, 4vw, 16px)在 320px 宽度下，4vw = 12.8px，低于阈值 - 第三方组件（如
<van-field></van-field>）用内联 style 覆盖了你的font-size
必须同时覆盖的元素和伪类
只写 input, textarea 不够，iOS 同样会检查这些能唤起键盘的节点：
-
select下拉框 -
[contenteditable]富文本编辑器容器（比如 Quill 的根div） - 所有带
contenteditable="true"的元素，哪怕只是<span contenteditable></span>
而且必须显式加 :focus 规则，否则某些框架在聚焦时动态加 class 可能导致字号回落：
input, textarea, select, [contenteditable] {
font-size: 16px !important;
}
input:focus, textarea:focus, select:focus, [contenteditable]:focus {
font-size: 16px !important;
}
-webkit-text-size-adjust: 100% 的真实作用
这个属性不是“禁用缩放”，而是告诉 Safari：别对这个元素的文本做二次字号重计算。但它有个前提——只在 font-size ≥ 16px 时才生效：
- 写在
body上会干扰正文可读性，必须和font-size同级作用于表单元素 -
-webkit-text-size-adjust: none在 iOS 10+ 已废弃，部分版本反而失效 - 推荐组合：
font-size: 16px !important; -webkit-text-size-adjust: 100%;
真机调试时，直接打开 Safari 开发者工具看 Computed 面板里的 font-size 值，比猜配置靠谱得多。最易被忽略的从来不是怎么写，而是字号在继承链里怎么一步步被压缩掉的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
