viewport需动态适配而非依赖initial-scale=1.0；rem+px混合单位更可控；grid替代flex提升兼容性；data-属性标记平台优于UA判断；优先保障主流环境而非过时内核。
用 viewport 元标签控制初始缩放，但别信“万能值”
移动端默认缩放常导致布局错乱，viewport 是第一道防线，但 width=device-width, initial-scale=1.0 并不总适用：
- 安卓 WebView 旧版本对
initial-scale解析不稳定，建议显式加maximum-scale=1.0, user-scalable=no（仅限纯展示页，交互页慎用） - iOS Safari 在横屏时可能忽略
width=device-width，可补minimum-scale=1.0防止意外缩放 - 某些折叠屏设备返回
screen.width是展开后宽度，但viewport仍按折叠态解析，此时靠 JS 动态写入更可靠
用 rem + px 混合单位做弹性基础，而非纯 vw/vh
vw 看似跨端友好，但实际在微信内置浏览器、QQ 浏览器等环境下存在 1–2px 渲染偏差，且无法适配系统字体缩放设置；rem 更可控：
- 根字体大小统一用 JS 设置：
document.documentElement.style.fontSize = window.innerWidth / 375 * 16 + 'px'（以 375px 设计稿为基准） - 关键像素级元素（如 1px 边框、图标尺寸）保留
px，避免rem在小屏下缩到不可见 - 文字字号优先用
rem，但需配合min-font-size（通过clamp()或媒体查询兜底），防止 iOS “大号字体”模式下文字过大撑破容器
结构上回避依赖 flex 单一轴向，改用 display: grid + minmax()
很多“跨端崩塌”源于 flex-wrap 在低端 Android Webview 中行为不一致，或 flex-basis 计算逻辑差异；grid 兼容性已足够（iOS 10.3+、Android 5.0+ Chrome 内核均支持）：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))替代flex-wrap实现响应式卡片流 - 行高控制不用
line-height固定值，改用grid-row-gap+align-items: start，避免多行文本在不同引擎中基线对齐偏差 - 绝对定位元素的
top/left值尽量用rem或百分比，少用vh——部分 Android 系统软键盘弹出时vh会错误重算
用 data- 属性标记平台特征，而不是 UA 字符串硬判断
直接解析 navigator.userAgent 容易误判（尤其微信、飞书、钉钉等容器 UA 混杂），更稳妥的是由宿主环境注入特征标识：
立即学习“前端免费学习笔记（深入）”；
- 让客户端在初始化时往
写入data-platform="wechat"、data-os="ios"、data-webview="true" - CSS 中用属性选择器精准控制：
[data-platform="wechat"] .btn { padding: 12px 24px; }，避免 JS 多次读取 UA - 若必须运行时探测，优先查
navigator.standalone（iOS PWA）、window.webkit（Safari）、WebViewJavascriptBridge（微信）等稳定 API，而非字符串匹配
真正难的不是写兼容代码，而是识别哪些“兼容”其实是伪需求——比如为已停止维护的 UC 内核加 hack，不如把测试资源投在微信安卓最新版和鸿蒙 WebView 的边界 case 上。
