移动端不是桌面版的压缩副本，而是独立交互场景，需以移动优先重构：先重置基础样式为小屏可用（rem单位、100%宽度、图片自适应），再用min-width断点逐步增强布局，而非max-width降级修复。
直接改：删掉所有 max-width 媒体查询，换成 min-width，再把基础样式重写成小屏可用——这不是“优化”，是重构起点。
为什么桌面优先布局在手机上会崩
典型症状包括横向滚动条、文字小到看不清、按钮点不中、图片溢出容器。根本原因不是“没加 media query”，而是整个 CSS 逻辑反了：你先用 100vw、px 固定宽高、float 或绝对定位撑开桌面布局，再靠 @media (max-width: 767px) 强行“缩小”或“隐藏”，结果是小屏要扛大屏的冗余规则，还经常覆盖不全。
移动端不是桌面版的“压缩副本”，它是独立交互场景：触控面积、视口物理尺寸、网络带宽都不同。强行缩放只会让体验变差。
- 固定
width: 1200px在 375px 宽的 iPhone 上必然溢出 -
font-size: 16px在小屏上等效显示面积不足，实际可读性差 - 用
display: inline-block+vertical-align排列的导航，在窄屏下极易换行错位
第一步：重置基础样式为移动可用
删掉所有已有媒体查询，从零写一套无查询的基础 CSS。目标只有一条：在 320px–414px 屏宽下，内容能完整阅读、可点击、不横向滚动。
- 把所有
px字体/间距/边框，换成rem或em（1rem = 16px是安全起点） -
.container改为width: 100%+padding: 1rem，别设max-width - 禁用
white-space: nowrap、overflow: hidden这类掩盖问题的写法 - 图片统一加
img { max-width: 100%; height: auto; }
此时页面可能看起来“太松散”或“太小”，这正常——移动优先不追求视觉还原，而追求功能可用。
第二步：用 min-width 逐步增强，不是“降级”
从 @media (min-width: 768px) 开始加断点，只做“增强”，不做“修复”。每加一层，只回答一个问题：“这个尺寸下，用户需要什么新能力？”
-
768px（平板竖屏）：可加max-width: 720px居中，启用两栏卡片布局 -
1024px（平板横屏/小桌面）：启用display: grid，列数从 1 → 2 → 3 -
1280px（常规桌面）：恢复侧边栏、增加内边距、放宽行高
关键区别：min-width 断点是“向上叠加”，不会影响小屏；而旧式 max-width 是“向下覆盖”，容易漏掉选择器或权重冲突。
Tailwind 用户注意断点前缀的实际生效逻辑
Tailwind 的 md: 不是“在 md 屏上才生效”，而是“在 ≥768px 的屏幕上，覆盖默认样式”。这意味着：
-
class="w-full md:w-1/2"中w-full是小屏基础，md:w-1/2是增强，不是条件开关 - 如果忘了写基础类（比如只写
md:w-1/2），那小屏会回退到浏览器默认宽度（通常是auto），很可能失控 -
sm:起点是 640px，但很多安卓小屏手机横屏刚好卡在这个边界，建议用真机测试，别只信模拟器
真正难的不是写断点，而是判断哪些样式该保留在基础层——比如 padding、line-height、touch-action，这些必须从最小屏就存在，否则触控和可读性直接报废。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
