百度前端面试题目整理
移动端适配及 rpx 与 px 换算
根据提供的文章内容,以下是移动端适配方案的逻辑整理,按文章结构分层呈现核心要点:
一、移动端适配的背景
-
问题根源
- 移动端设备屏幕尺寸碎片化(不同分辨率、视口比例)。
- 固定尺寸元素在不同设备上显示比例失衡(大屏显小,小屏显大)。
-
核心目标
- 等比缩放:确保元素在不同设备占据的视口比例一致。
二、自适应 vs 响应式
概念 | 特点 | 实现方式 |
---|---|---|
自适应布局 | 为不同屏幕预设多套静态布局(尺寸不变,位置变化) | 媒体查询(@media ) |
响应式布局 | 元素布局随屏幕实时动态调整(更强的自适应,解决小屏布局拥挤问题) | 媒体查询 + 流式布局(如 Flex、Grid) |
注:
响应式布局包含自适应,但更强调布局的动态调整能力
。
三、主流适配方案对比
方案一:百分比布局(不推荐)
- 原理:使用百分比(
%
)定义元素宽高/边距(参照父元素尺寸)。 - 缺点:
- 不同属性(宽、高、边距等)的百分比
参照物不同,难以统一
。 - 需配合
box-sizing: border-box
避免尺寸溢出。
- 不同属性(宽、高、边距等)的百分比
- 示例:
.box {width: 100%; /* 参照父容器宽度 */padding: 5% 10%; /* 参照自身宽度 */margin: 0 auto; }
方案二:rem + 动态 font-size
(企业常用)
- 原理:
rem
单位基于html
根元素的font-size
计算。- 动态设置
html
的font-size
为屏幕宽度的1/10
(如 375px 屏幕 →font-size: 37.5px
)。
- 单位换算:
- 手动:
rem = 设计稿元素px值 / 基准font-size
(如 100px →100/37.5 ≈ 2.6667rem
)。 - 自动化工具:
- 预处理器:Less/Sass 函数自动换算。
- 工程化:Webpack +
postcss-pxtorem
插件。 - 开发辅助:VSCode 插件
px to rem
。
- 手动:
- 动态设置
font-size
方法:- 媒体查询(硬编码,不灵活):
@media (min-width: 375px) { html { font-size: 37.5px; } }
- JS 动态计算(推荐):
function setRem() {const htmlWidth = document.documentElement.clientWidth;htmlEl.style.fontSize = htmlWidth / 10 + 'px'; } window.addEventListener('resize', setRem);
- 现成库:
lib-flexible
(淘宝方案,自动处理 1px 问题)。
- 媒体查询(硬编码,不灵活):
方案三:vw / vh(推荐趋势
)
- 原理:
vw
= 视口宽度的1%
,vh
= 视口高度的1%
。- 直接基于视口尺寸,无需动态设置根字体。
- 单位换算:
- 公式:
vw = (设计稿元素px值 / 设计稿宽度) * 100vw
(如 100px 在 375px 稿 →100 / 3.75 = 26.6667vw
)。 - 自动化工具:
- 预处理器函数、Webpack +
postcss-px-to-viewport-8-plugin
。 - VSCode 插件
px to vw
。
- 预处理器函数、Webpack +
- 公式:
- 重要规则:
- 禁止混用
vw
和vh
:导致元素宽高比例失真(横竖屏变化时变形)。 - 统一使用
vw
:高度用vw
保持比例稳定(因高度通常大于宽度)。
- 禁止混用
方案四:Flex 弹性布局(辅助方案)
- 角色:处理内部元素排列(不解决整体缩放问题)。
- 核心能力:
- 主轴对齐:
justify-content
(水平方向)。 - 侧轴对齐:
align-items
(单行)、align-content
(多行)。 - 换行控制:
flex-wrap: wrap
+align-content
调整换行后对齐。
- 主轴对齐:
- 适用场景:结合 rem/vw 方案,实现细节自适应排列。
四、方案选择建议
方案 | 适用场景 | 优势 | 局限性 |
---|---|---|---|
百分比 | 简单宽度自适应 | 无依赖 | 复杂布局易失控 |
rem | 企业级项目(兼容性要求高) | 成熟工具链,可控性强 | 需动态计算 font-size |
vw / vh | 现代项目(未来趋势) | 无需 JS,语义明确,简化开发 | 低版本兼容性(需 Polyfill) |
Flex | 内部元素排列 | 灵活对齐,避免浮动问题 | 不解决整体缩放 |
最佳实践:
- 整体缩放:vw 方案(优先)或 rem 方案。
- 内部布局:Flex / Grid 辅助排列。
- 淘汰方案:百分比布局(仅作辅助)。
五、关键结论
- 响应式 > 自适应:响应式通过动态布局解决小屏拥挤问题。
- 核心缩放方案:
- rem:需动态设置根
font-size
,依赖 JS 或媒体查询。 - vw/vh:视口原生单位,更简洁(未来主导趋势)。
- rem:需动态设置根
- 排列方案:Flex 布局处理细节对齐,与缩放方案互补。
- 工程化:通过 PostCSS 插件、预处理器函数、编辑器工具自动化单位换算。
附:完整实现代码参考原文示例(媒体查询、JS 动态 rem、Flex 布局等)。
布局类型
- 静态布局 px
- 流式布局:%/em、vh/vw、rem(默认16px)
- 自适应布局:Media Query
- 响应式布局:流式(Flex)+媒体查询
适配
基础配置:viewport meta标签
布局方案:rem + vw
(动态计算根字体)
辅助方案:Flex布局处理内部元素排列
精细调整:关键断点的媒体查询
图片处理:响应式图片 + WebP格式
“
viewport meta标签是移动端开发的关键配置
,通过<meta name="viewport" content="width=device-width, initial-scale=1.0">
可以确保页面按设备实际宽度渲染。其中width=device-width设置布局视口等于设备宽度,initial-scale=1.0设置初始不缩放。现代开发中我们还需要考虑全面屏适配和可访问性,所以会添加viewport-fit=cover
并保留适度的缩放能力。需要注意的是,不同浏览器对某些属性如user-scalable的实现可能有差异…”
图片响应式与加载优化策略
🧰 实现响应式图片的关键技术
- HTML 层面的图片资源适配:
srcset
与sizes
属性:允许浏览器根据设备的屏幕尺寸和分辨率自动选择最合适的图片资源,从而避免加载不必要的大图。
<picture>
标签:支持在不同的媒体条件下加载不同的图片资源,适用于需要在不同设备上展示不同图片内容的场景。
CSS 层面的图片尺寸控制:
- 流式布局:通过设置
max-width: 100%
和height: auto
,使图片在其容器内自适应缩放,避免超出容器范围。- 媒体查询(MediaQueries):根据不同的屏幕尺寸和分辨率,调整图片的显示样式和布局,以适应各种设备。
性能优化策略:
- 图片格式选择:根据图片内容选择合适的格式,如使用
WebP 格式
以获得更好的压缩率和加载性能。- 懒加载(Lazy Loading):仅在图片
进入视口时才加载(IntersectionObserver)
,减少初始加载时间和带宽消耗。- 图片压缩与优化:在不影响视觉质量的前提下,压缩图片以减小文件大小,提高加载速度。
“在响应式图片处理方面,我通常采用
srcset
和sizes
属性配合使用,确保在不同设备上加载最合适的图片资源。同时,通过 CSS 的流式布局和媒体查询,实现图片在各种屏幕尺寸下的自适应显示。此外,我也注重性能优化,例如选择合适的图片格式、实施懒加载策略,以及对图片进行压缩处理,以提升整体的加载效率和用户体验。”
在前端面试中,向面试官清晰地介绍 XSS(跨站脚本攻击)和 CSRF(跨站请求伪造)是展示你对 Web 安全理解的重要环节。以下是对这两种攻击方式的简明介绍及其防御措施:(vue3js.cn)
Flex布局面试常考的场景题目
Flex布局面试常考的场景题目
计网
XSS(Cross-Site Scripting,跨站脚本攻击)
原理
XSS 攻击是指攻击者在网页中注入恶意脚本代码,当其他用户浏览该网页时,恶意脚本会在用户的浏览器上执行,从而窃取用户信息、篡改页面内容或进行其他恶意操作。(牛客网)
类型
- 反射型 XSS:恶意脚本存在于 URL 中,服务器将其反射到页面中,用户点击链接后触发攻击。
- 存储型 XSS:恶意脚本被存储在服务器(如数据库)中,用户访问相关页面时自动执行。
- DOM 型 XSS:攻击者利用前端 JavaScript 的漏洞,在不经过服务器的情况下修改页面 DOM 结构,执行恶意脚本。(GitHub, CSDN)
危害
- 窃取用户的 Cookie、Session 等敏感信息。
- 劫持用户会话,冒充用户进行操作。
- 篡改网页内容,传播虚假信息或钓鱼链接。(百度智能云, 腾讯云, 牛客网)
防御措施
- 输入验证:对用户输入的数据进行严格的验证和过滤,防止恶意代码注入。
- 输出编码:对输出到页面的内容进行适当的编码,防止浏览器将其解析为可执行代码。
- 使用 HTTP-only Cookie:设置 Cookie 为 HTTP-only,防止 JavaScript 访问。
- 部署 Content Security Policy(CSP):限制浏览器加载的资源来源,防止执行未授权的脚本。(百度智能云, 牛客网)
CSRF(Cross-Site Request Forgery,跨站请求伪造)
原理
CSRF 攻击是指攻击者诱导已登录受信任网站的用户,在不知情的情况下发送请求到该网站,从而执行非本意的操作,如修改账户信息、进行转账等。
危害
- 在用户不知情的情况下更改账户设置。
- 进行未授权的资金转移或操作。
- 降低用户对网站的信任度,影响网站声誉。(百度智能云)
防御措施
- 使用 CSRF Token:在请求中加入随机生成的 Token,服务器验证 Token 的有效性。
- 验证 Referer 或 Origin 头:检查请求的来源,确保来自合法的页面。
- 设置 SameSite Cookie 属性:限制第三方网站发送的请求携带 Cookie。
- 要求用户进行二次验证:对于敏感操作,要求用户输入密码或进行其他验证。
XSS 与 CSRF 的对比
比较维度 | XSS | CSRF | |
---|---|---|---|
攻击目标 | 用户 | 服务器 | |
利用方式 | 注入并执行恶意脚本 | 利用用户的身份发送伪造请求 | |
用户参与 | 被动执行恶意脚本 | 被动发送请求 | |
防御重点 | 输入验证、输出编码、CSP 等 | CSRF Token、验证请求来源、SameSite Cookie 等 | (牛客网, albert-w.github.io, 阿里云开发者社区) |
在面试中,除了理论知识,结合实际案例或项目经验,说明你如何在开发中防范这些攻击,将更能体现你的实战能力。
如需更深入的理解,推荐观看以下视频教程:
前端安全系列之XSS:4分钟彻底了解XSS攻击与防范
该视频简明扼要地介绍了 XSS 攻击的原理、类型及防范措施,有助于加深理解。(腾讯云)