移动端 H5 适配经典

• 三种方案的换算机制与原理
• 各自优缺点与适用场景
• vw 主流化的原因分析

三种方案核心都是"按视口等比缩放"：rem+flexible——flexible 库按屏幕宽度动态设置根字号，用 rem 换算（设计稿 750 除以 10），早年解决"设计稿转 rem"痛点，但依赖 JS 运行时注入、需处理 dpr 与字体缩放异常；vw/vh——直接以视口为基准单位（100vw = 视口宽度），CSS 原生计算、无 JS 依赖、换算直观（设计稿 750px 除以 7.5 即 vw），且天然适配旋转与动态视口；px+媒体查询——按断点整页切换布局（响应式），不缩放字体与细节，适合"设计稿差异大、按设备分段"的场景。vw 成为主流的理由：原生 CSS 能力免运行时依赖、与设计稿换算简单、随视口实时响应（键盘弹起、旋转）、配合 rem 做"vw 定布局 + rem 定字体"的混合方案，且现代浏览器对 vw/vh 与动态视口（dvh）支持完善，flexible 的 JS 方案逐步退出。工程上通常"vw 为主 + 临界点媒体查询 + 安全区适配"组合。

回答按"演进路径 → 三方案原理对比 → vw 主流化的三个理由"组织，突出"免 JS、原生、实时响应"的对比视角。

• WebView 的能力差异（UA、存储、后台）
• JSBridge 与原生能力调用
• Cookie 同步与缓存治理

WebView 与浏览器的差异与适配：能力差异——WebView 暴露的 API 与系统浏览器不完全一致（部分 API 缺失或行为不同），用能力检测与降级；UA 与标识——通过 UA/注入标识识别 WebView 环境（用于埋点与差异化逻辑）；后台行为——WebView 页面在 App 切后台时可能被冻结/销毁，需用 visibilitychange 与页面状态持久化适配。JSBridge 通信：通过注入 API（window 上的桥对象）或 URL Scheme 与原生双向通信，调用原生能力（登录、支付、分享），注意桥的可用性检测、回调超时与安全（协议校验、注入内容白名单）。Cookie 同步：App 内 WebView 与 App 原生网络栈的 Cookie 需同步（登录态贯通），用统一 Cookie 管理（原生注入、跨域共享策略、SameSite 兼容）；缓存策略：WebView 缓存（HTTP 缓存 + 本地存储）受 App 清理与更新影响，用版本化资源与 CDN 指纹控制，避免"旧缓存不更新"与"缓存过大"；离线包预加载可进一步提升首屏。

回答按"环境差异清单 → JSBridge 通信 → Cookie 同步 → 缓存策略"组织，突出"环境检测 + 桥接安全 + 缓存版本化"三个适配主线。

• 橡皮筋滚动与下拉刷新的机制
• overscroll-behavior 的兼容性
• 滚动锁定的方案与副作用

iOS 橡皮筋（rubber-banding）是 UIScrollView 的弹性回弹，下拉刷新是系统/浏览器手势，在 H5 中做弹层、横滑等场景需要禁用：overscroll-behavior 属性（contain/none）可禁用它触发的边界连锁行为——CSS 原生、零 JS，但兼容边界：iOS 16+ Safari 才开始支持（之前无效），且它禁的是"边界传递"与"刷新"（配合 touch-action），橡皮筋视觉弹性在部分 iOS 版本仍存在；兼容方案：对不支持的 iOS 用 JS 滚动锁定（阻止 touchmove 默认行为、记录滚动位置、overflow:hidden 切换）。body 滚动锁定的取舍：弹层打开时锁背景滚动——方案：overflow:hidden（简单但 iOS 上不总是生效、滚动位置丢失）、position:fixed 修复（保持位置但跳变/抖动）、touchmove preventDefault（精准但影响子滚动区域需配合判断）；现代方案用 overscroll-behavior: contain 减少副作用。取舍原则：优先 CSS（overscroll-behavior + touch-action），必要时 JS 兜底，并保留弹层内部滚动区域的事件透传。

