星源智1面

3 小时前更新

核心问题与回答

Q1：请简单介绍一下你的工作经历和项目经验？

原始回答：

• 面试官你好，我是唯一，有三年前端开发经验，目前在中山文安特科技公司负责智慧停车业务线的前端开发
• 参与搭建了覆盖车主端H5小程序和运营管理后台的管理平台
• 负责停车缴费、欠费追缴、停车订单和设备运维等核心模块，推动欠费查询、在线缴费和运营跟进的业务闭环
• 是 uni APP 移动端 Wot UI 组件库的成员，主导开发过高拓展性的瀑布流组件，参与过 Wot Star 脚手架的建设

回答质量： ⭐⭐⭐

复盘后的标准回答：

• 面试官你好，我有3年前端开发经验，目前就职于中山稳安特科技公司，负责智慧停车业务线的前端开发
• 技术栈以 Vue3 和 UniApp 为主，参与搭建了覆盖车主端 H5 小程序和运营管理后台的完整管理平台
• 核心负责停车缴费、欠费追缴、停车订单和设备运维等模块，推动了欠费查询、在线缴费到运营跟进的业务闭环
• 同时是 Wot UI 组件库的核心成员，主导开发了高拓展性的瀑布流组件，并参与了脚手架工具的建设
• 在 AI 方向也有实践，负责过公司 RAG 知识库问答系统的前端开发

---

Q2：对于网页响应式开发，你一般会采用哪些方案？

原始回答：

• 响应式方案的话，一般有使用 iem 方案，或者使用 CSS 的响应式属性如 rem、vw/vh，还有媒体查询
• 还有一个纯 JS 的方案，像阿里淘宝已经有开源库专门解决响应式问题
• 如果想统一项目的响应式尺寸，也可以使用现成的库
• 现在一般都有响应式单位 vw 这种，或者使用百分比布局也可以做到响应式布局

回答质量： ⭐⭐⭐

复盘后的标准回答：

• REM 方案： 设置根字体大小，所有尺寸使用 rem 单位，配合 postcss-pxtorem 自动转换，适合整体等比缩放
• 视口单位方案： 使用 vw/vh 做布局尺寸，适合全屏自适应场景
• 媒体查询： 针对不同屏幕宽度设置断点，调整布局结构，适合复杂布局变化
• Flex/Grid 布局： 利用弹性布局和网格布局天然的自适应能力
• 百分比布局： 结合 max-width/min-width 控制范围
• 移动端适配推荐： 使用 vw + rem 组合方案，vw 做布局单位，rem 做字体单位
• 工具推荐： 阿里开源库 lib-flexible + postcss-pxtorem，或直接使用 postcss-mobile-forever

---

Q3：在使用 REM 方案时，如何处理大屏和小屏文字显示不一致的问题？

原始回答：

• 一个方案是分开针对 1K 屏、2K 屏这种单独做适配
• 进行统一的比例转换，先算好一个基准值，然后识别 1K 屏、2K 屏的物理设备密度、像素密度，有一个叫 dpr 的值
• 封装好转换函数，传入设计稿的值，乘以设备实际像素密度的比例值，动态转换
• 也可以使用 Sass 等 CSS 预处理器封装函数，在写 CSS 时直接调用转换函数

回答质量： ⭐⭐

复盘后的标准回答：

• 问题原因： REM 方案基于屏幕宽度等比缩放，大屏下所有元素（包括文字）等比放大，可能导致文字过大
• 解决方案一： 设置最大基准值，当屏幕超过某个宽度时，根字体大小不再增加

  html { font-size: calc(100vw / 375 * 16); }
  @media (min-width: 540px) { html { font-size: 24px; } }

• 解决方案二： 文字使用 px 或 em，布局使用 rem，文字不参与缩放
• 解决方案三： 使用 clamp() 函数限制字体大小范围，如 font-size: clamp(14px, 3vw, 20px)
• 推荐方案： 布局用 vw，字体用 px + 媒体查询微调，兼顾适配和可读性

---

Q4：在移动端渲染时，如何处理 iOS 和安卓端样式不一致的问题？

原始回答：

• 目前公司项目中没有遇到过 0.5 像素渲染问题
• 理论上可以使用 CSS 的 scale 进行缩放
• 通过设置底层分辨率实现自适应
• 使用 viewport meta 标签进行配置
• 太久没做了，有点忘了怎么处理

回答质量： ⭐

复盘后的标准回答：

• 1px 边框问题： 使用 transform: scale(0.5) + ::after 伪元素实现 0.5px 边框
• 滚动条差异： iOS 上滚动更顺滑，使用 -webkit-overflow-scrolling: touch（已废弃，现代浏览器默认支持）
• 输入框样式： iOS 上使用 -webkit-appearance: none 重置默认样式
• 安全区域适配： 使用 env(safe-area-inset-top/bottom) 适配刘海屏
• 字体渲染： iOS 字体更细，可设置 -webkit-font-smoothing: antialiased
• 通用方案： 使用 CSS Reset/Normalize.css 统一各端默认样式，再针对差异做兼容处理
• 推荐工具： PostCSS 插件 postcss-mobile-forever 或 autoprefixer 自动处理兼容性

