移动优先的核心是基础CSS默认适配小屏、viewport标签必须正确且置顶、所有断点仅用min-width递进增强；禁用max-width混用、硬编码宽度及user-scalable=no，内容默认显示而非隐藏。
移动优先不是加个 @media 就算完事，核心是基础 CSS 默认只适配小屏、所有断点用 min-width 递进增强、 必须正确且置顶。
viewport meta 标签必须写对且放最前
这是整个移动优先链路的第一道闸门。浏览器没正确解析视口，后续所有布局都会错位或缩放异常。
-
是唯一可靠写法 - 禁用
width=320或user-scalable=no—— 前者硬编码会破坏 iOS Safari 双击缩放，后者让视障用户无法放大文字（普通网站不该加） - 该标签必须在
最顶部，不能靠 JS 动态插入；某些安卓 WebView 在 DOM ready 后才执行 script，此时页面已渲染完成，补插无效
基础 CSS 不写任何媒体查询，只面向手机最小视口
很多项目所谓“响应式”，其实是先写死桌面版（比如 .container { width: 1200px; }），再用 @media (max-width: 767px) 去覆盖——这本质是倒着来的修补，维护成本高、易遗漏关键交互点。
- 基础样式应默认单列、流式宽度（
width: 100%或max-width: 100%）、用rem或em控制字体和间距 - 禁用
px写按钮尺寸：44px 是触摸目标最小物理像素建议值，但不同 DPR 下实际渲染不同；改用min-width: 44px; min-height: 44px;+padding保证视觉可点性 - 圆角统一用
border-radius: 0.25rem;，而不是4px；rem会随根字体缩放，比px更适应高 DPR 屏
所有媒体查询只用 min-width，按升序排列
混用 max-width 和 min-width 容易在缩放、高 DPI 或折叠屏下漏掉边界值，比如 @media (max-width: 767px) 和 @media (min-width: 768px) 并列时，767.5px 视口两者都不命中。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 断点数值别抄 768px/1024px，要依内容崩坏点设定：拖动 DevTools 宽度滑块，观察卡片何时换行、文字何时挤成一团，记下临界值（如 892px → 取整为 900px）
- 每个
@media块里只写「需要变化的属性」，不要重复基础样式。例如默认font-size: 1rem;，那@media (min-width: 1024px)里只写font-size: 1.125rem; - 把小断点写在前面、大断点写在后面，CSS 层叠顺序决定覆盖逻辑；避免
min-width: 769px这类非整数边界，768px 设备会完全跳过该规则
别默认隐藏重要内容，而是默认显示、大屏再重组
常见错误是基础样式里写 .sidebar { display: none; }，再靠媒体查询把它 display: block; 出来——这等于默认屏蔽关键信息，违反移动优先“内容优先”原则。
- 正确做法是默认显示所有内容，小屏单列堆叠；大屏时用
flex或grid把侧边栏并排布局 - 表格类组件尤其要注意：小屏不强行横向滚动，改用
overflow-x: auto包裹，或用display: block+th[scope="row"]配合伪元素实现“行头转列头”的语义化重排 - 导航别一上来就塞汉堡菜单；先做底部固定导航或精简顶部 tab，平板以上再升格为横向 navbar + 下拉菜单
真正难的不是写多少 @media，而是判断哪些样式必须从基础层就支持触控、流式和缩放——比如 gap 替代 margin、min-block 替代 margin-top、所有交互区域都带 :focus-visible 适配键盘用户。这些细节不会报错，但一上线就被真实用户卡住。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