回答按"问题机制 → overscroll-behavior 与兼容边界 → 滚动锁定方案对比 → 取舍原则"组织，突出"CSS 优先、JS 兜底、版本检测"。

• DPR 与物理像素的关系
• transform: scale(0.5) 的方案原理
• 其他方案（border-image、box-shadow）与取舍

成因：CSS 1px 是逻辑像素，高 DPR（如 2x/3x）设备上 1px 逻辑对应 2/3 物理像素，浏览器通常以"最接近的物理像素"渲染，导致 1px 线变粗（2 物理像素宽）或模糊。解决方案：transform 缩放——画 1px 元素的 2 倍尺寸后 scale(0.5)（或用伪元素 + scaleY(0.5)），精确映射到 1 物理像素，清晰且自适应 DPR（scale = 1/dpr），适合单侧边框与圆角场景，代价是实现复杂（伪元素、位置与圆角处理）；border-image——用 1px 渐变/图片做边框图，兼容性老、语法繁琐，已少用；box-shadow: 0 0.5px——依赖浏览器对亚像素的支持，非标准表现不稳定；viewport 缩放（flexible 的 dpr 方案整体缩放）——影响面大已弃用。现代取舍：优先 transform 缩放（可控、清晰），或接受 0.5px 线（部分浏览器支持 border 0.5px 渲染为细线）；用 CSS 变量与 mixin/工具类统一封装，避免散落。

回答按"成因（DPR 物理像素）→ 各方案原理 → 现代取舍"组织，突出"1/dpr 缩放"的本质与统一封装。

• 双击缩放手势导致延迟的成因
• meta viewport 与 pointer 事件的解决
• 点击穿透的机制与预防

300ms 延迟的历史成因：早期移动浏览器为支持"双击缩放"，单击后需等待约 300ms 判断是否第二击，导致所有点击响应延迟。解决状态：现代浏览器已消除——viewport 声明 width=device-width（禁用双击缩放语义）后不等待；部分浏览器对 touch-action: manipulation 声明不缩放元素同样消除；pointer 事件统一了触摸/鼠标语义，配合 touch-action 精确控制手势；此外 Chrome 对滚动容器内的点击也不等延迟。点击穿透：触摸点击触发后，300ms 内若元素消失（弹层关闭、跳转），后续合成 mouse 事件会落到下方元素（如触发按钮/链接）；预防：用 touch 事件即时处理（touchstart/touchend 判断）、弹层关闭用 CSS transition 延迟移除、或整体监听并阻止合成事件。工程注意点：现代项目不再需要 fastclick 类库（引入反而引入新问题），用 pointer/touch 事件 + touch-action 即可；测试真机手势与快速连击场景。

回答按"历史成因 → 现代解决机制（meta/touch-action/pointer）→ 点击穿透原理与预防 → 工程结论"组织，给出"不再需要 fastclick"的准确现状。

• 手势冲突的典型场景
• touch-action 与事件处理的分工
• 冲突协调的工程模式

手势冲突的典型场景：页面内部横向滑动（轮播、抽屉）与纵向滚动；H5 滚动区域与原生手势（返回手势、下拉刷新、边缘滑动）；弹层打开时背景滚动。协调机制分三层：CSS 层——touch-action 声明元素允许的手势（pan-y 允许纵向滚动、禁止横向/缩放），让浏览器原生解析手势归属（滚动容器内横向拖拽不触发页面滚动）；事件层——JS 按手势方向与起始位置裁决（记录 touchstart 坐标，比较位移方向：横向优先转轮播，纵向转滚动），配合 pointer 事件统一；容器层——滚动区域独立（内部 overflow 滚动，外部锁定）、弹层用滚动锁定。下拉刷新与页面滚动：刷新触发条件是"页面在顶部且向下拖拽"，实现上监听 touchstart 于顶部 + 位移阈值判定，用 touch-action: pan-y 允许纵向（避免浏览器与 JS 双抢手势），或直接禁用原生下拉用自定义刷新。工程模式：把"手势裁决"收敛为统一的 gesture 工具（方向判定、区域判定、事件分发），避免各组件各自为政。

