亿格云前端开发工程师面试准备

亿格云前端开发工程师面试准备入口，整理岗位画像、项目深挖模板、高频问答和 ToB 安全场景表达策略。

#tech / dev / frontend #type / howto #status / growing #resource / interview

[!info] related notes

亿格云前端开发工程师面试准备

亿格云是企业安全平台，面试风格大概率偏“项目深挖 + 工程边界 + 安全意识 + ToB 中后台表达”。不要只背八股，要把项目讲成能落地、能迁移、能收敛到安全场景的工程实践。

这篇怎么用

  1. 先练熟 14 节的”1 分钟速背版”，确保能流畅输出项目主线。
  2. 按 4.x 节的深挖问答逐题自测，答不顺的回到相关 MOC 补知识。
  3. 面到 React 或安全问题时，主动把话题引到”可迁移能力”和”企业安全场景收敛”。
  4. 面前 30 分钟只看 14 节速背版和 13 节速背问答。

岗位画像

亿格云做的是企业安全控制台类产品，前端岗位大概率考察：

  • 中后台系统开发能力，不是活动页或展示型页面
  • 工程化、模块化、跨端协作和长期维护意识
  • 安全边界理解，比如鉴权链路、权限控制、数据隔离
  • 复杂状态管理和实时通信能力
  • 能否把项目经验迁移到 ToB 安全产品语境

换句话说，面试官更看重的是”能不能把复杂前端做得稳、清晰、易协作”，而不是”会不会写某个页面”。

推荐主讲项目

一句话版本

我最想讲的是 Memoflow 多端效率平台。它不是单一前端页面，而是基于 Nx Monorepo 的多应用项目，包含 Web、Desktop、API 和共享业务包。前端这边我重点负责的是 Web 端应用壳、模块化分层、鉴权链路、共享服务注入、工程化和跨端复用设计。

30 秒版本

这个项目的特点不是页面多，而是工程边界清楚。仓库里有 apps/web、apps/desktop、apps/api，还有 packages/task、packages/goal、packages/repository、packages/contracts 这些共享包。我的做法是把前端拆成 视图层、composable 层、store 状态层、client service 层、adapter 层，让 Web 通过 HTTP 适配器访问后端，桌面端通过 IPC 适配器访问本地能力，但上层业务用法尽量保持一致。这样既方便扩展，也方便测试和跨端复用。

90 秒版本

这个项目本质上是一个多端的中后台应用。技术上我用了 Nx + pnpm 做 monorepo，前端 Web 是 Vue 3 + TypeScript + Vite + Pinia，桌面端是 Electron + preload + IPC 白名单，后端是 Express + Prisma + PostgreSQL。

我比较看重的地方有三个。

第一是 模块边界。我把业务拆成 task、goal、repository、notification、governance 这些模块，每个模块都有相对稳定的 contracts、application-client 和 infrastructure-client 分层，避免页面直接耦合接口细节。

第二是 跨端一致性。Web 用 HTTP 适配器，桌面端走 IPC，但上层 composable 和业务接口尽量一致，这样后续扩展桌面端或者移动端时，改动集中在 transport 和 adapter 层。

第三是 工程可维护性。仓库里 CI 会基于 Nx affected 跑 lint、typecheck、test、build；鉴权链路有统一的 ResultHttpClient、401 自动刷新和失败兜底；桌面端通过 preload 暴露白名单 IPC，尽量把安全边界前置。

如果把它映射到亿格云那种 ToB 安全平台，我觉得它最匹配的点就是：不是只会写页面，而是能做中后台系统、能讲工程边界、能考虑安全和跨端。

项目核心亮点

  • 它是中后台而不是活动页项目。有 dashboard、任务、目标、提醒、通知、知识仓库、设置、治理规则等多个业务域。
  • 它是多端项目。Web、Desktop、API 在一个 monorepo 中协同，天然适合回答工程化、协作、复用问题。
  • 它不是”页面直连接口”。有 contracts、client service、adapter、DI、store/composable 分工。
  • 它考虑了安全边界。Web 有统一鉴权刷新链路，Desktop 有 preload + IPC 白名单。
  • 它考虑了真实复杂度。有鉴权、路由守卫、SSE、代理、错误边界、国际化、主题、CI/CD、构建与发布。
  • 它能对应亿格云的 ToB 场景。统一控制台、复杂状态、策略配置、权限和实时通知，这些表达方式都可以往企业安全产品语境里靠。

项目深挖问答

为什么做成 monorepo，而不是前后端拆多个仓库？

