html语义化标签不能直接提升移动端渲染速度，但能降低js框架和辅助技术适配成本；max-width与width:100%作用对象不同，混用易致图片压扁；viewport漏设user-scalable=no会导致双指缩放失控；@media宜用em单位以规避safari缓存bug。
HTML语义化标签在移动端真能提升渲染速度？
不能直接提速，但能显著降低 JS 框架或辅助技术的适配成本。比如 screen reader 读取 nav 时跳过一堆 div 嵌套，省掉手动加 aria-label；next/image 在 SSR 阶段识别 figure + figcaption 后，会自动注入 loading="lazy" 和宽高属性。
常见错误现象：div 套 div 写导航栏，结果 iOS VoiceOver 把整个区域读成“group”，用户得滑 8 下才到「登录」按钮。
- 移动端浏览器对
main、section、article的默认样式几乎为零，别指望靠它替代 CSS 重置 -
header不一定非得在页面顶部——它只表示“一个区块的页眉”，嵌套在article里也合法 - 用
time标记发布时间，iOS Safari 会识别并提供「添加到日历」快捷操作（需含datetime属性）
响应式布局中，max-width 和 width: 100% 混用为什么常出错？
因为它们作用对象不同：width: 100% 是让元素填满父容器，而 max-width 是限制这个“填满”行为的上限。移动端最典型的翻车场景是图片容器：父级设了 max-width: 100%，子图却写 width: 100% + height: auto，结果在小屏上被双重缩放压扁。
使用场景：卡片列表、图文混排、表单字段宽度控制。
立即学习“前端免费学习笔记（深入）”；
- 图片/视频优先用
max-width: 100%+height: auto，而不是width: 100% -
input元素默认有min-width（Chrome 是 130px），直接设width: 100%可能撑破父容器，加min-width: 0才可靠 - Flex 容器里的子项，
width: 100%会被 flex 主轴覆盖，此时max-width依然生效
viewport meta 标签漏写 user-scalable=no 会怎样？
不是安全问题，而是交互预期断裂。很多业务方要求「禁止双指缩放」，但只写了 width=device-width, initial-scale=1.0，用户仍可缩放——尤其在微信内置浏览器里，双指一捏，字体突变，表单控件错位，fixed 导航栏飘走。
注意：user-scalable=no 在 iOS 10+ 已被 Safari 视为非强制策略，系统级缩放设置（如「更大字体」）仍会生效，它只禁双指手势。
- 必须和
maximum-scale=1.0配合使用，单独写user-scalable=no在部分安卓 WebView 中无效 - 不要在登录页或表单页禁用，视障用户可能依赖缩放看清验证码或小字条款
- 若用
rem布局，禁用缩放后font-size计算更稳定，但需确保根字体大小不随系统设置变化（即不用vw或%动态算）
CSS @media 查询里用 em 还是 px？
用 em，但不是为了「可访问性」，而是为了规避 Safari 移动端的媒体查询缓存 bug：当用户在设置里调大系统字体，再切回网页，用 px 的 @media (max-width: 768px) 可能不重触发，而 em 基于当前根字号计算，响应更及时。
性能影响极小，兼容性上所有现代移动浏览器都支持 em 媒体查询，包括微信 X5 内核 6.8+。
-
1em对应的是html元素的font-size，不是浏览器默认 16px —— 如果你用html { font-size: 62.5%; }，那1em = 10px - 别混用单位：写
@media (max-width: 48em)就别在同个断点里又写480px，CSS 解析器不会报错，但维护时容易误判实际生效宽度 - Android Chrome 在横屏切换时，
em查询比px多一次重绘，但人眼不可察，不必为此降级