回答按"场景清单 → CSS/事件/容器三层机制 → 下拉刷新专项 → 统一裁决工具"组织，突出"touch-action 优先、JS 裁决兜底"。

• 首屏渲染链路与白屏优化
• JS 执行与长任务治理
• 图片懒加载/预加载的策略

首屏白屏优化按渲染链路拆解：网络层——CDN、HTTP/2、资源合并与压缩、离线包/预加载 HTML；解析层——入口 HTML 精简、关键 CSS 内联（避免 CSS 阻塞渲染）、script 加 defer/async 或拆分关键路径；渲染层——首屏只渲染可视区域、骨架屏占位（内容就绪替换）、字体子集化避免 FOIT。JS 执行阻塞治理：长任务（Long Task）拆分（切片、requestIdleCallback 分批）、重逻辑迁移（Web Worker）、按需加载（路由级拆包、动态 import）、避免主线程大对象计算（虚拟列表）；用 Performance 面板与 RAIL 模型定位。图片策略：懒加载——滚动进入视口才加载（loading="lazy" 或 IntersectionObserver），适合长列表图片；预加载——首屏关键图用 或 JS 提前请求（连接复用），适合首屏大图/轮播；配合尺寸占位（aspect-ratio 防布局抖动）、WebP/AVIF 与 srcset 响应式、CDN 裁剪参数。取舍：按"图片在首屏与否 × 体积大小"决定懒/预，并设性能预算与 CI 观测。

回答按"首屏链路优化 → JS 长任务治理 → 图片策略选型 → 预算与观测"组织，突出"分阶段拆解 + 按需加载"的方法论。

• 键盘弹起的 viewport 变化机制
• iOS 与 Android 的行为差异
• 输入框遮挡与布局适配方案

键盘弹起本质是"视觉视口变化"：Android（部分版本）与 iOS 都可能在键盘弹起时触发 visualViewport 缩小（resize），固定定位元素与视口单位（100vh）随之变化，出现输入框被遮挡、固定按钮上移/跳动。平台差异：iOS Safari 键盘弹起不触发 window resize（历史行为），用 visualViewport.resize 事件感知；Android Chrome 默认 resize 并可用 meta viewport 的 interactive-widget 新特性（resizes-visual/content）声明行为；Android 的 adjustResize/adjustPan（原生侧）影响 WebView 高度。适配方案：输入框聚焦时用 scrollIntoView/滚动补偿（iOS 需延迟滚动）；固定底部按钮改为跟随视口（visualViewport 高度计算）或输入时收起到安全区上方；避免用 100vh 做全屏布局（用 100dvh 或 JS 高度）；弹层内输入时锁定外部滚动。工程要点：visualViewport 事件统一封装（含 resize/offsetTop 补偿）；真机多机型验证（键盘高度差异大）；必要时原生侧配置（soft input mode）配合。

回答按"变化机制 → 双平台差异 → 适配方案（聚焦滚动/动态单位/visualViewport）→ 验证治理"组织，突出"visualViewport 感知 + dvh 单位"的现代做法。

• rem/vw 的换算与联动原理
• 字体、1px 与安全区的边界
• 混合方案的工程实践

