viewport标签必须置于HTML头部最前面，正确写法为，否则iPad等设备会以980px渲染导致@media失效。
viewport 标签必须放在 最前面
没有它，iPad 浏览器会按约 980px 宽度渲染，@media 规则根本不会触发。常见错误是把它写在 <link rel="stylesheet"> 后面，或漏掉 width=device-width——只写 initial-scale=1.0 不够。
正确写法（且必须置于所有 CSS/JS 引用之前）：
<meta name="viewport" content="width=device-width, initial-scale=1.0">
- iOS 和 Android Safari 都依赖这个值来激活响应式行为
- 用 Chrome DevTools 切换 iPad Pro 模拟器，Elements 面板里显示的 viewport 宽度应为 1024（横屏）或 768（竖屏），不是 980
- 别加
maximum-scale=1.0或user-scalable=no，会破坏可访问性
断点别硬套 768px，改用 min-width 渐进增强
直接写 @media (max-width: 768px) 会让很多平板（如 iPad Air 竖屏 820px、Surface Pro 竖屏 1080px）落在“无样式区间”，导航栏既不收缩也不展开。
更可靠的做法是移动优先 + 内容驱动断点：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 基础导航默认用
flex-direction: column、font-size: 1rem、width: 100% - 从
@media (min-width: 768px)开始适配竖屏平板：让导航项横向排列、增加内边距、启用 hover 效果 - 再加一层
@media (min-width: 1024px)处理横屏平板和小桌面：比如把 logo 和搜索框拉到同一行，或给导航项加min-width: 120px防文字挤缩 - 断点值不要查设备列表，而是拖动浏览器窗口，观察导航文字何时开始换行、间距是否过紧——那个宽度就是你的断点
导航项宽度和字体在平板上容易溢出
平板屏幕宽高比特殊，white-space: nowrap + font-size: 1.1rem 很容易导致文字撑破容器或折行错位。
- 每个导航项内文字用
max-width: 20ch限宽（比 px 更贴合实际字宽） - 避免锁死高度，改用
height: clamp(48px, 4.5vh, 72px)，兼顾触控点击区与视觉比例 - 行高统一设为
line-height: 1.3，别用 1.2——宽屏下字符密度高，太紧易糊 - 如果用了 Flex 布局，给
nav ul加flex-wrap: wrap，窄屏下自动折行，而不是强制压缩
横向导航在 iPad 横竖屏切换时布局抖动
仅靠 @media (orientation: landscape) 切换 90% 会失效。iOS Safari 动画帧中 matchMedia 可能连续触发 false/true/false；某些 WebView 根本不支持该查询。
- 真正稳定的方式是结合
visualViewport.width（实时可视宽度）和screen.orientation.type（系统传感器返回的 "landscape-primary" 等）交叉验证 - 桌面或旧引擎中，回退到
window.matchMedia监听 + 宽高差值判断（例如Math.abs(window.innerWidth - window.innerHeight) > 200） - 对折叠屏设备，Chromium 119+ 支持
@media (screen-spanning: single-fold-horizontal)，这是唯一可信的铰链状态信号
平板适配最常被忽略的是：断点不是设备尺寸，而是内容临界点；viewport 标签的位置错误会导致整个响应式逻辑静默失效；而 orientation 媒体查询在真实设备上远不如 JS 传感器数据可靠。