我做成 monorepo 主要是因为这个项目天然有多端和共享域模型。Web、Desktop、API 都在消费同一批业务模块，如果拆多个仓库，contracts、DTO、领域类型、构建规则和版本同步成本会明显上升。

用 Nx monorepo 以后，我能把共享内容下沉到 packages，比如 contracts 负责统一协议类型，task、goal、repository 这些包承载具体业务模块，app-vue 提供前端应用层复用。这样做最大的收益有三个：

第一，跨端共享是自然的，而不是靠复制代码。 第二，影响范围更清楚，CI 可以用 nx affected 做增量检查。 第三，架构更容易被约束，不同项目和包之间的边界是看得见的。

我不是为了”技术炫技”才用 monorepo，而是因为这个项目确实有多应用和共享模块的现实需求。

前端分层是怎么做的？

我在这个项目里比较强调前端分层，而不是把接口调用、状态和 UI 全写在一个组件里。

我的做法是：

  • View / Page：负责展示和交互。
  • Composable：负责异步流程、错误处理、提示反馈、状态编排。
  • Store：只负责存数据和派生状态，不直接承担复杂 I/O。
  • Client Service：提供业务能力抽象，比如 task、goal、auth 等。
  • Adapter / Transport：对接 HTTP 或 IPC 等具体传输层。

比如任务模块里，store 只保存模板、实例、依赖图和分页信息；真正去拉取数据、处理失败重试、toast 提示，是在 useTask 里做的。这样做的好处是职责更清晰，也更容易测。

我比较反对把 store 写成”什么都做”的大容器，因为那样状态、网络、提示、副作用会全耦在一起，后期很难维护。

为什么选 Vite？

我选 Vite 主要是因为这个项目有明显的工程效率诉求。它在开发期基于原生 ES Module，冷启动和热更新体验会比传统 bundler 更轻；对 Vue 3 支持也很成熟，和 Nx 集成后整体开发体验比较顺。

但我不是只会说”Vite 快”。我更关注的是它在这个项目里怎么落地。比如：

  • Web 项目通过 Vite 配置了 workspace alias，开发期直接指向源码包，便于共享包联调。
  • 本地开发时我给 /api/v1 配了代理，减少跨域问题。
  • 因为项目里有 SSE，我还显式关闭了压缩，并对 /sse/ 路径做了额外处理，避免流式响应被中间件破坏。

所以对我来说，选型不是背概念，而是看它能不能支撑当前项目的开发效率和实际场景。

状态管理是怎么考虑的？

这个项目里我用了 Pinia，但我对状态管理的理解不是”把所有东西都扔进 store”。我更倾向于把 store 当成 纯状态容器。

像任务模块的 store，主要存模板列表、实例列表、当前详情、分页、加载态这些；真正的接口调用、错误翻译、桌面端鉴权恢复、toast 提示，都在 composable 里处理。

这样做的好处是：

  • store 更稳定，职责清晰；
  • composable 更容易复用和组合；
  • 状态和副作用拆开之后，后期排查问题更容易；
  • 迁移到 React 也比较自然，本质上可以映射成 hook + state manager + service。

所以我觉得核心不在 Pinia 还是 Redux，而在于你是否把”状态”和”异步副作用”区分清楚。

鉴权链路是怎么做的？

展开阅读: 登录前后端链路设计, Cookie/Session/Token/JWT

Web 端我做了一套统一鉴权链路，而不是每个页面各管各的。整体流程是：

  1. 登录成功后，把 access token、refresh token、identity 和 session 信息交给认证 store 统一维护。
  2. 请求发起时，通过统一的 token provider 从 store 里拿 access token 注入请求。
  3. 如果后端返回 401，会触发统一的 refresh 逻辑，用 refresh token 请求刷新接口。
  4. 刷新成功后更新 store，再自动重试原请求。
  5. 如果刷新失败，就清空状态并跳转登录页。

这样做的价值在于：鉴权逻辑收敛到了 HTTP client 层，业务模块不需要重复处理 token 细节。

但如果在面亿格云这种安全导向更强的公司，我会主动补一句：

当前项目因为是个人多端项目，Web 端为了开发效率用了持久化 store 保存 token；如果是企业安全场景，我会优先考虑把 refresh token 放到 HttpOnly Cookie，前端只保留短期 access token 或干脆走 BFF/同站点策略，减少 XSS 暴露面。

如果让你设计登录功能，怎么讲前后端链路？

我一般会从四层来讲：输入校验、凭证校验、会话签发、前端状态收敛。