原理：vw 以视口宽度为基准（1vw = 1% 视口宽），设计稿 750px 转 vw 即除以 7.5（2x 设计稿按 375 逻辑宽换算）；rem 以根字号为基准（html font-size 动态设置，如视口宽度/10），页面内 rem 随之缩放。边界问题：字体——纯 rem 缩放字体在极端宽度下过大/过小，常用"vw 定布局 + 固定 px 或 clamp() 定字号"；1px——vw/rem 缩放不改变"1px 是逻辑像素"的本质，细线问题仍按 DPR 方案处理，且 vw 布局中的边框建议用物理像素方案；安全区——刘海屏的 env(safe-area-inset-*) 与 vw 布局叠加时，底部/左右留白按安全区计算（max() 组合）；动态视口——键盘弹起/浏览器工具栏收合时 100vh 抖动，用 dvh 或 visualViewport 适配；超大/超小屏——vw 布局在极端宽度（折叠屏）需配合 max-width 容器与媒体查询限幅。工程实践：统一换算工具（postcss-px-to-viewport 等）与 CSS 变量，避免手写换算漂移。

回答按"原理 → 三类边界（字体/1px/安全区）→ 动态视口与极端屏 → 工具化"组织，突出"vw 布局 + 物理像素与安全区专项兜底"。

• 布局视口与视觉视口的定义
• meta viewport 的 width/initial-scale 语义
• 视口配置的工程要点

移动端视口分两层：布局视口（layout viewport）——页面 CSS 布局的坐标基准，默认宽度大于屏幕（iOS 980px），导致 PC 页面缩小显示；视觉视口（visual viewport）——屏幕实际可见区域，浏览器缩放与键盘弹起改变的是它；meta viewport 的作用是让布局视口对齐设备宽度：width=device-width 把布局视口设为设备逻辑宽度（消除缩放显示）、initial-scale=1 初始缩放 1:1、user-scalable=no 禁用缩放（注意无障碍取舍，可用 maximum-scale=1 替代）、viewport-fit=cover 扩展至全面屏（配合安全区）。工程要点：width=device-width 是移动端适配的地基（没有它 vw/rem 都失真）；布局视口宽度决定 vw 基准（未设置时按 980 计算导致换算错误）；iOS 的 viewport-fit=cover 需配合 env() 处理刘海遮挡；视觉视口变化（键盘、双指缩放）用 visualViewport API 感知。

回答按"双层视口概念 → meta 字段语义 → 工程要点（基准、全面屏、感知）"组织，突出"布局视口=CSS 基准、视觉视口=可视区域"的区分。

• safe-area-inset 的四个值
• viewport-fit=cover 的配合
• 典型场景（底部栏、顶部栏、横屏）

刘海屏安全区由 env(safe-area-inset-top/right/bottom/left) 提供（单位 px，随设备与方向变化）：配合 meta viewport 的 viewport-fit=cover（页面扩展到全面屏区域）后，用 env() 为被刘海/圆角/手势条遮挡的区域留白。典型用法：底部 Tab/悬浮按钮 padding-bottom: env(safe-area-inset-bottom)（底部手势条）；顶部状态栏区域 padding-top: env(safe-area-inset-top)（非全屏应用一般由系统避让，全屏/沉浸式场景需要）；横屏时左右 inset 生效（侧边圆角）。注意点：env() 在不支持的浏览器/设备中无效，用 max(12px, env(safe-area-inset-bottom)) 形式保证默认值兜底（CSS 变量组合）；inset 值在滚动/非滚动上下文都可能为 0（元素是否贴边），需按"元素是否接触屏幕边缘"判断；键盘弹起时底部 inset 可能为 0（软键盘接管），组合 visualViewport 处理；iOS 与 Android 刘海形态不同，用真机矩阵验证；避免把 inset 写死为固定值（机型差异）。

回答按"机制（inset+viewport-fit）→ 三场景用法 → 兜底与平台差异"组织，突出"max() 兜底与贴边判断"两个实践细节。

• 真机页面内调试工具（vConsole/eruda）
• Chrome USB 远程调试与 Safari Web Inspector
• 按场景选择调试组合

