东方红
核心问题与回答
Q1：请做自我介绍
原始回答：
- 我是伟业，有三年开发经验，目前在中山稳安特公司负责座位停车业务线
- 参与搭建了公司的覆盖车主端的H5小程序和运营管理后台
- 主要负责停车缴欠费、停车缴费、欠费追缴订单，还有设备运维等核心模块
- 推动停车欠费查询、在线缴费和运营跟进的业务闭环
- 是尤尼普移动端组件库沃特UI组件库的成员，主导开发过高拓展性的瀑布流组件
- 参与过组件库生态的沃特斯塔脚手架建设
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 面试官你好，我叫伟业，有3年前端开发经验，目前就职于中山稳安特公司，负责智慧停车业务线的前端开发
- 技术栈以 Vue3 和 UniApp 为主，参与搭建了覆盖车主端 H5 小程序和运营管理后台的完整停车管理平台
- 核心负责停车缴费、欠费追缴、设备运维等模块，推动了欠费查询、在线缴费到运营跟进的业务闭环
- 同时是 Wot UI 组件库的核心成员，主导开发了高拓展性的瀑布流组件，并参与了脚手架工具的建设
- 在 AI 方向也有实践，负责过公司 RAG 知识库问答系统的前端开发
Q2：工作经验三年对吧？
原始回答：
- 对
回答质量： ⭐⭐
复盘后的标准回答：
- 是的，从毕业到现在刚好3年，期间一直从事前端开发工作，积累了从 C 端 H5 到 B 端管理系统的全栈前端开发经验
Q3：你是2024年3月到现在一直是在广东稳安特科技有限公司，对吧？
原始回答：
- 没错
回答质量： ⭐⭐
复盘后的标准回答：
- 是的，从2024年3月至今一直在广东稳安特科技有限公司，负责停车业务线的前端开发，经历了从项目搭建到维护迭代的完整周期
Q4：你是什么样的原因加入开源社区？
原始回答：
- 当时公司开发使用的技术栈中，现有组件库API和组件数量方面使用体验不好
- 沃特UI是一个比较新的组件库，在DS view和AI生态方面做得比较完善
- 使用过程中发现bug，给作者提了一些bug和修复了一些issue
- 最主要的是瀑布流组件，与作者交流多了之后被拉入沃特团队
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 加入开源社区的契机源于工作中的实际需求：公司使用的组件库在 API 设计和组件丰富度上体验不佳
- 偶然发现了 Wot UI 这个新兴组件库，它在 Design System 和 AI 生态方面做得比较完善，于是开始使用
- 使用过程中发现了一些 bug，主动给作者提了 issue 并提交了修复 PR
- 特别是瀑布流组件方面，与作者深入交流后被邀请加入团队，成为核心贡献者
- 这段经历让我深刻体会到：参与开源最好的方式就是从解决实际问题开始，贡献代码比单纯提 issue 更能获得认可
Q5：开源项目中其他人提的问题，你什么时候处理？
原始回答：
- 一般是下班时间处理，5:30下班后时间比较多
- 不太会占用上班时间，除非上班真的很闲的时候才会处理
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 开源贡献主要利用业余时间处理，我一般是下班后（5:30之后）集中处理
- 工作日晚上和周末是主要贡献时间
- 除非当天工作任务不紧张，偶尔会在工作时间处理紧急 issue
- 建议回答时强调时间管理能力：开源和本职工作分得很清，不会影响工作产出
Q6：如果问题比较着急，怎么协调时间处理？
原始回答：
- 组件库团队成员有七八个
- 处理不了可以在群里面沟通，分配给谁就由谁处理
- 或者在群里面简单沟通交流思路，谁有空就处理
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 团队有完善的协作机制，核心成员约七八人
- 遇到紧急问题时，首先在团队群内同步，明确问题归属和优先级
- 如果自己处理不了或时间不允许，会在群里沟通思路，协调其他有空的成员接手
- 团队有异步协作文化，不要求即时响应，但会确保问题有人跟进
Q7：停车综合运营平台是从24年3月份到现在一直在开发？
原始回答：
- 对，平台有各种业务需求会频繁改动
- 现在主要是进入维护期，但需求一直在变动
- 核心功能基本上开发完了
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 是的，从2024年3月至今一直在持续迭代
- 目前平台已进入维护期，核心功能基本开发完成
- 但由于停车业务涉及多方对接（物业、支付、设备厂商等），需求仍在持续变动
- 这个过程中积累了丰富的业务系统开发和维护经验，特别是应对频繁需求变更的工程实践
Q8：2800多台设备的统一运营管理，怎么保证渲染？
原始回答：
- 可以做筛选控制，想要渲染什么就开放出来
- 有智能渲染容器，只渲染屏幕中能看到的部分
- 看不到的部分不会进行状态更新
回答质量： ⭐⭐
复盘后的标准回答：
- 采用可视区域渲染（虚拟列表）策略，只渲染当前视口内的设备
- 配合筛选控制，用户可以通过条件过滤只查看特定设备，减少渲染压力
- 不可见区域不进行状态更新，避免不必要的重渲染
- 数据层面做分页加载和筛选前置，减少单次渲染的数据量
- 对于地图场景，使用聚合（Cluster）策略，将密集设备聚合成一个标记点
Q9：轮询策略是什么？多久轮询一次？
原始回答：
- 调试设备时设置10秒轮询一次
- 前端也是10秒左右轮询一次
回答质量： ⭐⭐
复盘后的标准回答：
- 前端轮询间隔设置为10秒左右，用于获取设备最新状态
- 调试模式下同样采用10秒轮询，保证调试数据实时性
- 轮询策略的考量：10秒间隔在实时性和服务器压力之间取得了平衡
- 如果对实时性要求更高，可以考虑切换为 SSE（Server-Sent Events）或 WebSocket 方案
Q10：如果要监控电梯实时状态，怎么实现？
原始回答：
- 硬件更新到服务端，服务端收到信息后往前端推送
- 可以用SSE或前端进行轮询
- 约定好固定时间轮询电梯最新状态，拿到楼层数和开门状态
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 整体链路：硬件传感器采集数据 → 上报服务端 → 服务端推送/前端拉取 → 前端展示
- 方案一（推荐）：SSE（Server-Sent Events），服务端有更新时主动推送给前端，适合单向数据流场景
- 方案二：前端轮询，约定固定时间间隔查询电梯最新状态（楼层数、开门/关门状态）
- 方案三：WebSocket，适合需要双向通信的场景（如远程控制电梯）
- 选型建议：纯监控场景用 SSE 最合适，实现简单且浏览器原生支持
Q11：轮询压力怎么处理？
原始回答：
- 可以用服务器主动推送的SSE模式
- 有更新时后端推送到前端
- 当前系统没有使用SSE，主要采用轮询方式
回答质量： ⭐⭐
复盘后的标准回答：
- 轮询压力的核心问题是：大量无效请求占用服务器资源
- 解决方案一：切换为 SSE，服务端有更新时主动推送，前端无需频繁请求
- 解决方案二：优化轮询策略，如动态调整轮询间隔（空闲时拉长、有事件时缩短）
- 解决方案三：加入缓存机制，前端缓存上次结果，对比有变化才更新 UI
- 当前系统主要采用轮询，因为业务对实时性要求不是极高，且轮询实现更简单可靠
Q12：RBAC权限控制怎么做？
原始回答：
- 后端定义好权限表枚举所有系统能力，角色表配置角色拥有的权限，用户表绑定用户对应的角色
- 有新的权限组合的情况，可以新加角色，并分配相应的权限能力
- 前端登录时返回对应角色的权限列表
- 登录时调用接口返回权限列表到前端
- 前端进行持久化存储
- 如果当前角色没有权限，按钮上使用类似v-if控制渲染
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 后端设计： 三张核心表——权限表（枚举所有系统能力）、角色表（配置角色拥有的权限）、用户表（绑定用户对应的角色）
- 前端流程：
- 登录时调用接口获取当前角色的权限列表
- 将权限列表持久化存储（localStorage / Pinia）
- 使用自定义指令（如
v-permission）或v-if控制按钮/菜单的显隐
- 扩展性： 新的权限组合只需新增角色并分配对应权限，无需修改代码
- 安全注意： 前端权限控制只是用户体验层面的，后端必须做二次校验
Q13：多租户多账户怎么实现？
原始回答：
- 租户识别：H5场景下，租户ID通过URL参数或者二维码携带，App.vue启动时收参并判断
- 请求透传：所有接口都在请求头里带上tenant-id，保证后端能正确路由数据
- UI适配：登录后根据租户配置动态渲染品牌色、Logo、功能菜单和入口
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 租户识别： H5 场景下，租户 ID 通过 URL 参数或二维码携带，App.vue 启动时解析并存储
- 请求透传： 所有 API 请求在请求头中携带
tenant-id，后端根据租户 ID 路由到对应数据源 - UI 适配： 登录后根据租户配置动态渲染品牌色、Logo、功能菜单和入口，实现一套代码多租户使用
- 数据隔离： 前端只做展示层隔离，真正的数据隔离由后端通过 tenant-id 保证
- 缓存策略： 不同租户的配置和权限分开缓存，切换租户时清除旧缓存
Q14：怎么防止重复缴费？
原始回答：
- 没遇到过这个问题
- 如果遇到，后端会处理
回答质量： ⭐
复盘后的标准回答：
- 重复缴费的防止主要依赖后端，常见方案有：
- 幂等性设计： 每次缴费请求携带唯一订单号或幂等键，后端对相同幂等键只处理一次
- 状态机控制： 订单状态流转（待支付 → 支付中 → 已支付/支付失败），已支付状态拒绝再次扣款
- 分布式锁： 对同一订单加锁，防止并发请求同时处理
- 对账机制： 定期与支付渠道对账，发现重复扣款自动退款
- 前端可以做的是：支付按钮点击后立即置灰，防止用户重复点击；支付结果页轮询查询真实状态
Q15：首屏加载时间从3.9秒优化到1.5秒，做了哪些工作？
原始回答：
- 通过浏览器lighthouse和performance API分析
- 发现核心问题是静态资源未压缩和加载非首屏模块
- 开启Brotli压缩，降低资源体积
- 将能放到CDN的静态资源放到CDN
- 给不频繁变动的资源加缓存
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 诊断阶段： 使用 Lighthouse 和 Performance API 分析，发现两个核心问题——静态资源未压缩、加载了非首屏模块
- 优化措施：
- 开启 Brotli 压缩（比 Gzip 压缩率更高，体积减少约20-30%）
- 静态资源迁移到 CDN，利用 CDN 边缘节点加速
- 给不频繁变动的资源添加强缓存（Cache-Control: max-age=31536000）
- 代码分割：非首屏模块按需加载（路由懒加载 + 组件异步加载）
- 图片懒加载 + WebP 格式转换
- 效果： 首屏加载时间从 3.9s 优化到 1.5s，提升约 60%
Q16：RAG项目前端直接连接模型API吗？
原始回答：
- 模型调用阿里百链上的API
- 核心逻辑是前端自己做的
- 历史记录用Node.js连接Redis实现
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 模型 API 调用的是阿里百链上的接口，前端直接与模型 API 通信
- 核心的 RAG 逻辑（向量检索、重排序等）由前端实现
- 历史记录功能使用 Node.js 中间层连接 Redis 实现持久化
- 架构特点：前端承担了部分后端职责，适合探索性项目快速验证
- 生产环境建议：将 RAG 核心逻辑放到后端，前端只负责展示和交互
Q17：为什么没有后端参与RAG项目？
原始回答：
- 这是公司的探索性项目
- 后端在做其他事情，正好我有时间就自己做了
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 这是一个公司的探索性/创新项目，主要用于验证 RAG 技术在知识库问答场景的可行性
- 当时后端团队资源紧张，都在忙核心业务线
- 正好我对 AI 方向感兴趣，也有时间，就主动承担了前后端全栈开发
- 这种探索性项目由前端全栈开发的好处是：快速验证、灵活迭代
- 如果项目进入生产阶段，建议引入专业后端进行架构重构
Q18：RAG项目具体实现方案？
原始回答：
- 第一路是向量检索，文档切分后转成向量
- 第二路是BM25稀疏检索，保障精确命中
- 第三路是元数据过滤，根据设备类型等条件过滤
- 使用RRF方案做倒数排名融合
- 重排序模型做最后精排
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 采用经典的多路召回 + 重排序架构：
- 第一路（向量检索）： 文档切分后通过 Embedding 模型转为向量，使用向量数据库（如 Milvus/Pinecone）进行语义相似度检索
- 第二路（BM25 稀疏检索）： 传统关键词匹配，保障精确命中，弥补向量检索在精确匹配上的不足
- 第三路（元数据过滤）： 根据设备类型、时间范围等条件进行结构化过滤，缩小检索范围
- 融合策略： 使用 RRF（Reciprocal Rank Fusion）倒数排名融合算法，将多路召回结果按排名加权合并
- 精排： 使用 Cross-Encoder 重排序模型对融合结果做最后精排，提升 Top-K 结果的相关性
- 这种方案在召回率和精确率之间取得了良好平衡
Q19：有没有做过安卓、iOS和鸿蒙开发？
原始回答：
- 没有做过原生开发
- 打包过安卓应用
回答质量： ⭐⭐
复盘后的标准回答：
- 没有做过原生开发，但使用 UniApp 打包过安卓应用，对打包流程和原生配置有一定了解
- 熟悉 H5 与原生端的交互方式（JSBridge、URL Scheme 等）
- 如果有需要，相信借助 AI 辅助和已有的技术积累，可以快速上手原生开发
Q20：对客户端技术了解吗？
原始回答：
- 因为没开发过所以不太了解
- 但感觉有AI帮助加上技术沉淀，上手应该不是问题
回答质量： ⭐⭐
复盘后的标准回答：
- 目前对客户端技术了解有限，没有实际的原生开发经验
- 但作为前端开发者，对跨端技术（UniApp、Flutter）有一定了解
- 相信以现有的编程基础和对新技术的快速学习能力，加上 AI 辅助，上手客户端开发不会太困难
- 建议表达出学习意愿和信心，同时诚实说明当前的能力边界
反问环节
原始提问：
- 公司主要业务方向是什么？除了内部产品和新零售，还有哪些业务？
- 公司目前主要使用哪些技术栈？
- 开发团队大概有多少人？
- 如果有幸加入，希望新员工能快速具备哪些能力？
复盘后的提问思路：
反问环节的核心目标是展示对业务和团队的真实兴趣，同时获取信息判断岗位匹配度。提问应覆盖以下维度：
- 关于业务： 请问公司主要聚焦哪些业务方向？核心产品是什么？目标客户群体是怎样的？
- 关于团队： 团队目前的规模和分工是怎样的？前端团队有多少人？开发流程是怎样的？
- 关于技术栈： 团队目前使用的技术栈是什么？对新技术（如 AI 辅助编程）的态度是怎样的？是否有技术栈升级计划？
- 关于成长： 公司对新人的培养机制是怎样的？入职后 onboarding 流程是怎样的？比较看重应聘者的哪些能力？
- 提问技巧： 先了解业务再问待遇，展现职业态度；避免问面试官已透露的信息；表现出对公司和岗位的深度思考
薄弱环节与改进方向
| 薄弱点 | 改进建议 | 关联知识点 |
|---|---|---|
| 防止重复缴费（Q14）回答太简单，只说"后端会处理" | 学习支付系统的幂等性设计、状态机控制和分布式锁等方案，面试时能说出具体技术方案 | 待补充：支付系统幂等性设计 |
| 2800台设备渲染（Q8）回答不够深入，只说"智能渲染容器" | 补充虚拟列表、聚合策略、Canvas/SVG 渲染、数据分页等具体技术方案 | 待补充：大屏可视化性能优化 |
| 轮询策略（Q9）回答太简短，只说10秒 | 准备轮询间隔的选型考量，以及 SSE、WebSocket 等替代方案的对比 | 待补充：实时数据推送方案对比 |
| 客户端技术（Q19/Q20）了解有限 | 了解 UniApp 打包流程、JSBridge 交互、Flutter 基础概念，至少能说清前端与原生端的通信方式 | 待补充：跨端开发基础 |
| 简单确认性问题（Q2/Q3）回答被动 | 确认性问题后主动补充有用信息，如"对，3年经验，一直做前端" | 待补充：面试沟通技巧 |
访谈总结
本次面试详细了解了伟业的技术背景和项目经验，包括停车业务系统开发、开源组件贡献、性能优化实践等。面试者展示了扎实的前端开发能力和问题解决思路，特别是在 RAG 项目中的多路召回方案设计。双方就技术栈匹配度和岗位要求进行了充分沟通，后续将根据评估结果进一步联系。
整体表现： 面试者在开源贡献、RAG 项目实现、性能优化、RBAC 权限控制等方面表现较好，展示了扎实的技术功底和全栈开发能力。但在防止重复缴费等支付相关问题上回答过于简单，2800 台设备渲染和轮询策略的回答不够深入。客户端技术了解有限，简单确认性问题回答被动。反问环节表现得体，展现了对公司和岗位的兴趣。