前端提交登录表单后，先做基础校验，然后调用登录接口。后端收到请求后校验账号密码，校验通过就签发 access token 和 refresh token，同时返回当前身份和会话信息。前端收到响应后，不是把 token 散落到各个组件，而是统一交给认证模块管理。后续普通接口带 access token，请求失效时再走 refresh。

如果是 Web 场景，我会重点讨论 token 存储方案的取舍；如果是 Electron 场景，我会补充本地安全存储、preload 隔离和 IPC 边界；如果是 ToB 产品，我还会补充会话管理、设备管理、强制下线、审计日志和权限模型。

我的习惯不是把”token 放 localStorage”说成标准答案，而是会结合系统安全等级和部署方式谈 trade-off。

为什么要做统一的 HTTP client？

因为中后台项目一旦模块多了，如果每个模块自己处理 baseURL、鉴权头、超时、错误映射和 401 刷新，代码会非常散，而且行为不一致。

我这里抽了统一的 ResultHttpClient，主要收益有三点：

  • 统一鉴权：token 注入、401 刷新、失败回退只维护一处。
  • 统一错误语义：对业务层返回 Result<T>，减少到处 try-catch。
  • 统一可观测性：超时、日志、错误行为更容易集中治理。

这类封装在 ToB 项目里很有价值，因为模块数量会上来，稳定性比单次开发速度更重要。

有什么能体现对”安全边界”的理解？

我觉得最能体现安全边界意识的是桌面端的 preload 设计。Renderer 不能直接无限制访问 Node 能力，我通过 preload 用 contextBridge 暴露有限 API，再配合 IPC channel 白名单，只允许明确登记过的通道通信。

这个设计的核心不是 Electron API 用法本身，而是两个思路：

  • 默认不信任渲染进程；
  • 能收口的能力尽量收口，不把系统权限直接暴露给页面。

如果映射到亿格云这类企业安全产品，我觉得这个思路是相通的，本质上都是减少攻击面、把边界显式化。

实时通信怎么讲？

我这个项目里实际有 SSE 相关处理。我在 Web 的 Vite 代理层专门处理了 SSE，关闭压缩并对流式响应路径做兼容，避免被中间件缓冲或压坏。

如果面试官问为什么选 SSE、WebSocket、长轮询，我会这样答：

  • SSE 适合服务端单向推送到前端，比如通知、提醒、状态流。
  • WebSocket 适合双向高频实时交互，比如协同编辑、聊天室、强实时面板。
  • 长轮询/短轮询 实现简单，但实时性和资源利用率一般，更适合作为兜底方案。

如果是我这个项目，像通知、提醒、状态更新这类服务端推送，其实 SSE 就够用，前端接入成本也更低；但如果是需要双向通信、频繁交互或者更复杂的连接状态管理，我才会考虑 WebSocket。

CI/CD 怎么讲？

这个项目里 CI 不是简单跑一遍全量脚本，而是结合 Nx 的 affected 机制做增量校验。当前流水线至少会对受影响项目执行 lint、typecheck、test 和 build，避免每次改一个模块就把全仓都跑一遍。

另外发布链路也做了分层处理。比如桌面端 release 会校验 tag 和版本一致性，然后按平台构建并产出安装包。

我觉得 CI/CD 的重点不是”会不会写 yml”，而是：

  • 能不能让反馈更快；
  • 能不能减少无意义构建；
  • 能不能让构建、测试和发布规则稳定下来；
  • 能不能针对多端项目设计不同的流水线路径。

怎么做错误处理和兜底？

我不太喜欢”接口一失败页面就白屏”的做法，所以我在这个项目里会把错误处理分层。

  • 网络层：统一 HTTP client 处理超时、401、刷新、错误结果归一化。
  • 业务层：composable 里把错误翻译成用户可理解的信息，并做 toast 反馈。
  • 视图层：页面自己展示局部 error state。
  • 应用层：再加全局 Error Boundary，兜住致命渲染错误，避免直接白屏。

这样做的好处是不同级别的问题在不同层处理，用户体验和可维护性都会更好。

这个项目和 ToB 中后台有什么关系？

虽然这个项目是效率平台，但它的前端问题其实很典型地偏 ToB。因为它不是内容展示型页面，而是统一控制台式应用，有模块化导航、复杂状态、仪表盘、任务流转、提醒与通知、设置中心、治理规则、错误兜底、鉴权和跨端协作。

所以我会强调，这个项目训练我的不是活动页开发能力，而是：

  • 面向复杂业务域做模块拆分；
  • 面向多角色和多状态做页面组织；
  • 面向长期维护做工程收敛；
  • 面向真实交付去考虑安全、部署、测试和发布。

