PC与移动端共用HTML需依赖viewport标签、响应式媒体查询和弹性布局；viewport必须写全width=device-width且initial-scale=1；媒体查询应采用min-width自下而上增强；字体优先用rem或clamp，禁用混用vw/rem；图片须用srcset，杜绝固定宽度硬编码。
PC端和移动端用同一份HTML，不是靠“适配教程”解决的，而是靠三件确定性工具：viewport 元标签、响应式 CSS 媒体查询、弹性布局基础（flexbox 或 grid）。其他所谓“兼容方案”——比如 UA 判断跳转、双页面、JS 动态重写 DOM——在现代项目里基本是倒退。
为什么 <meta name="viewport"> 是前提，且不能只写一半
没这行，移动端浏览器会按桌面宽度（通常是 980px）渲染页面，文字小到看不清，用户得双指放大才能阅读。但只写 width=device-width 不够，还得加 initial-scale=1，否则 iOS Safari 在横屏切换后可能缩放错乱。
正确写法：
<meta name="viewport" content="width=device-width, initial-scale=1">
常见错误：
立即学习“前端免费学习笔记（深入）”；
-
user-scalable=no—— 屏蔽缩放，违反 WCAG 可访问性要求，部分国家法律风险 -
maximum-scale=1—— 和上面一样，实际中让视障用户无法调整字号 - 漏掉
initial-scale=1—— Android Chrome 某些版本下触发强制缩放，布局错位
媒体查询用 min-width 而不是 max-width 的真实原因
移动优先是默认策略，不是口号。先写移动端样式，再用 @media (min-width: 768px) 向上增强，这样：
- CSS 文件体积更小（多数设备只加载自己需要的部分）
- 避免
max-width堆叠导致的覆盖混乱（比如@media (max-width: 767px)和@media (max-width: 480px)容易互相干扰） - 服务端或构建工具做 CSS 分割时逻辑更清晰
典型断点参考（非固定，按设计稿容器宽度定）：
@media (min-width: 768px) { /* 平板竖屏及以上 */ }<br>@media (min-width: 1024px) { /* 平板横屏 / 小桌面 */ }<br>@media (min-width: 1280px) { /* 标准桌面 */ }
rem 和 vw 别混着用，选一个并坚持到底
rem 依赖根字体大小，适合需要精确控制字号层级的场景（比如标题体系）；vw 直接绑定视口宽度，适合全屏 banner、大标题等强响应需求。混用会导致计算不可控，尤其在 iOS Safari 中 vh/vw 在地址栏展开/收起时会抖动。
实操建议：
- 字体大小统一用
rem，配合 JS 动态设置document.documentElement.style.fontSize（仅限需兼容 iOS 9 以下的老项目） - 现代项目直接用
clamp(1rem, 4vw, 1.5rem)—— 它比媒体查询更轻量，且浏览器原生支持 - 绝对定位、padding/margin 等非文字尺寸，优先用
px或em，避免vw在小屏上把间距压成 0.3px 导致渲染异常
真正卡住项目的从来不是“怎么写响应式”，而是图片未做 srcset、第三方组件强行写死 width: 1024px、或者测试只跑 Chrome 桌面模式就上线。多设备兼容不是加一堆 hack，是约束源头：所有宽度相关声明，必须有明确的响应依据。