---

Q5：在渲染可视化大屏时，如何优化 2800 台设备的渲染性能？

原始回答：

• 首先做可视区域裁剪，监听地图的平移和缩放事件，只渲染当前视口内的设备，视口外的 DOM 和 mark 隐藏掉
• 做聚合和降级策略，地图缩放到较小比例时使用高德地图的 mark club cluster 做点聚合，放大后再逐个展开
• 简化 DOM 结构，把地图上的 mark 标记转为 icon 组件，减少 DOM 节点数量
• 做数据分页和筛选前置，用户筛选设备类型后后端只返回对应数据
• 对更新不频繁的数据做缓存，后端用 Redis 缓存，前端用 localStorage，HTTP 层面开启 cache-control

回答质量： ⭐⭐⭐

复盘后的标准回答：

• 可视区域渲染（虚拟列表）： 只渲染当前视口内的设备，不可见区域不创建 DOM 节点
• 聚合策略（Cluster）： 地图场景下，将密集设备聚合成一个标记点，缩放时自动拆分/合并
• DOM 简化： 将复杂 DOM 结构转为轻量级元素（如 Canvas 或 SVG），减少 DOM 节点数
• 数据分页 + 筛选前置： 先筛选再渲染，减少单次渲染数据量
• 缓存策略： 后端 Redis 缓存 + 前端 localStorage 缓存，减少重复请求
• HTTP 缓存： 静态资源开启强缓存，数据接口使用协商缓存
• requestAnimationFrame： 批量更新 DOM，避免频繁重排重绘

---

Q6：可视化大屏的数据获取方式是怎样的？数据量大了怎么处理？

原始回答：

• 前端轮询方式，每 30 秒请求一次后端
• 第一次初始化时获取所有数据，存入 localStorage
• 后续根据视口范围只获取可见区域的数据
• 数据大小约 900kb，主要是设备在线情况、经纬度、是否报错等信息
• 面试官追问 28 万条设备存不下 localStorage 怎么办：暂时想不到

回答质量： ⭐⭐

复盘后的标准回答：

• 初始化： 首次加载时获取全量数据，存入 localStorage 作为本地缓存
• 轮询策略： 每 30 秒轮询一次，获取增量更新数据
• 按需加载： 后续请求只获取当前视口范围内的数据，减少传输量
• 缓存更新： 轮询到新数据后，对比差异并局部更新，避免全量替换
• 优化建议： 如果实时性要求不高，可拉长轮询间隔（如 60 秒）；如果实时性要求高，可切换为 SSE 或 WebSocket
• 大数据量方案： localStorage 只有 5-10MB 上限，28 万条数据建议使用 IndexedDB 存储，配合 Web Worker 分片处理，或采用服务端分页 + 按需加载的策略

---

Q7：你开发的瀑布流组件是如何实现的？

原始回答：

• 基于队列驱动的增量排版机制，加载一个排版一个，不等全部加载完再统一排版
• 使用最短优先算法，每次找到当前高度最短的那一列追加
• 父子组件结构，父组件负责排版布局，子组件负责卡片内容展示
• 异步加载编排，使用 Vue Watch + Promise 等待内容加载完成，拿到精确高度后再算位置
• 超时时有最大等待时间兜底，使用默认高度继续排，不阻塞整个排版队列
• 四级错误处理策略：失败就结束、使用默认高度兜底、显示占位图、自动重试指定次数
• 支持完整的布局生命周期 API：reflow（重新排版）、reset（重置）、任意位置插入
• 处理了页面切换打断布局的问题，切后台时中断排版并清理资源，切回时恢复

回答质量： ⭐⭐⭐

复盘后的标准回答：

• 架构设计： 父子解耦架构，父组件 Waterfall 维护列高和坐标计算，子组件 WaterfallItem 通过作用域插槽支持任意内容
• 排版算法： 基于最短优先算法，每次将新项插入当前高度最小的列
• 增量排版： 基于队列驱动，新增数据时只对新项排版，不触发全部重排
• 异步加载： 使用 Vue Watch + Promise 等待图片等资源加载完成后再排版，保证布局准确
• 错误处理（四级策略）：
  1. 失败结束：加载失败时终止该次排版
  2. 默认高度兜底：使用预设高度占位
  3. 显示占位图：加载失败显示占位图片
  4. 自动重试：加载失败后自动重试
• 生命周期 API： 提供 reflow（重新排版）、reset（重置布局）、insertAt（任意位置插入）等完整 API

---

Q8：运营端如何实现按需配置的首页布局？

原始回答：

• 使用 JSON schema 描述布局，每种布局写成一个 JSON schema
• 提供布局选择开关，用户选择想要的布局
• 结合 RBAC 模型进行权限过滤，不同岗位能看到的内容不同
• 根据权限决定显示哪些内容卡片，用 v-if 做判断不渲染无权限的卡片

回答质量： ⭐⭐⭐

复盘后的标准回答：

