Infinix机型适配必须用width=device-width+initial-scale=1.0，禁用user-scalable=no；CSS优先rem动态计算根字体；触控需同时监听touchstart和click并preventDefault；安全区须用viewport-fit=cover配合env()函数。
viewport 设置必须加 width=device-width，别信“固定 320”老方案
Infinix 大部分中低端机型（如 HOT 系列、SMART 系列）用的是 Android 11/12 + Mediatek 芯片，WebView 内核较新（Chrome 90+），但默认会启用兼容模式。如果你还在用 这类硬编码宽度，页面会在 Infinix 手机上被强制缩放、文字糊、按钮点不中——因为它的物理屏幕宽度普遍是 360px–412px（比如 Infinix NOTE 30 是 393px），根本不是 320。
-
width=device-width是唯一可靠起点，它让浏览器读取设备真实的 CSS 像素宽度（非物理像素） - 务必搭配
initial-scale=1.0，否则某些 Infinix 系统会默认放大 1.2 倍（尤其在开启「字体增大」系统设置时） - 禁用
user-scalable=no：Infinix 用户常手动双指缩放，强行禁用会触发无障碍审查失败，且部分机型（如 X6815）会直接忽略该属性反而导致布局错乱
CSS 单位优先用 rem + 动态根字体计算，别依赖 vw 或百分比
Infinix 的屏幕密度跨度大（1.5x 到 3.0x 都有），vw 在低分辨率屏（如 HOT 40 的 720×1600 屏）上容易导致文字过小；纯百分比又难控行高和间距。最稳的仍是 rem，但必须动态算，不能写死 html { font-size: 100px }。
- 用 JS 按设备宽度动态设根字号：例如以 375px 为基准，
document.documentElement.style.fontSize = document.documentElement.clientWidth / 375 * 100 + 'px'; - 注意：Infinix 部分机型（如 SMART 8）在横屏切换瞬间会触发两次 resize，需加节流或用
orientationchange事件兜底 - 避免用
em嵌套，Infinix 的 WebView 对嵌套继承计算偶有偏差，rem直接锚定 root 更可控
触控交互必须同时监听 touchstart 和 click，别只写 click
Infinix 的触控固件响应延迟略高（实测平均 80–120ms），只绑 click 会出现明显卡顿、点两下才触发，用户感知就是“按钮失灵”。而单纯用 touchstart 又会在桌面调试时失效。
- 正确做法是：两个事件都监听，用
event.preventDefault()阻止 click 的 300ms 延迟，再统一调用处理函数 - 别用
fastclick这类旧库：Infinix Android 12+ 已原生支持touch-action: manipulation，加这句 CSS 就能消除延迟 - 测试重点：在 Infinix NOTE 30 上连点 5 次按钮，看是否全部触发且无重复 —— 这是判断触控适配是否到位的最简验证
安全区（Safe Area）要主动适配，尤其顶部状态栏和底部导航条
Infinix 的全面屏机型（如 X6815、NOTE 30）都有异形屏，顶部状态栏高度不固定（从 24px 到 44px 不等），底部也有虚拟导航条。若没处理，header 会被截断、返回按钮被遮挡。
立即学习“前端免费学习笔记（深入）”；
- 必须加
，否则env(safe-area-inset-top)不生效 - 顶部留白用：
padding-top: env(safe-area-inset-top, 24px);（24px 是 fallback） - 底部留白同理：
padding-bottom: env(safe-area-inset-bottom, 0);，但注意 Infinix 的虚拟导航条高度常为 48px，需在 JS 中用window.innerHeight - screen.height校验后覆盖
真正麻烦的不是代码怎么写，而是 Infinix 机型碎片化太严重：同一型号不同批次可能预装不同版本 WebView，有些甚至关掉了 device-pixel-ratio 检测。上线前至少要在 HOT 40、SMART 8、NOTE 30、X6815 四台真机上跑通 touch、resize、safe-area 三个关键链路，模拟器完全不可信。
