移动端适配需协同视口控制、单位选择与响应式断点：viewport meta须正确设置minimum-scale和maximum-scale；优先用vw/vh替代rem，平板768px起切回px；img/video须设max-width:100%并用srcset适配DPR。
移动端适配不是靠「加个 meta 标签」就完事的，核心在于视口控制、单位选择和响应式断点三者协同。单独改 viewport 或只用 rem 都会翻车。
viewport meta 必须写对，且不能被覆盖
常见错误是复制粘贴了过时模板，比如漏掉 user-scalable=no（虽不推荐禁缩放，但至少得显式声明），或写成 width=device-width, initial-scale=1.0 却没加 maximum-scale=1.0 导致 iOS 双击放大失灵。
正确写法（兼顾可访问性与控制）：
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=5">
-
minimum-scale=1防止用户误操作缩得太小看不清 -
maximum-scale=5留出辅助阅读空间，比user-scalable=no更友好 - 不要在 JS 里动态重写
<meta name="viewport">，iOS Safari 会忽略第二次设置
用 viewport 单位替代 rem 做流体布局
很多项目还在用 lib-flexible + rem，但现代方案更轻量、更可靠：直接用 vw/vh 配合媒体查询微调。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
例如按钮高度适配不同屏幕：
button {
height: 8vw; /* 在 iPhone SE 上约 32px，在 iPad 上约 64px */
font-size: 3.5vw;
}
@media (min-width: 768px) {
button {
height: 48px; /* 平板统一为固定值，避免过大 */
font-size: 16px;
}
}-
vw基于视口宽度，比rem少一层 JS 计算，无 FOUC 风险 - 平板（
768px起）建议切回 px，因为物理像素密度差异大，纯vw容易让文字在 iPad 上过小或过大 - 慎用
vmin/vmax，Android WebView 对它们的支持不稳定
图片和视频必须设 max-width，且优先用 srcset
移动端最常出现的布局崩坏，90% 来自未约束的 <img alt="HTML5建模移动端适配怎么做_手机平板显示优化技巧【技巧】" > 或 <video></video>。即使父容器用了 flex，原生宽高的媒体元素仍会撑破布局。
基础防御写法：
img, video {
max-width: 100%;
height: auto;
}但仅这样不够——还要按设备像素比加载合适尺寸：
<img src="cat-400.jpg" srcset="cat-400.jpg 1x, cat-800.jpg 2x, cat-1200.jpg 3x" alt="cat" >
-
srcset比<picture></picture>更轻量，适用于大多数场景 - 不要依赖 JS 检测 DPR 后再换图，CDN 和浏览器原生支持更稳
- 视频建议加
controls和playsinline，否则 iOS 全屏播放会中断页面流程
真正难的是处理「非标准平板」——比如折叠屏展开后视口宽度突然变成 1200px，但 DPR 还是 2。这时候光靠 @media (min-width) 不够，得结合 screen.width 和 window.devicePixelRatio 做运行时判断，但别在首屏 JS 里做，容易卡住渲染。