这和亿格云这种企业安全控制台其实是同一类能力模型。

Vue / React 相关问题

Vue 和 React 优劣怎么答？

如果从我自己的项目经验看，Vue 3 的优势是上手和组织速度比较快，模板、响应式和组合式 API 在中后台项目里很高效，尤其是多人协作时，很多常见写法比较统一。

React 的优势是生态更广、抽象自由度更高，尤其在组件模型、跨端能力和一些工程体系上更成熟。代价是自由度高也意味着约束更弱，如果团队没有统一规范，很容易出现风格漂移。

我自己的理解是，不要把 Vue 和 React 简单理解成”谁更强”，而要看团队背景、现有资产和项目类型。

在我现在这个项目里，我用 Vue 做 Web 和桌面端应用层，原因是开发效率和组织成本更合适；但我做的分层方式，比如 store 只管状态、service 和 adapter 解耦、transport 抽象统一，这些迁移到 React 也是成立的。对我来说框架是 UI 表达层，工程设计能力才是更底层的东西。

React Hook 是什么？

展开阅读: React Hooks 原理深挖

Hook 本质上是 React 在函数组件里复用状态和副作用逻辑的一套机制。它解决的核心问题不是”语法更短”，而是让函数组件也能拥有状态、生命周期式副作用和逻辑复用能力。

从工程角度看，Hook 的价值主要有三个：

  • 让状态逻辑从 UI 结构里拆出来；
  • 让多个组件之间复用一套有状态逻辑；
  • 让组件更容易按职责拆分，而不是堆在 class 生命周期里。

如果结合我自己的项目经验来讲，Vue 里的 composable 和 React 的自定义 Hook 在思想上是接近的，本质都是把”状态 + 副作用 + 业务流程”抽成可复用单元。

如果面试官抓着 React 问，但项目主栈是 Vue，怎么回答最稳？

展开阅读: class vs function component, React Hooks 原理

我会很坦诚地说，我这个最成熟、投入最多的项目主 Web 确实是 Vue。但我不回避这一点，因为我想证明的是更底层的前端工程能力。

我在项目里做的很多事情其实和框架无关，比如模块边界、状态和副作用分层、DI、client service、adapter、统一鉴权、CI/CD、跨端 transport 抽象，这些能力迁移到 React 是完全成立的。

如果换成 React，我会用 Hook 去承接现在很多 composable 的职责，用 context 或状态库承接 store，用 service 和 adapter 保持业务层稳定。

所以我不是只会某个框架语法，而是有一套能迁移的工程设计方法。

JS / TS 高频题

什么是闭包？

展开阅读: 闭包是什么，有什么应用和问题, 柯里化手写

闭包就是函数在定义时，能够记住并访问其词法作用域中的变量，即使这个函数在外层作用域执行结束后仍然被调用。

它不是一个”技巧题”，而是 JavaScript 很基础的能力。常见用途包括：

  • 封装私有状态；
  • 实现函数工厂；
  • 回调中保留上下文；
  • Hook / composable 内部保留状态和依赖。

我平时更关心的是闭包带来的两个副作用：

  • 可能产生意外引用，增加内存占用；
  • 在 React 场景里容易产生 stale closure 问题。

所以我会把闭包答成”能力 + 代价”。

TS 常用工具类型怎么答？

我在项目里最常用的是这几类：

  • Partial<T>：做局部更新参数时很常见；
  • Pick<T, K> / Omit<T, K>：裁剪 DTO 或组件 props；
  • Record<K, V>：做枚举到配置映射；
  • ReturnType<T> / Parameters<T>：从函数签名推导类型；
  • Awaited<T>：处理异步结果；
  • Readonly<T>：限制对象被意外修改。

但我不会只背定义。我更看重工具类型的使用场景。比如做前端模块分层时，接口层和页面层需要的字段往往不一样，Pick 和 Omit 很适合做边界收敛；做通用配置映射时，Record 会比对象字面量随便写更稳。

type 和 interface 的区别怎么答？

我通常不会把它答成”谁更高级”，而是分场景。

  • interface 更适合描述对象结构，尤其适合可扩展、可合并的公共契约。
  • type 更适合联合类型、交叉类型、别名和更灵活的类型表达。

在工程里我的习惯是：

  • 对外暴露、稳定的对象协议更偏向 interface；
  • 组合、映射、联合这种类型表达更偏向 type。

关键不是选哪个，而是团队风格是否一致、边界是否清楚。

工程化题

为什么依赖这样选？

我选依赖时一般看四点：

  • 是否解决明确问题，而不是”流行就上”；
  • 是否和现有技术栈兼容；
  • 是否能减少长期维护成本；
  • 团队能不能真正消化。

