刚面完飞书前端一面，趁热乎把题和思路都整理出来
坐标社招，前端方向，年后投了字节飞书的岗位。上周约的一面，刚面完不到两个小时，趁脑子里还热乎，赶紧把这45分钟里被问到的东西、我的答法、还有复盘时觉得答得不够好的地方全部写下来。飞书前端团队在字节内部一直以工程化和产品复杂度著称，一面主要筛的就是基础硬不硬、业务落地能力强不强，这套面经对准备字节系前端岗位的同学应该都有参考价值，尤其是工作两年以上、想冲大厂社招的人。
先说下面试的整体流程。约面之后收到的飞书会议链接，面试官准时进入，打开摄像头，自我介绍完就进入正题。整个一面时长大概45分钟，节奏分布大概是：项目深挖15分钟，基础题和手写题25分钟，反问环节5分钟。没有上来就甩题，是先聊项目再考基础，这基本是字节前端的固定打法，项目是用来开场的，也是用来摸底你真实工作深度的。
1. 面试前的准备与整体思路
1.1 社招前端投递飞书，前期怎么准备更高效
这次约面速度比我想象中快。周四在招聘平台更新简历并主动投递，周一就有HR联系，简单电话沟通了工作年限、技术栈、离职状态之后就约了当周的视频面。飞书这边用的就是自己的视频会议产品，这点挺有意思，面试工具本身就是他们的业务产品。
准备阶段我核心做了三件事。第一是重新梳理了简历上最重的那个项目，准备好"你在里面具体负责什么、遇到的最大难点是什么、最后怎么解决"这组问题的答案。第二是把前端基础八股文过了一遍，重点放在JavaScript运行机制、浏览器渲染原理、Vue响应式原理这几个方向。第三是手写题练了一轮，防抖节流、深拷贝、Promise相关、数组去重这些都是高频题，不练到闭着眼能写的程度不敢上考场。事实证明这些准备方向是对的，面试中大部分问题都在这个范围内。
还有一点想提醒大家，飞书团队对项目里体现出的复杂场景处理能力非常看重。他们做的产品本身就是重交互、重协同、重实时性的办公套件，所以如果你有做过类似复杂表单、协同编辑、或大规模列表渲染这类项目，一定要在简历里明确体现出来，面试官基本都会针对这些细节往下追问。
1.2 一面到底在筛什么，面试官想看到什么
字节一面的定位比较明确，就是在最短时间内判断你“基础扎不扎实、能不能干活、有没有潜力”。他们不指望你什么都会，但考察的所有内容都指向一个目标：你是不是一个靠谱的前端工程师。
从我这次被问到的内容来看，一面的考察维度大致可以分成四块。第一个是JavaScript语言本身的掌握程度，比如事件循环、this指向、闭包、原型链这些，这些是判断你语言功底最直接的方式。第二个是浏览器和网络相关的基础，缓存机制、从输入URL到页面展示的整个过程、HTTP相关知识点，这些能看出你对前端运行环境的理解深度。第三个是框架原理，Vue和React至少要精通一个，面试官会深挖响应式原理、diff算法这些核心机制的底层实现。第四个就是工程化能力和项目落地能力，通过深挖项目经历判断你解决真实问题的能力。
这里有个很重要的认知：面试官不是在考你背书功力。比如问到缓存，不是让你把强缓存和协商缓存的定义背一遍，而是会不断追问“为什么要有强缓存和协商缓存之分”“ETag和Last-Modified到底选哪个好”“如果前端改了文件但用户还是拿到旧文件，你会怎么定位”。这种追问方式本质是在模拟真实的排障过程，回答的时候尽量结合自己实际遇到过的场景，用具体的调试经历来支撑你的理解，会比重背知识点有说服力得多。
2. 打开视频后的前15分钟：项目深挖与实战验证
2.1 自我介绍怎么讲才算合格
面试官的第一个问题当然是“先做个自我介绍吧”。别小看这个环节，很多人在自我介绍阶段就已经开始丢分了。
我的做法是控制在三分钟左右，结构是“基础信息（姓名、年限、当前方向）→ 最近一份工作的核心职责 → 最有代表性的项目简述（背景、难点、成果）→ 为什么看机会”。重点放在前两项，最后一项一笔带过就行。这个结构的好处是既给面试官一个清晰的画像，又自然地把话题引导到你最擅长的项目上去，让接下来的深挖节奏掌握在你手里。
还有一个细节，自我介绍里提到的技术栈一定要精准。比如你说自己“精通Vue”，面试官后面很可能就默认往死里问Vue底层；你说“Vue和React都有实战经验”，那就要做好被对比着问的准备。不确定的内容不要说满，给自己留好余地，否则一旦问到你陌生的角落，反而会显得你名不副实。
2.2 项目深挖环节的致命追问链
自我介绍结束，面试官几乎是顺滑地接了一句：“我看你简历上写了XX项目，这个项目是你主要负责的吧？聊一下这个项目。”
注意，他说的是“聊一下”，而不是“介绍一下”。这就是字节典型的开放式提问，你的回答会决定他接下来追问的方向。我这次讲的是一个偏中后台的复杂业务系统，包含动态表单配置和复杂表格交互。在几分钟的讲述中，我刻意突出了三个点：业务背景的复杂度、我在技术方案上的取舍、最后拿到的量化结果。
讲完之后，面试官的追问果然来了。第一个问题就是“你提到的动态表单方案，当时为什么要自己造轮子而不是直接用现成的表单方案？”这个问题就是在考察你做技术选型时的决策依据和深度。第二个问题更细：“动态配置项的校验规则是怎么设计的？有没有考虑过表单项之间的联动校验？”这种问题直接决定你在面试官心里是“能落地的工程师”还是“纸上谈兵的简历选手”。
我结合之前做过的表单引擎设计，讲了校验规则如何从配置项中抽离、如何通过依赖收集来实现联动校验、以及如何规避循环依赖的问题。讲的过程中面试官插了一句“这里你考虑过性能问题吗”，于是我又补充了在配置项变化时如何做局部校验而非全量校验的优化逻辑。整体上这个环节的对话感是有的，面试官会根据你的描述调整追问方向，尽量每一个回答都做到“结论在前、过程在后、数据兜底”，别绕弯子。
2.3 面试官想从项目中验证的三个能力
面完之后我复盘，发现项目深挖环节本质上是在验证三件事：技术深度、系统思维和业务结果意识。
技术深度体现在你对自己项目里每个技术方案的原理是否清楚。比如动态表单这个方向，你需要说清楚用的什么渲染机制、如何管理表单状态、配置驱动的数据结构如何设计、如何做性能优化，这些都是一环扣一环的，任何一个环节含混不清都会被抓住追问。
系统思维体现在你有没有站在更高维度看项目。面试官问“这个方案如果让你重新设计一次，你会改哪些地方”，这个问题直接暴露你是只完成了需求，还是真的思考过整个系统的演进方向。
业务结果意识也很关键。你做完一个项目，它带来了什么收益？提效多少？节省了多少人力？减少了多少线上问题？我反馈到的是一个从“人工配置需要3小时”压缩到“操作5分钟内完成”的数据，面试官对这个结果明显是认可的。做技术的容易只盯着技术指标看，但大厂面试官非常看重技术对业务的支撑能力。
3. 手写题与基础题实录：每题背后的考察逻辑
3.1 第一道手写题：防抖函数，别只写个能用的版本
项目深挖结束，面试官切换到共享屏幕模式，出了一道手写题：实现一个防抖函数。
这个题表面上看很基础，但想答好并不容易。面试官让你“写一下”和让你“写好”是两个概念。我当时写完后，他用鼠标画了一下我的代码说：“如果我希望第一次点击立即执行，后面在等待时间内不重复触发，但等待时间结束后可以再次执行，你要怎么改？”
这就是leading + trailing模式，很多人在算法题练习时没区分过这个场景。我的思路是：在防抖函数内部维护一个timer和一个记录上次执行时间戳的变量，调用时先判断当前时间与上次执行时间的差值是否大于wait，若大于则立即执行并更新时间戳，否则重新设置定时器延迟执行。代码层面我用一个闭包保存状态，返回新的包装函数，同时处理this指向和参数透传问题。
注意：写防抖函数时，this的绑定是很多人容易漏掉的细节。防抖内部的执行上下文应该是调用者，而不是防抖函数本身，所以必须用function关键字的动态this，或者显式bind(target)。用箭头函数直接包裹就会踩坑。
面试官接下来追问：“如果这时候用户快速触发了十次，你怎么保证最后一次一定执行？”这就是要加timer兜底逻辑。核心就是：每次触发都先clearTimeout再重新开始计时，这样在等待窗口期内的触发会不断重置计时器，最后一次触发后的wait毫秒才真正执行。写完这些之后，面试官满意地点了点头，这道题算过。
3.2 事件循环输出题：经典但容易翻车的点
第二道题是代码输出题，大致内容是：
async function async1() { console.log('async1 start'); await async2(); console.log('async1 end'); } async function async2() { console.log('async2'); } console.log('script start'); setTimeout(() => { console.log('setTimeout'); }, 0); async1(); new Promise((resolve) => { console.log('promise1'); resolve(); }).then(() => { console.log('promise2'); }); console.log('script end');这道题考的是对事件循环、微任务队列、async/await执行顺序的综合理解。我当时的输出是：script start → async1 start → async2 → promise1 → script end → async1 end → promise2 → setTimeout。
关键难点在于async1 end和promise2的顺序。很多人会搞错，认为promise2应该比async1 end先输出，其实要分情况。这里的严格顺序取决于V8引擎对await的处理方式：模块内的await后面是微任务，promise1的then也是微任务，但异步函数的resume逻辑在Promise内部先注册了then回调，相当于先入队，所以async1 end先输出。不过在不同版本的Node或浏览器里，这部分行为确实出现过细微差异，如果你在面试中遇到这道题，明确说明当前环境的执行顺序，并解释清楚为什么async1 end先于promise2输出，面试官会更认可你的理解深度。
写完这道题后，面试官追问了一句：“如果await后面跟的是一个已经resolve的Promise变量，和直接写一个普通值，执行时机有区别吗？”这个问题是微任务的进阶考点。在ES2017之后的规范中，await一个非Promise值会经过PromiseResolve包装，同样会进入微任务队列，不会同步执行。所以即使是await 1这样的写法，后续代码也是异步执行的。但这段逻辑和V8引擎的优化有关，较新版本的V8对await做了优化处理，减少了额外的一次微任务开销。答到这一层，说明你不仅仅是刷过题，而是真正读过规范或源码，面试官一般会认可。
3.3 深拷贝手写题：边界情况才是真正的考点
第三个手写题是实现深拷贝。说实话，这个题我准备很充分，但面试官还是问出了我意料之外的变体。
基础版本很简单：判断类型、递归处理。用Array.isArray判断数组，用obj.constructor判断普通对象还是Date、RegExp等特殊对象，然后递归拷贝。但面试官很快抛出一个陷阱：“如果对象里有循环引用怎么办？”这就是要用WeakMap来存储已拷贝的引用，当遇到循环引用时直接从WeakMap里取，避免死循环。
他接着又问：“如果对象里有Symbol作为key怎么办？”这就涉及Object.getOwnPropertySymbols和Reflect.ownKeys的实现细节了。完整的深拷贝实现应该考虑普通字符串key、Symbol key、不可枚举属性，以及对特殊对象类型的处理。我在白板上写了两个版本，第一版是日常工作够用的，第二版是覆盖循环引用和更多边界情况的完整版本。
经验：面试时手写题不要一上来就写完整版。先实现一个朴素的可用版本，再说“但我考虑还有几个边界情况可以优化”，然后逐步加上WeakMap循环引用处理、特殊对象类型判断。这种“从简到繁”的答题节奏，比一口气写完整版更能展示你思考问题的层次感。
面试官最后还问了一个实际场景衔接题：“如果你在做深拷贝时发现对象里有个字段特别大，拷贝特别慢，你怎么优化？”这个是考性能敏感度。我当时回答了几种方案：按需拷贝（利用Proxy懒拷贝）、或者用structuredClone代替手写深拷贝、对大字段做特殊处理。虽然他没有继续深挖，但这一问一答其实已经在考察你在实际业务中做性能优化的习惯了。
3.4 前端缓存：从基础概念到实际排障的完整链路
基础题部分，第二个大块是浏览器缓存。面试官先抛出一个业务场景：“线上有个资源更新了，但是用户拿到的还是旧版本，你会怎么排查？”
这就是典型的从实际场景切入，考察你对HTTP缓存机制的理解。我的回答路径是：先打开DevTools的Network面板，确认资源请求的状态码，判断是200还是304，再看响应头里的cache-control和expires，判断命中的是强缓存还是协商缓存。如果是强缓存命中导致拿不到新版本，优先考虑给构建后的静态资源加hash，让文件内容变化后URL也变化，从源头避免强缓存干扰。如果是协商缓存的问题，则要看服务器是否正确返回ETag或Last-Modified，并在校验时是否合适地返回304。
这里有个经验之谈：跟面试官聊缓存时，尽量别停留在“什么是强缓存、什么是协商缓存”的复读层面。我提到了一个真实案例：项目里静态资源走CDN，更新版本后在部分用户手机上仍显示旧页面。最后定位到原因是CDN节点的缓存时间设置过长，即使文件内容变化了，CDN边缘节点仍然用旧缓存响应请求。解决方案是在CDN配置中调整缓存规则，核心业务文件不走长缓存，或者配合版本号管理来强制刷新。这个案例一讲出来，面试官明显感觉很真实，因为这是业务中真正会遇到的问题。
3.5 事件循环、闭包与作用域链：为什么前端面试绕不开这些
除了上述题目，面试官还让我解释了一下闭包是什么、闭包有什么缺点、如何避免闭包导致的内存泄漏。
闭包这个概念每个前端都会说“函数里面返回函数，子函数引用了父函数的作用域变量”，但面试官显然想听更深一层的理解：函数创建时所处的作用域链被保留下来，即使父函数执行完毕，子函数仍然可以访问父函数的变量。从底层来说，这是执行上下文中作用域链的延续。
追问的缺点是“闭包可能导致内存泄漏”这个经典论调。我当时的回答是：闭包本身不会导致内存泄漏，真正的内存泄漏通常是因为闭包引用了本不需要长期存活的对象，导致这个对象无法被GC回收。比如在事件监听器里使用闭包但忘记解绑，或者大数组被闭包持有。理论讲清楚之后，再给一个实际操作建议：在Vue项目里，如果在setup函数里声明的变量被闭包引用，且这个闭包被全局事件总线持有，组件销毁时这个闭包仍然存活，就会导致组件实例无法被回收。解决方式是在组件的onUnmounted钩子里清理事件监听或取消订阅。
这道题让我意识到，字节面试的八股文其实都是带着业务影子出现的。他们考闭包，不是因为这是面试题库里的经典题，而是因为闭包导致的引用持有问题，在业务开发中确实频繁出现。
4. 框架原理与工程化：一面躲不开的两座山
4.1 Vue响应式原理：从Object.defineProperty到Proxy的演进
面试官在基础题之后，把话题切到了框架上：“你们项目用Vue3比较多，那聊聊Vue3的响应式原理吧。”
这是前端面试八股文里的一座大山，但我不建议直接背“Proxy拦截get和set”的结论。我的回答分了三个层次：先讲Vue2时代的Object.defineProperty是怎么实现响应式的，再讲Vue3为什么要换成Proxy，最后讲两者的差异在实际开发中到底带来了什么感知变化。
Object.defineProperty通过拦截对象的属性读取和赋值来实现依赖收集和派发更新，但它的先天局限是：新增属性和删除属性无法被感知，所以Vue2才需要Vue.set和Vue.delete来弥补，数组的下标变化也需要劫持数组方法才能触发更新。Vue3换用Proxy之后，直接在对象层面做了代理，无论是新增属性、删除属性还是数组索引变化，都能被统一拦截到，依赖收集和触发的粒度也变成懒收集，没渲染用到的数据不建立依赖，性能上有明显提升。
面试官追了一问：“那Vue3的依赖收集具体是怎么做的？”这需要深入到effect、track、trigger这套机制。简单说，在组件渲染时会把当前的副作用函数（effect）作为全局依赖收集的目标，当渲染函数读取响应式数据时，通过Proxy的get拦截触发track，将数据和当前effect关联；当数据变化时，set拦截触发trigger，找到关联的effect并重新执行。这套机制核心是用一个WeakMap维护“对象→属性→依赖集合”的关系链。
另外他还问到了ref和reactive的区别。这个是在实际开发中就会遇到的用法问题：reactive只能处理对象类型，ref通过给基本类型包一层对象也能实现响应式。平时写代码很少有人深究为什么统一用ref，原理上的差异在于基本类型值无法被Proxy直接代理，只能通过对象包装来实现引用传递。
4.2 虚拟DOM与diff算法：性能优化的底层逻辑
框架部分的第二个重点问题是虚拟DOM和diff算法。面试官的切入方式是：“你项目中遇到大数据量列表，为什么改用虚拟列表？虚拟DOM能解决什么？”
这个问题的核心在于理解虚拟DOM的真实价值。它不是为了让DOM操作更快，而是为了在状态变化时，以最小的代价更新真实DOM。通过对比新旧虚拟节点的差异，找出真正需要变更的节点，减少不必要的重排和重绘。diff算法的核心逻辑是同层对比、双端指针优化、依靠key值复用节点。
我提到了Vue3中diff算法的“快速路径”优化：对于没有绑定key的列表会走简单复用逻辑，对于isSameVNodeType为true的节点会复用DOM元素，只做属性的patch。而React的Fiber架构则引入了可中断的调度机制，把diff过程切分成可打断的单元。两者思路不同，但都指向同一个目标：让UI更新更高效。
面试官顺着追问了一个业务场景题：“如果遇到大数据量且频繁更新的列表，除了虚拟列表，还有什么优化策略？”我回答了几种：数据分片渲染（setTimeout分批添加）、使用requestIdleCallback在浏览器空闲时段处理、开启will-change提示浏览器做图层优化、如果只是局部数据变化则精确到组件级别的更新。这个环节主要考察你平时是否真的做过性能优化，而不是只会背概念。
4.3 前端工程化：从模块化到微前端的完整布局
工程化这块面试官主要问了两个方向。第一个是关于模块化方案的理解，第二个是关于微前端的实际看法。
模块化的提问方式是：“CommonJS和ES Module的区别是什么，实际项目中怎么选择？”这个问题很基础，但考察点挺细：CommonJS是运行时加载，导出的是值的拷贝；ES Module是编译时加载，导出的是值的引用，且支持静态分析和tree-shaking。再加上浏览器对ES Module的原生支持，以及Node.js环境里CJS和ESM的互操作问题，基本就把这个知识点答全了。我还补充了当前Vite这类构建工具为什么默认走ESM，因为它能让开发服务器只需要在请求时做即时编译，不用整个项目打包，启动速度和热更新体验会好很多。
微前端是我主动提起的，原因是在上一个项目里用qiankun做过业务系统的微前端拆分。面试官马上追问了：“qiankun的核心原理是什么？样式隔离和JS沙箱怎么做的？”
我详细答了一下：qiankun的JS隔离通过Proxy代理window对象，子应用在访问和修改全局变量时都被限制在代理环境中；样式隔离通过动态样式表追加和移除，配合Shadow DOM或CSS命名空间的方式在运行时隔离样式。主应用通过import-html-entry加载子应用的HTML入口文件，解析出JS和CSS后再执行。说实话这块能答到“JS沙箱基于Proxy快照”这个粒度，面试官就基本判断你有没有真正实践过微前端了。
不过我最后补了一句：“微前端也不是银弹，它主要解决的是多团队独立开发、独立部署、技术栈异构的问题，但如果你们的业务都是同一个团队维护，强行上微前端反而会增加通信成本和加载性能损耗。”这种带着批判视角的回答，反而能让面试官觉得你是有独立判断能力的。
4.4 性能优化实战：从首屏加载到长任务优化
性能优化是面试官几乎一定会问的工程化方向，这次是以一个问题展开的：“现在前端首屏加载太慢，你会从哪些方向去分析和优化？”
我的回答是按链路拆的：网络层面、渲染层面、代码层面。网络层面先看请求数量、资源体积、CDN是否生效、是否开启HTTP/2或HTTP/3，然后考虑做资源合并、图片懒加载、字体子集化。渲染层面看是否存在长任务阻塞主线程，用Performance面板录制一段加载过程，观察FCP、LCP、CLS这些指标，定位是JS执行时间过长还是布局抖动严重。代码层面考虑路由级代码分割、第三方包按需引入、以及把非首屏需要的逻辑在空闲期加载。
面试官接下来追问了一个细节：“你提到的长任务具体是什么样的？怎么定位？”我结合项目经历讲了一个案例：排查一个页面在数据加载后卡顿500ms的现象，录制Performance后发现有大量的同步循环计算和DOM遍历操作，定位到一个表格组件在渲染前对全量数据做排序和格式化处理，复杂度和数据量都是O(n²)级别的。优化方式是把这个处理逻辑拆分到异步任务执行，配合requestIdleCallback在浏览器空闲期分片处理，或者直接用Web Worker处理纯计算部分，避免阻塞主线程。
这个案例无意中也踩中了热词里的“前端使用worker上传大文件”方向，我在后面反问环节还专门问了面试官对Web Worker在业务中的应用边界怎么看，他说在日常业务中Worker非常适合纯计算密集型任务，比如文件上传的分片处理和哈希计算，但跨线程通信有序列化成本，不能滥用。这个观点和我实际项目里的感受完全一致。
5. 反问环节与面试复盘：面完之后最有价值的沉淀
5.1 反问环节我提了什么问题
常规流程走到最后，面试官说“你有什么想问我的吗”，这绝对不是客套，而是真的在给你机会展示你的思考维度。我记得字节有一面反问被刷掉的情况，因为候选人问了一个在官网或者文档里就能查到答案的问题，这会被解读为“没有做基本功课”。
我问了两个问题。第一个是关于团队的：“飞书前端的业务迭代节奏很快，团队在技术方案上是怎么兼顾快速交付和代码质量的？”这个问题既体现了对业务压力的认知，也体现了对工程化规范的关注，面试官听完之后明显多聊了几句，说他们有统一的code review流程和发布前检查机制，以及一些自动化的质量看板。
第二个问题是：“针对我今天的面试表现，在后续准备中还有哪些建议？”这个问题等于主动要求对方给你反馈，虽然很多面试官不会直接评价，但能表现出你是一个重视复盘和成长的人。面试官很坦诚地提了一条：在讲项目的时候可以多讲一些决策过程的权衡对比，而不只是描述功能和结果。这个建议对后面的面试非常有帮助。
5.2 复盘：哪些地方答得好，哪些地方还能更好
面完我复盘了一遍，给自己挑了几个重点问题。
答得比较顺利的部分是第一道手写题和项目深挖的环节。防抖的leading/trailing模式因为之前在做输入搜索功能时确实实吃过类似场景，答得比较有感受；项目深挖因为准备充分，从方案选型到性能优化再到业务收益，整个逻辑链条是完整的，面试官在那段对话里也给了不少积极的反馈。
答得不够满意的是关于微前端JS沙箱这部分。面试官问到底层实现细节时，我在JS沙箱的具体实现方式上只能说个大概，没有深入到一个具体方案的源码级理解。后来复盘时去查了qiankun的源码，发现它不仅仅是简单的Proxy代理，还有快照沙箱和Proxy沙箱的差异、以及针对旧版本浏览器不支持Proxy时的兼容方案。如果面试官再往深问，我大概率会在那一环露怯。这个事给我提了个醒：简历上写到的技术栈，一定要做好被问到底的准备，不懂的原理宁可不写，写了就最好能说到源码层面。
5.3 给准备字节系前端面试的人几条建议
结合这次一面经历和过去几年大厂面试的准备心得，我整理了几条直接能用的建议。
第一，项目故事的讲述方式比项目本身更重要。用“背景→难点→方案→落地→结果→反思”的结构讲项目，每个环节都准备两个面试官可能追问的细节，尤其是“为什么选这个方案”和“还有其他方案为什么不选”这两个问题，几乎必问。
第二，手写题部分不要背题，要理解题目背后的工程场景。字节的面试官非常喜欢在基础题型之后追加一个业务场景变体，比如写完了防抖紧接着就问搜索场景中如何配合取消请求、写完了深拷贝紧接着就问大对象拷贝时的性能问题。你要是只会背标准解法，变体题一出，很容易露馅。
第三，基础八股文不能只背结论，要能讲清楚演进过程和取舍。比如Vue2和Vue3响应式的区别、CommonJS和ES Module的区别、强缓存和协商缓存的取舍逻辑，这些“为什么”和“不为什么”才是面试官真正想听到的。
第四，反问环节一定不要说“没有”。你可以问团队的工程技术栈、问新人的培养路径、问团队的代码评审流程、问当前业务遇到的最大技术挑战。这些提问方向都会让面试官觉得你是认真在考虑和团队一起工作，而不只是来走个过场。
从约面到走出视频会议室，整个飞书一面大概就这些内容。说实话，飞书一面的考察风格和网上流传的字节面经比较吻合：不搞偏题怪题，所有问题都围绕前端日常必用的基础能力和业务落地能力展开，但每个题都会往下深挖几层，直到触到你的知识边界。面试官没有刻意刁难，全程更像是一次技术交流，你抛出一种思路，他顺着思路追问边界，你能感觉到他是在认真判断你的技术水平，而不是在背题库打分。
这次一面整体感觉题目都在准备范围内，但在微前端沙箱原理这个点上暴露了深度不够。我已经在补源码了，如果后续收到二面通知，再回来更新。祝正在准备字节系前端面试的同学，都能拿到想要的offer。