三套方案覆盖不同场景：vConsole/eruda——注入页面内的轻量调试台（console、网络、存储、元素），无需连接线、随页面运行，适合真机直接验收、现场问题复现、线上灰度环境排查；Chrome Remote Debugging——Android 手机 USB 连接 + Chrome DevTools 远程调试（完整 DevTools：断点、性能、网络、元素），适合复杂逻辑与性能分析；Safari Web Inspector——iOS 设备经 Safari 开发者菜单连接（需开启 Web 检查），能力完整但仅限 macOS 连接 iOS。选择与组合：开发期用 Remote Debugging/Web Inspector（完整工具链）；联调与验收用 vConsole（随时随地、可交给测试）；线上问题用 vConsole 注入 + 日志上报（错误、网络快照）组合定位；注意 vConsole 的生产注入策略（按环境开关、体积小、勿泄露敏感信息）；Android 用 USB 调试时注意 Chrome 版本匹配与 adb 环境；iOS 需在设置开启"网页检查器"。

回答按"三方案机制与能力 → 场景选择矩阵 → 工程治理（注入开关与日志）"组织，突出"完整 DevTools 用于开发、vConsole 用于现场"的分工。

• 300ms 延迟的成因与消除条件
• touch 事件模型与合成事件
• 基于 touch 的交互优化实践

300ms 延迟成因与现状：源于双击缩放判定，现代浏览器在 width=device-width 或 touch-action: manipulation 下已消除，无需 fastclick；但"手势与点击混合"场景（滑动容器内点击、长按）仍需理解事件时序。touch 事件模型：touchstart/touchmove/touchend 提供原始触摸流，浏览器在 touchend 后合成 mouse/click 事件（有延迟窗口，元素变化时产生穿透）；touch-action 声明可让浏览器"不等待"直接派发 click（关键优化）。touch 优化实践：即时响应——点击态（高亮、按压反馈）在 touchstart 触发而非等待 click；防误触——滑动阈值判断（位移超阈值视为滚动，不触发点击），touchend 时校验；长按/连击——计时器区分 tap/longpress/doubletap；穿透防护——处理 touch 后 preventDefault 合成事件（注意全局阻止会影响滚动，需按场景）；优先 pointer 事件（统一鼠标/触摸/笔，含 pointerdown/pointerup 与 touch-action 配合）而非裸 touch，减少双端事件逻辑。性能：touch 高频事件（touchmove）节流与 passive 监听（不 preventDefault 时）避免滚动卡顿。

回答按"延迟现状 → touch 事件模型 → 交互优化实践（即时响应/阈值/穿透）→ pointer 与 passive 建议"组织，突出"现代浏览器已免延迟、优化焦点转移到手势体验"。

• 两类通信机制的原理
• 桥接层的设计与安全
• 兼容与降级策略

URL Scheme：H5 通过跳转自定义协议（myapp://action?param=）唤起原生，原生解析 scheme 分发；优点是无注入依赖（WebView 都能用）、可用于唤起外部 App；缺点是传参受限（URL 长度）、易被劫持（scheme 冲突）、回调困难。JSBridge：原生向 window 注入桥对象（window.WebViewJavascriptBridge 等），H5 直接调用（同步/异步 callback），双向实时通信；现代实现多用 addJavascriptInterface（Android）/WKScriptMessageHandler（iOS）承载，性能与安全性优于 scheme。桥接层设计：统一 API 封装（promise 化、方法注册表、参数校验）、回调管理（唯一 id + 超时）、能力检测（桥存在性、方法存在性）、错误码统一；安全：注入内容校验、敏感能力需原生侧授权、防 scheme 注入（参数编码校验）、禁外部页面（白名单 origin）调用桥。兼容策略：优先 JSBridge（性能），scheme 兜底（降级唤起/老容器）；用统一 facade 隔离两端实现，便于容器升级。

回答按"两机制原理对比 → 桥接层设计（封装/回调/检测）→ 安全治理 → 兼容降级"组织，突出"桥优先、scheme 兜底"与"facade 隔离"。

• 两类事件模型的设计差异
• pointer 事件的统一性与特性
• 手势开发的选型建议