比如这个项目里：

  • Nx 是因为多应用多包协作明显，能解决影响分析和任务编排问题；
  • Vite 是为了提升开发体验，并且和 Vue 3 集成成熟；
  • Pinia 是因为我需要一个轻量、类型友好的状态层；
  • ResultHttpClient 是为了统一错误处理和鉴权逻辑；
  • Electron preload + IPC 白名单 是为了收紧桌面端权限边界。

所以依赖选择的核心不是”技术新”，而是”对当前复杂度是否刚好”。

怎么理解”工程能力”？

我理解的工程能力不是会不会配脚手架，而是当项目复杂度上来以后，代码还能不能继续改、继续测、继续协作。

所以我会从几个角度看工程能力：

  • 边界是否清楚；
  • 依赖是否显式；
  • 问题是否收敛在该收敛的层；
  • 测试和 CI 是否跟得上；
  • 需求变动时是不是改一处就够，而不是连锁反应。

我现在这个项目里最能体现工程能力的地方，不是某个页面，而是 模块化、跨端抽象、鉴权链路统一、增量 CI 和安全边界控制。

网络与实时通信

WebSocket、SSE、长轮询、短轮询区别

展开阅读: 实时通信选型对比, AI 场景 SSE vs WebSocket

  • 短轮询：客户端定时请求，简单但浪费资源，实时性也一般。
  • 长轮询：服务端先挂起请求，有数据再返回，减少无效请求，但连接管理成本高。
  • SSE：服务端到客户端的单向流式推送，浏览器原生支持，适合通知、日志流、状态流。
  • WebSocket：全双工通信，适合双向高频实时场景。

我的选择原则是：

  • 单向推送优先考虑 SSE；
  • 需要双向、频繁、低延迟交互再上 WebSocket；
  • 轮询通常作为兼容或低复杂度方案。

不要为了”技术更高级”就无脑上 WebSocket。

WebSocket 心跳机制怎么答？

展开阅读: WebSocket 心跳机制

心跳的核心作用是检测连接是否假活着。因为网络断开、代理中断、服务端异常时，前端不一定马上能感知连接失效。

通常做法是客户端或服务端定时发送 ping/pong 或轻量消息，如果连续多个周期没有收到响应，就判定连接异常并触发重连。

我会补一句：心跳不是越频繁越好，要结合业务实时性、连接规模和服务端压力平衡。

UX / CSS / 中后台意识

可访问性和用户体验怎么看？

展开阅读: Fitts 定律与尼尔森十大交互原则

我理解的可访问性不是锦上添花，而是中后台系统稳定体验的一部分。像键盘操作、焦点管理、错误提示清晰、颜色对比度、语义结构，这些都会影响真实使用效率。

这个项目里我会关注全局错误边界、命令面板、主题切换、加载和错误状态、路由切换进度反馈，这些都属于体验设计的一部分。

如果在亿格云那种安全控制台场景里，我会更重视：

  • 重要操作的确认反馈；
  • 表单错误的可理解性；
  • 列表、筛选、状态标签的一致性；
  • 实时状态变化时的可见性和可追溯性。

CSS 里的高斯模糊怎么答？

展开阅读: CSS 高斯模糊怎么用

最常见就是两个属性：

  • filter: blur(...)：作用在元素本身内容上；
  • backdrop-filter: blur(...)：作用在元素背后的背景上，常用于毛玻璃。

如果继续追问，我会补两个点：

  • backdrop-filter 要考虑兼容性和性能；
  • 大面积模糊会有性能成本，尤其在低端设备上要控制使用范围。

AI 相关问题

怎么用 AI 提效？

我会把 AI 当成加速器，而不是替代判断。

我平时更常用的方式有：

  • 让 AI 帮我快速生成方案对比或初稿；
  • 用它补测试样例、边界条件和类型体操思路；
  • 做代码阅读、重构建议和文档整理；
  • 在不熟悉的模块里先建立全局上下文，再自己收敛到最终实现。

但我会特别注意三件事：

  • 生成内容必须回到项目上下文里验证；
  • 涉及安全、鉴权、数据一致性的代码不能直接照搬；
  • AI 适合加速信息处理，不适合替代架构判断。

如果面亿格云，我会顺手补一句：

企业产品里使用 AI，更重要的是可验证、可审计和边界清晰，而不是”能生成就行”。

AI 会不会让前端门槛变低？

我觉得会降低入门门槛，但不会降低高质量交付门槛。