• JSON Schema 驱动： 首页布局由后端返回的 JSON Schema 描述，前端动态渲染
• 布局配置： 运营人员可通过配置开关选择显示哪些内容卡片
• 权限过滤： 结合 RBAC 模型，根据用户角色权限过滤可显示的卡片
• 动态渲染： 前端根据 Schema 和权限列表，动态渲染对应的组件
• 优势： 无需发版即可调整首页布局，运营配置灵活

---

Q9：有没有做过 3D 渲染相关的项目？

原始回答：

• 这个倒是没有做过
• 我知道 3D 渲染有 WebGL 或者 Three.js 这些框架
• 但是公司目前没有这方面的需求，所以没有接触过这些方案
• 不过我相信现在有 AI 辅助的话，学这种方案应该也会比较快，上手也是比较快的

回答质量： ⭐⭐

复盘后的标准回答：

• 目前没有实际做过 3D 渲染相关的项目，公司业务暂时没有这方面的需求
• 但对 WebGL 和 Three.js 有一定的了解，知道它们的基本渲染流程和适用场景
• 如果有需要，可以快速学习上手，特别是现在有 AI 辅助的情况下，学习曲线会大大降低
• 建议表达：虽然没有实际经验，但对技术原理有基本了解，且有信心快速掌握

---

Q10：在使用 AI 辅助设计稿还原时，如何约束 AI 的产出？

原始回答：

• 首先把设计规范写成一个 design.md 文档放到项目根目录
• 如果使用 Figma，配合 Figma 的 MCP 插件和 skill 连接
• 让 AI 参照设计文档实现页面，调用 Figma 的 MCP 和 skill 读取设计规范
• 如果还有问题，只能跟 AI 细说哪部分需要调整

回答质量： ⭐⭐⭐

复盘后的标准回答：

• 设计规范文档： 在项目根目录编写详细的设计规范文档，包含颜色、字体、间距、组件样式等
• Figma MCP 集成： 通过 Figma 的 MCP 插件和 Skill，让 AI 直接读取设计稿中的设计规范
• 上下文约束： 在 Prompt 中明确指定设计规范文件路径，要求 AI 严格参照
• 分步还原： 先还原整体布局，再逐步细化组件样式，避免一次性输出偏差过大
• 人工校验： AI 产出后人工 Review，对不满意部分手动调整或重新生成
• 经验总结： 设计规范越详细，AI 还原准确度越高；复杂页面建议拆分为多个小组件分别还原

---

反问环节

原始提问：

• 贵公司的主要业务方向是什么？开发岗具体做哪些方面？
• 开发团队的规模大概是多少？
• 岗位偏大屏可视化方向，是这样吗？

复盘后的提问思路：

反问环节的核心目标是展示对业务和团队的真实兴趣，同时获取信息判断岗位匹配度。提问应覆盖以下维度：

• 关于业务： 请问这个岗位主要负责哪些业务线？目前比较紧急的任务是什么？短期和长期的目标是什么？
• 关于团队： 团队目前的规模和分工是怎样的？前端团队有多少人？前后端协作模式是怎样的？
• 关于技术栈： 团队目前使用的技术栈是什么？对新技术（如 AI 辅助编程）的态度是怎样的？
• 关于成长： 公司对新人的培养机制是怎样的？比较看重应聘者的哪些能力？
• 提问技巧： 先了解业务再问待遇，展现职业态度；避免问面试官已透露的信息；表现出对公司和岗位的深度思考

薄弱环节与改进方向

薄弱点	改进建议	关联知识点
iOS/安卓端样式差异处理（Q4）回答不清，承认"忘了"	系统学习移动端样式兼容方案：1px 边框、安全区域、滚动差异、字体渲染，至少能说出 3-4 个具体方案	待补充：移动端样式兼容方案
REM 方案文字适配（Q3）回答绕，缺少结构化方案	学习 clamp() 函数、max-width 限制、文字与布局分离等方案，面试时直接给出 2-3 种具体方案	待补充：REM 方案文字适配优化
大数据量存储方案（Q6 追问）没有思路	学习 IndexedDB、Web Worker 分片加载、虚拟滚动等方案，应对数据量级扩展的问题	待补充：前端大数据量存储方案
3D 渲染（Q9）没做过，回答较简短	了解 Three.js/WebGL 基本概念，至少能说出渲染流程、场景、相机、几何体等核心概念	待补充：WebGL / Three.js 基础

访谈总结

本次面试详细了解了面试者在前端开发方面的技术能力和项目经验，特别是在响应式开发、可视化大屏优化和组件开发方面的实践经验。面试者展示了扎实的技术基础和解决问题的能力，对前端性能优化有深入理解。同时，也了解了其所在公司的业务方向和团队规模情况。

整体表现： 面试者在自我介绍、响应式方案、大屏性能优化、瀑布流组件实现和开源贡献方面表现较好，展示了扎实的技术功底和项目经验。但在 iOS/安卓样式兼容处理和 REM 方案文字适配方面回答不够清晰，大数据量存储方案被追问时没有思路，3D 渲染方面没有实际经验，需要在后续面试中加强准备。反问环节提问得体，展现了对公司和岗位的兴趣。