差异本质：touch 事件（touchstart/move/end）只面向触摸设备，事件对象提供 touches/changedTouches（多点触摸列表），无鼠标语义；pointer 事件（pointerdown/move/up）统一鼠标、触摸与笔，pointerType 区分来源，支持 pointerId（多点）、悬停（hover）语义与捕获（setPointerCapture）——同一套逻辑适配全输入设备。工程差异：兼容性——pointer 事件在 iOS Safari 13+ 支持（此前需 polyfill），现代项目可用；多点触摸——touch 用 touches 数组、pointer 用 pointerId 区分多指；手势系统（如 hammer.js/手势库）两种都能封装，但 pointer 事件配合 touch-action 是官方推荐路径（浏览器原生手势解析，减少 JS 拦截）；事件合成——两者最终都会合成 click，穿透与时序问题处理思路一致。选型建议：新项目优先 pointer 事件（统一、标准、配合 touch-action），需要精细多点逻辑（捏合、旋转）时用 pointerId 管理指针集合，或用成熟手势库（其底层已适配）；老旧容器（低版本 WebView）保留 touch 兼容分支或库兜底。

回答按"事件模型差异 → 多点与捕获机制 → 兼容现状 → 选型建议"组织，突出"pointer 统一输入源 + touch-action 原生解析"的现代实践。

• 真机调试的接入方式（远程调试/注入）
• vConsole 的实践用法
• 调试到线上排障的闭环

真机调试接入分两类：开发期——Android 用 Chrome Remote Debugging（USB + adb 转发端口），iOS 用 Safari Web Inspector（macOS 连接），可断点、看网络与性能；验收期——vConsole/eruda 注入页面（构建期按环境注入或动态加载），真机直接看 console、网络请求、存储与页面结构，无需数据线，适合交给测试与产品走查。vConsole 实践：按环境开关（dev/qa 注入、生产默认关闭，避免体积与信息暴露）；提供"开启调试"入口（特殊手势/URL 参数）用于线上问题现场取证；结合日志上报（错误、网络快照、用户操作）在 vConsole 查看的同时留痕，形成"现场查看 + 后端分析"闭环。工程要点：vConsole 的版本与 WebView 兼容（老容器选低版本）、与第三方脚本（统计、监控）的冲突排查；真机矩阵（iOS/Android 各版本）建立标准调试 SOP（连接方式、注入开关、日志抓取），缩短"复现-定位"链路。

回答按"开发期远程调试 → 验收期 vConsole → 线上取证与日志闭环 → 团队 SOP"组织，突出"工具按阶段分工、注入策略可控"。

• 字号自动放大的触发条件与机制
• format-detection 的电话号码识别
• 对应的 CSS 与 meta 适配

iOS Safari 的字号自动放大：页面（或元素）中文字在未禁用缩放时，横向排布的文字被自动放大以适配屏幕（历史上为 PC 布局优化），导致字号与设计稿不符、换行异常；通过 CSS 的 -webkit-text-size-adjust: 100% / none 禁用（现代标准 text-size-adjust 已标准化），且 viewport 设置 width=device-width 后现代 iOS 不再放大（历史版本仍需属性兜底）；注意 100% 与 none 的语义差异（none 完全禁止，100% 允许但等比例）。电话号码识别：iOS Safari 把形似电话的文本自动转为可拨打的链接（tel:），带来样式与误识别问题（数字串、订单号被链接化）；通过 meta 的 format-detection: telephone=no 关闭，或对指定元素用 x-apple-data-detectors 属性（iOS 私有）局部控制；需要"可拨打"的场景保留识别并配合 tel: 链接样式。工程要点：全局 meta（format-detection）与 CSS（text-size-adjust）统一配置于模板；局部豁免（如地址簿场景保留检测）按业务声明；真机验证横竖屏与老 iOS 版本行为。

回答按"两机制的原理 → 对应适配手段（CSS/meta/属性）→ 保留场景与验证"组织，突出"全局关闭、按需开放"的配置策略。