因为页面代码本身更容易被生成，但真正拉开差距的部分是：

  • 需求抽象能力；
  • 架构与边界设计；
  • 性能与稳定性；
  • 安全与协作；
  • 对业务问题的理解。

所以 AI 会替代一部分机械劳动，但不会替代工程判断。

底层原理怎么学

展开阅读: 底层原理学习方法

我不太会把”学底层”理解成只刷源码。我更倾向于从实际问题出发反推原理。

比如做鉴权时，我会去看 HTTP 请求链路、token 刷新和浏览器存储的安全差异；做实时通信时，我会去看 SSE、WebSocket 和代理层的行为；做框架时，我会去理解响应式、调度和组件更新模型。

我的方法通常是：

  1. 先在项目里遇到真实问题；
  2. 再定位到对应抽象层；
  3. 最后回到源码、文档或实验验证。

这样学出来的原理更容易沉淀成工程判断，而不是只背概念。

速背问答

为什么 store 不直接调接口？

因为我希望 store 保持稳定，只承担状态容器职责。接口调用、错误翻译、toast、副作用如果都塞进 store，状态层会越来越重，后期会很难测试和维护。所以我把异步编排放在 composable，把 store 收敛成状态容器。

为什么要做显式依赖注入？

因为显式依赖比隐式单例更容易读、测和替换。像不同 transport 下切 HTTP 适配器还是 IPC 适配器，只应该发生在组合根或最外层，不应该渗透到业务组件里。

为什么要有 contracts 层？

因为多端协作时，协议和 DTO 不能散落在各处。contracts 层可以把接口类型、协议映射和 DTO 统一下来，减少前后端和多端之间的对不齐问题。

怎么理解”薄 controller / 薄 transport”？

我理解 transport 层只做协议映射，不做业务编排。这样真正的业务复杂度就收敛在 use case 或 service 层，后续换 HTTP、IPC 或别的接入方式时，上层逻辑更稳定。

怎么理解”跨端复用”？

跨端复用不应该是复制页面，而应该是复用业务语义和模块边界。我的做法是让上层业务尽量面向统一的 service / use case，底层再切 HTTP 或 IPC 适配器。

1 分钟速背版

我最想讲的项目是一个基于 Nx monorepo 的多端效率平台，包含 Web、Desktop、API 和一组共享业务包。它不是简单写页面，而是把任务、目标、通知、仓库、治理这些模块做成可复用的业务包。前端层面我比较强调分层，页面负责展示，composable 负责异步编排，store 只管状态，下面再接 client service 和 adapter。这样 Web 可以走 HTTP，桌面端可以走 IPC，但上层业务调用方式尽量一致。

工程上我做了统一鉴权链路、401 刷新、全局错误兜底、SSE 代理兼容、Electron preload + IPC 白名单，以及基于 Nx affected 的 CI。这个项目让我积累的不是某个页面实现，而是中后台、多端、工程化和安全边界方面的经验。我觉得这和亿格云这种企业安全控制台的能力要求是比较匹配的。

项目代码证据位置

  • Web 启动与应用壳：apps/web/src/main.ts
  • Web 依赖注入：apps/web/src/platform/di.ts
  • Web 统一鉴权链路：apps/web/src/platform/http.ts
  • Web 构建和 SSE 代理处理：apps/web/vite.config.ts
  • 路由与鉴权守卫：packages/app-vue/src/router/index.ts
  • 任务模块 composable：packages/app-vue/src/modules/task/composables/useTask.ts
  • 任务模块 store：packages/app-vue/src/modules/task/stores/taskStore.ts
  • Dashboard 聚合视图：packages/app-vue/src/views/DashboardView.vue
  • 全局错误兜底：packages/app-vue/src/shared/components/GlobalErrorBoundary.vue
  • 全局命令面板：packages/app-vue/src/shared/components/GlobalCommandPalette.vue
  • contracts 设计：packages/contracts/README.md
  • 组合根模式：packages/task/COMPOSITION_ROOT.md
  • 高复杂模块重构案例：packages/repository/COMPOSITION_ROOT.md
  • 治理模块分层架构：packages/governance/ARCHITECTURE.md
  • Electron preload 安全边界：apps/desktop/src/preload/preload.ts
  • IPC 白名单：apps/desktop/src/preload/allowed-channels.ts
  • CI：.github/workflows/ci.yml
  • 测试流水线：.github/workflows/test.yml
  • 发布流水线：.github/workflows/release.yml

实战提醒

  • 不要把这个项目讲成”我做了很多页面”，要讲成”我做了一个有明确边界的多端中后台系统”。
  • 不要死背概念，要反复把答案落回”为什么这么做、解决了什么问题、如果放到亿格云会怎么进一步收敛”。
  • 面到安全相关问题时，承认当前项目为了开发效率做过取舍，然后主动补充企业场景下你会怎么收紧，这是加分项。
  • 面到 React 相关问题时，不要慌着解释”我主项目不是 React”，而要把话题引到”我做的是可迁移的前端工程设计”。
  • 关键词要主动带出：Nx Monorepo、多端复用、显式依赖注入、contracts / adapter / service 分层、store 只存状态 composable 负责异步编排、统一鉴权链路、SSE 与代理兼容、Electron preload 安全边界、CI 基于 affected 增量执行、更偏 ToB 中后台不是纯展示型项目。

我先帮你校正一下名字：公开招聘里，和“前端开发工程师校招/应届”对应的主体基本是 亿格云，不是“忆格云”。“忆格科技”检索到的是另一家做人像/3D 打印相关业务的公司；而你要找的这家前端岗位，对应的是 杭州亿格云科技有限公司。(阿里云开发者社区)

我能直接搜到的“亿格云前端校招/实习面经”公开样本不算多，下面这份我按“公司与岗位画像 → 直接面经题目 → 高概率考点 → 备战建议”给你整理，尽量做到能直接拿去复习。(牛客网)

1）公司和岗位画像

亿格云官网把自己定位为 SASE / 办公安全厂商，主打零信任访问、数据防泄漏、终端安全、AI 治理等，并强调“一个控制台，一套规则，全球部署”；BOSS 公司页写到公司成立于 2021 年，总部杭州，在杭州和深圳有研发中心，服务 400+ 头部客户、覆盖超 300 万终端。也就是说，这家公司的前端很大概率不是纯 C 端活动页，更像 企业安全平台 / 管理控制台 / 中后台。(亿格云)

最近能查到的前端应届/校招 JD 至少有两版：一版强调 React、HTML/CSS/JavaScript、ES6+、响应式布局、浏览器兼容、React Hooks/Router/状态管理、Git、Vite/Webpack，还提到 可访问性、用户体验原则、Fitts 定律、尼尔森十大交互原则；加分项包含 Electron、HarmonyOS、Tauri/Flutter Web/React Native、GitHub/博客。另一版“校招前端开发工程师”则强调参与核心产品前端开发、跨团队协作，并要求 数据结构、网络协议、操作系统 这些计算机基础。(zhipin.com)

再往前一点的实习/牛客岗位，写法也很一致：强调 PC/移动端开发、ToB/中后台相关平台经验优先、熟悉 React 和 webpack/rollup；另一则实习岗位还直接提到 React / Node.js / AI 辅助开发，并点名 Cursor、Claude、ChatGPT、Copilot。这说明这家公司前端岗不只是看页面实现，还挺看重 工程化、产品理解和 AI 工具使用习惯。(牛客网)

2）我搜到的直接面经 / 题目

一条 2025 年 6 月的前端一面记录比较有价值：面试大约 30 分钟，题目包括：

  • Vue、React 优劣及学习心得
  • 项目开发环境为什么这么选、第三方依赖为什么这么选
  • WebSocket 心跳机制；SSE、长/短轮询
  • CI/CD 用什么、怎么规划部署
  • AI 相关
  • 怎么学习底层原理
  • TS 常用工具类型

发帖人的反馈是：面试官觉得“基本都能做出来，但不够精，答得不够深”，然后 很快约了二面。这个信号很重要：它家前端面不是只看“会不会”，而是很看 理解深度。(牛客网)

另一条“亿格云 前端实习”帖子列出的题目有：

  • 自我介绍
  • 项目经历深挖
  • React Hook 是什么
  • class component 和 function component 的区别
  • React VDOM 实现原理
  • 什么是闭包
  • 手写一个闭包例子（柯里化）(牛客网)

这条实习帖的检索摘要里，还能看到一道偏业务实现的题：如果设计一个登录功能，说说前后端的逻辑。这意味着它家前端题不会只停在八股，也会落到真实业务链路。(牛客网)

另外还有一篇题为“前端面筋---杭州亿格云（热泪回忆青春版）”的检索摘要里出现了 “CSS 里的高斯模糊怎么用” 和 “当场 offer” 这样的线索。因为页面正文解析不完整，这条我建议你当作弱证据看，但至少说明它家面试里也可能掺一些 CSS 细节 / 视觉实现题。(牛客网)

3）按命中率排序，你最该准备的方向

第一优先：React 主栈。
React Hooks、函数组件 vs 类组件、VDOM/渲染流程、路由、状态管理、组件化抽象，这些在 JD 和面题里都反复出现。还有一点要注意：虽然 JD 偏 React，但公开面经里还是直接问了 Vue 和 React 对比，所以不要只会背 React。(zhipin.com)

第二优先：工程化与选型能力。
为什么选 Vite / Webpack、依赖怎么选、CI/CD 怎么做、Git 工作流怎么协作，这类题在它家是显性考点。你最好准备 1～2 个自己项目里的真实取舍案例，而不是只背概念。(zhipin.com)

第三优先：Web 基础 + 计算机基础。
HTML/CSS/JavaScript、ES6+、响应式、兼容性，以及数据结构、网络协议、操作系统，这些都在校招 JD 里。说明它家对应届生不是“只要会 React 就行”，而是默认要有比较完整的基础盘。(zhipin.com)

第四优先：实时通信与前后端链路。
WebSocket 心跳、SSE、长短轮询、登录态设计、跨域代理、前后端交互流程，都是已经在公开题目里出现过的。因为公司产品是企业安全平台，涉及告警、日志、策略同步这类场景，我觉得这块命中率会挺高。后半句是基于产品形态的推断。(牛客网)

第五优先：TypeScript。
至少把常用工具类型、泛型、type/interface、组件 props 类型设计准备好。TS 工具类型已经被直接问到，说明这不是“会一点就行”的加分项。(牛客网)

第六优先：ToB / 中后台表达能力。
公司官网明确是统一控制台、安全治理平台；旧岗位也写了 ToB 或中后台相关平台经验优先。所以你讲项目时，最好往 表单、表格、权限、日志、策略配置、可视化面板、复杂交互 这些词上靠。这个是我结合官网产品形态和岗位文案做的高概率判断。(亿格云)

第七优先：UX / 可用性 / 交互意识。
最新一版 JD 明确点了 可访问性、用户体验原则、Fitts 定律、尼尔森十大交互原则。这说明它家不是纯“切图型前端”思路，面试官可能会看你有没有产品感。(zhipin.com)

第八优先：AI 相关。
公司官网主打 AI 治理 / AI 助手，岗位又点名 AI 辅助开发工具，公开面经里也有“AI 相关”问题，所以建议你提前准备“你怎么用 AI 提效、怎么做校验、怎么避免过度依赖”的回答。(亿格云)

4）你回答时要刻意强调什么

不要只说“我会 React”，要能说清楚你在项目里 怎么做组件拆分、状态边界、性能优化、异常处理、可维护性设计，以及为什么这么做。因为从已知一面反馈看，面试官明显在看“深度”而不是“会不会”。(牛客网)

项目介绍最好尽量包装成 企业场景问题解决。例如权限控制、策略配置、实时告警、日志检索、复杂表单、跨端适配、多人协作流程，这会更贴亿格云的产品语境。这个判断来自它官网强调的安全治理控制台、终端/网络/数据/AI 治理平台，以及旧岗位的 ToB/中后台偏好。(亿格云)

如果面到登录态，不要把“token 就放 localStorage”说成唯一标准答案。OWASP 明确提醒 不要把会话标识符存到 localStorage，因为它始终可被 JavaScript 访问；Cookie 可借助 HttpOnly 降低这类风险。你在面试里更稳妥的说法是：结合 XSS / CSRF 风险、业务形态和部署方式谈取舍。(OWASP Cheat Sheet Series)

5）你现在可以直接突击的题单

React：Hook 原理与使用限制、函数组件 vs 类组件、VDOM、状态管理、组件封装。(牛客网)

工程化：Vite vs Webpack、依赖选择依据、CI/CD 流程、Git 分支策略、构建优化、代码规范。(牛客网)

JS / TS：闭包、柯里化、事件循环、原型链、常用 TS 工具类型、泛型、type/interface。(牛客网)

网络与业务：WebSocket 心跳、SSE/轮询区别、登录流程、鉴权、跨域、浏览器缓存、HTTP 基础。(牛客网)

CSS / 体验：响应式布局、兼容性处理、可访问性、交互原则、filter / backdrop-filter 这类基础视觉实现。(zhipin.com)

6）一句话总结

这家前端岗不是只考“会不会写页面”，更像是在看 React 基础 + 工程化深度 + ToB/中后台思维 + 一点 UX/AI 意识。公开面经虽然不多，但题型已经很集中，按上面这条线准备，命中率会比较高。(牛客网)

接下来我可以直接继续给你整理一版 “亿格云前端校招模拟面试题 + 参考回答要点”。

创建于 2026/4/3 更新于 2026/5/27