Runhua Zhao我上一篇文章刚聊完游戏公司前端的技能树取舍，就有好几个读者来问莉莉丝的一面情况。说实话，莉莉丝这种自研游戏项目偏重的公司，前端一面和普通互联网公司的考察点既有重合，又有明显的业务侧重。我在整理面经时发现，很多候选人不是不会做题，而是不知道这道八股文题背后面试官到底在验证什么能力，导致答得浅、答得散、答不到点上。这篇就结合莉莉丝2026年2月5日的前端一面真实面试题，做一次完整拆解，把每道题的考点、原理、答题话术和加分细节全部展开。不管你是正在准备春招的应届生，还是想跳槽进游戏行业的前端工程师，这篇都能用得上。
1. 莉莉丝前端一面：面试流程与考察维度拆解
1.1 莉莉丝一面的整体节奏与游戏公司特征
莉莉丝的一面通常维持在50到60分钟，前20分钟会围绕简历项目和实习经历展开追问，中间30分钟是密集的八股文基础考察，最后5到10分钟留给候选人反问。这里有个很明显的信号：莉莉丝一面并不期待你直接上手写复杂逻辑，而是用高密度的基础题目快速验证你的技术下限。因为游戏公司前端团队规模通常比电商、内容平台类公司小，业务上要承接官网、活动页、玩家社区、中台系统、可视化报表等多个方向，一个人可能要同时对接多个项目，基础不牢就意味着后续带人成本极高。
游戏公司前端一面还有个特点：很关注“性能敏感度”。游戏业务的活动页和大促页流量波动极大，一个运营活动上线前要经过多轮压测，首屏时间、资源体积、接口并发都是硬指标。所以面试题里只要涉及渲染、加载、缓存、打包，面试官都会多追问一层为什么，而不是满足于你背出定义。
1.2 一面考察的四大能力坐标
从我整理的面经样本来看，莉莉丝一面基本围绕四个能力坐标展开：JavaScript语言功底、浏览器运行机制、前端框架原理、工程化与安全基础。这四块对应的是前端工程师日常工作中最常接触、也最容易出问题的深水区。
JavaScript考察聚焦闭包、原型链、事件循环、this指向、异步编程，这些是手写题和输出顺序题的常客；浏览器运行机制考察缓存、渲染流程、从输入URL到页面展示的完整链路；框架考察React Hooks的渲染逻辑、setState机制、组件通信、性能优化手段；工程化与安全考察webpack/Vite区别、XSS和CSRF防御、常见构建优化策略。整个一面下来几乎不碰具体业务，而是看你在脱离业务的前提下，能不能把技术原理讲清楚。
这里我说一句实在话，很多候选人觉得八股文面试是“背题大会”，但从面试官视角看，八股文其实是成本最低的能力探测工具。一道闭包输出顺序题，能同时测出你对作用域链、变量提升、定时器机制、事件循环的理解深度。一道XSS问答题，能看出你有没有真实处理过用户输入、有没有在项目里写过防御逻辑。所以别把八股文当负担，它是展示思维方式的舞台。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. JavaScript地基：必考八股的深度答法
2.1 闭包与原型链：摆脱背书腔的正确姿势
先看一道莉莉丝一面大概率会出现的手写题：
javascript复制for (var i = 0; i < 5; i++) {
setTimeout(() => {
console.log(i);
}, 1000);
}
说真的，这道题已经烂大街了，但面经反馈中依然有一半候选人只能答出“输出5个5”，却解释不清为什么。面试官接着抛出的经典追问是：怎么改成输出0、1、2、3、4？请至少说出三种方案。
第一种是var改let，这个基本都能答上；第二种是用闭包包裹一层立即执行函数，把每次的i作为参数传入；第三种是使用bind绑定当前值，setTimeout回调绑定参数；第四种是配合Promise和async/await让异步执行顺序可控。到这里，面试官其实已经在验证你对闭包的理解是否到位了。真正能拉开差距的是面试官继续追问：let方案为什么能行？let在底层做了什么？
这里要答到关键点：let声明的变量在每次循环迭代中都会创建一个新的词法环境，简单说就是每次循环的i都是独立绑定，闭包捕获的是当次迭代的绑定值；而var只存在一个函数级作用域，循环结束后统一访问的是同一个变量对象。这个区别要结合作用域链来解释，不能只停留在“let有块级作用域”这层。
接着面试官可能顺势考原型链。我见过的一道莉莉丝真题是：
javascript复制function Foo() {}
Foo.prototype.getName = function() { return 'foo' };
const foo = new Foo();
console.log(foo.getName()); // ?
console.log(foo.hasOwnProperty('getName')); // ?
console.log(foo.constructor === Foo); // ?
console.log(foo.__proto__ === Foo.prototype); // ?
第一问输出foo没有问题，第二问false，第三问true，第四问true。关键是第四问之后的连环追问：如果我想在一面里展示深度，可以主动补充一句“constructor属性是原型对象上的一个公开属性，正常情况下指向构造函数本身，但如果我们把Foo.prototype整体重新赋值了，constructor就会丢失指向，需要手动修正”。这个细节很多候选人不知道，一旦说出来，面试官会觉得你的原型链知识不是背的，而是真正理解过。
2.2 事件循环与微任务/宏任务：输出顺序题的高分模板
莉莉丝一面有一类题几乎必考，就是事件循环输出顺序。它的变体很多，但考察内核一致：区分同步代码、微任务、宏任务的执行时机。我挑一道比较有代表性的题拆解：
javascript复制console.log('start');
setTimeout(() => {
console.log('timeout1');
Promise.resolve().then(() => {
console.log('promise1');
});
}, 0);
Promise.resolve().then(() => {
console.log('promise2');
});
queueMicrotask(() => {
console.log('microtask');
});
console.log('end');
正确的输出顺序是：start、end、promise2、microtask、timeout1、promise1。但面经里显示，很多人会把timeout1和promise1的顺序搞错，更多人不知道queueMicrotask和Promise.then属于同一梯队。
这里我建议用一套固定模板回答，既清晰又显专业。第一步，先找同步代码，按执行顺序输出；第二步，看微任务队列，把所有resolve回调、queueMicrotask回调按入队顺序执行；第三步，当微任务队列清空后，再从宏任务队列取出第一个任务执行；第四步，宏任务内部如果又产生了微任务，要等当前宏任务执行完后先清空微任务队列，再进入下一个宏任务。
回答时还要主动提一句“浏览器的事件循环和Node.js事件循环存在差异，主要在Node 11版本以后行为趋于一致，但像process.nextTick和setImmediate的执行顺序在Node里是独特的”。这句话的价值在于让面试官知道你有跨端意识，而游戏公司通常有Node.js中间层或工具链开发需求，这正好踩在他们的人才期待上。
2.3 this指向与箭头函数：高频送分题也有大坑
this指向问题莉莉丝一面几乎没跑过。面试官常用的一个场景是：
javascript复制const user = {
name: 'lilith',
getName: function() {
return this.name;
},
getNameArrow: () => {
return this.name;
}
};
console.log(user.getName());
console.log(user.getNameArrow());
第一行输出lilith，第二行输出什么？答案是undefined，但如果运行环境非严格模式，实际是undefined，因为箭头函数的this继承自定义时的外层作用域，也就是全局环境，所以拿不到user.name。有人可能会答错成window.name，需要看严格模式，严谨的答法是“箭头函数没有自己的this，捕获定义时外围上下文的this值，这里外围是全局，所以访问不到name属性”。
这道题的高分答法要在第一时间点出“方法调用约定”和“词法作用域”的区别：普通函数的this由调用时的点号调用约定决定，谁调用指向谁；箭头函数的this由定义时的词法环境决定，不随调用方式改变。然后可以补一句实际操作中的经验：不建议在对象方法上使用箭头函数，除非明确知道要捕获外围this，最典型的是React类组件中的事件处理函数，为了绑定this而使用箭头函数属性。
3. React与框架原理：一面怎么问才不吃亏
3.1 函数组件与Hooks的渲染流程
莉莉丝是国内最早大规模使用React来做运营后台和内容管理系统的头部游戏公司之一，一面问React的深度不会浅。我整理的面经样本里，有个问题频繁出现：一个函数组件从首次挂载到状态更新，经历了哪些阶段？请结合Hooks的执行机制说明。
这道题的完整回答分四层。第一层，首次渲染时React调用函数组件，执行内部所有Hooks，按调用顺序收集状态，生成虚拟DOM；第二层，React进行diff后提交更新到真实DOM，并在提交完成后执行useEffect中的副作用；第三层，当useState的更新函数被调用时，React把更新标记为待处理，并在下一次渲染时重新执行组件函数；第四层，Hooks的执行必须保证每次渲染调用顺序一致，否则React无法把当前状态与对应的Hook关联。
面试官在这个问题上的追问通常会集中在依赖数组上。比如：useEffect的依赖数组传空数组和完全不传有什么本质区别？这里要答清楚：完全空数组表示“只在挂载后和卸载前执行”，当然在React18严格模式开发环境下会额外执行一次来暴露副作用问题，这点要主动强调；完全不传表示“每次渲染后都执行”，这通常不是你想要的行为，但也是清理副作用的常见入口。如果依赖数组元素发生变化，React会在本次渲染提交完成后执行新的副作用函数，并先执行上一次的清理函数再执行新的回调。
3.2 setState同步还是异步：经典八股背后的原生逻辑
莉莉丝一面有个高频追问：setState到底是同步还是异步？很多候选人只回答“在React18自动批处理下都是异步的”，这个答法其实不够严谨。
准确说法是：setState本身是同步更新状态的，也就是说调用setState后立即读取state，拿到的可能仍然是旧值，因为state的变量引用在组件函数重新执行时才被更新。但在React18中，所有setState调用都会进入自动批处理，即同一个事件处理函数中多次调用setState只会触发一次渲染更新，这是“看起来像异步”的根本原因。在React18之前，Promise回调、setTimeout回调里setState不会走批处理，所以看起来是同步触发的，这也是很多老文章说“setTimeout里是同步”的历史背景。
加分回答可以补充：从React18开始，createRoot的默认行为就是自动批处理所有上下文中的更新，包括Promise、setTimeout、原生事件处理器。所以面试如果问React19，你可以直接说“批处理已经从事件系统扩展到几乎所有更新场景”。这条信息非常新，能有效向面试官传递“我在持续跟进框架更新”的信号。
3.3 性能优化：React.memo、useMemo、useCallback的使用边界
游戏公司对性能优化的考察几乎不会缺席，莉莉丝一面常见的是这样一组递进式提问：什么情况下React组件会重复渲染？如何减少子组件不必要的渲染？useMemo和useCallback到底该不该用？
第一问要答两点：父组件重新渲染时默认所有直接子组件都会重新渲染，无论子组件props是否变化；使用了useContext的组件，当context值变化时即使未直接依赖也会重新渲染。同时还要提到，渲染阶段执行的是组件函数本身，如果函数内部有纯计算或复杂派生数据，会消耗主线程时间。
第二问的核心工具是React.memo，它能对函数组件包裹一层浅比较，只有当props的浅比较结果不一致时才重新渲染。这里要特别提醒：React.memo只做浅比较，如果props里有对象或函数，每次父组件渲染都会创建新的引用，memo就形同虚设。所以在需要同时传函数和对象给子组件的场景下，useMemo和useCallback才有用武之地。
第三问很多人容易走极端。我的建议是：不要在组件里无脑给所有函数包useCallback，尤其当函数依赖了频繁变化的状态时，useCallback反而会让子组件在依赖变化时被迫更新，增加了无意义的比较成本。正确姿势是：先评估子组件是不是存在明显的渲染开销，比如大型表单、图表组件、列表项数量超过几百的项目，再决定是否做缓存。这里面有个实际项目里的经验：把useCallback的依赖数组写好，比包一层缓存更重要，因为依赖写错导致的闭包过期问题，比性能问题更难排查。
4. 浏览器与网络：从缓存到安全
4.1 HTTP缓存机制：强缓存与协商缓存的全链路拆解
我前面提到的莉莉丝面试题里，有一组关于HTTP缓存的考察也很典型，面试官会先问：浏览器缓存有哪些类型？给我一个完整的缓存判定流程。然后追问：Cache-Control的max-age和Expires有什么区别？如果服务端同时返回了ETag和Last-Modified，浏览器会优先使用哪一个？
第一问的完整回答是：强缓存和协商缓存两大类。强缓存命中后直接从本地读取资源，不再发请求，相关字段主要是Cache-Control和Expires；协商缓存命中后要发条件请求到服务器做验证，服务端返回304或200，相关字段是ETag/If-None-Match和Last-Modified/If-Modified-Since。
第二问要答出关键区别：Expires是绝对时间，依赖客户端本地时间，一旦用户改了系统时间就会失效；Cache-Control的max-age是相对时间，单位是秒，不受本地时间影响，优先级更高。我在项目里的实际做法是：静态资源都设置Cache-Control: max-age=31536000, immutable，因为文件名带hash，内容变了文件名就变，永远不会出现缓存旧资源的问题。这种情况下不需要协商缓存，因为它已经是最强缓存策略了。
第三问的准确答案是：优先用ETag。因为ETag是根据文件内容生成的哈希标识，只要内容变了，ETag就会变；而Last-Modified只精确到秒，同一秒内修改多次文件它也没法区分。服务端在收到If-None-Match后，只要比对一致就直接返回304，不会再看Last-Modified。回答这个的时候还可以补充：通常服务端返回ETag时会同时返回Last-Modified，但校验时以ETag为准。这是CDN场景下非常关键的缓存逻辑，游戏公司运营活动页基本都有CDN接入，这个知识点能直接应用在他们业务里。
4.2 从输入URL到页面渲染：考察点其实在细节
这道题很多人以为很简单，但莉莉丝的面试官喜欢在几个细节上不断加问。整体链路是：URL解析、DNS解析、建立TCP连接、发送HTTP请求、接收响应、浏览器解析HTML构建DOM树、解析CSS构建CSSOM树、执行JavaScript、合成渲染树、布局、绘制、合成。
容易被追问的细节有三个。第一个是DNS解析本地缓存和系统缓存的优先级；第二个是TCP连接时存在TLS握手，也就是HTTPS场景下除了TCP三次握手还有TLS握手，一共可能要经历多个往返；第三个是CSS不阻塞DOM生成，但阻塞渲染树的生成，script标签默认阻塞DOM构建，所以要放body底部或使用defer/async属性。defer和async的区别也要答清楚：defer会等DOM解析完再执行，并保证多个defer脚本按顺序执行；async是下载完成后立刻执行，不一定按顺序，而且可能在DOM解析中途执行，所以它不保证执行顺序。
游戏公司特别关注渲染性能，所以这里面试官还喜欢追问：CSS放在head、JS放在body底部，对性能有什么实际影响？答案是：CSS放在head是为了尽快生成CSSOM，避免白屏时间过长；JS放底部是为了防止脚本执行阻塞DOM解析。你可以再补一个关键细节：现代浏览器有预加载扫描器，它能提前发现link和script请求，但脚本执行仍然会阻塞主线程，所以脚本位置依然重要。
4.3 CSRF与XSS：安全八股的实际战场
安全相关的八股文在莉莉丝一面出现频率不低，因为游戏社区、玩家论坛往往有大量用户生成内容，XSS的防护压力比一般业务系统大得多。面试官通常会抛出一个场景题：假如你的论坛里用户可以发帖子，你会怎么防御XSS攻击？
完整回答分存储型、反射型、DOM型三种讲，然后落到防御措施：输入侧做转义和校验，输出侧做HTML实体编码，使用CSP限制脚本来源，对用户生成的富文本内容用白名单方式过滤标签和属性，禁用危险的style和事件属性。我建议实际项目中直接使用成熟库，不要试图手写过滤函数，然后补充一句“XSS的防御核心是永远不要在需要原文展示的地方直接插入用户HTML，除非你明确知道自己在做什么”。
CSRF的问题通常会问：CSRF攻击的本质是什么？怎么防御？本质是通过浏览器自动携带Cookie的特性，在用户已登录的高权限状态下，引导用户访问恶意页面并发起跨站请求。防御的三大手段是：CSRF Token校验，在表单或请求头中携带与用户会话绑定的随机token；SameSite Cookie属性，把Cookie设置为Lax或Strict，阻止跨站请求自动携带；校验请求来源的Origin和Referer头。
这里我的经验可以分享一个实际场景：如果前后端分离且前端是单页应用，CSRF Token就不太适合用Cookie来种，因为第三方请求也能读到Cookie。更好的做法是登录成功后由服务端通过接口返回token，前端放在内存或sessionStorage里，所有非GET请求在header里带上。这个方案虽然增加了token失效的处理成本，但能有效防止CSRF。莉莉丝这种大流量平台，CSP、Origin校验、SameSite属性基本是标配，能答到这一层，说明你不是只会背书。
5. 工程化与手写题：现场写代码怎么拿满印象分
5.1 前端工程化：webpack与Vite的核心区别与取舍
莉莉丝一面通常会有一道工程化问答题，最常见的切入点是：你们项目里为什么选择Vite而不是webpack？或者反过来问：你了解Vite的实现机制吗？
参考答案要分成开发和构建两个维度来讲。开发维度：Vite利用浏览器原生ESM，启动时不用打包整个项目，只做依赖预构建和按需转换请求的模块，所以冷启动速度远快于webpack；webpack开发模式需要从入口出发递归构建模块依赖图，再通过loader转换，项目越大启动越慢，HMR也要对修改的模块及其依赖链做重新构建和替换。构建维度：Vite默认使用Rollup做生产构建，处理兼容性需要通过@vitejs/plugin-legacy插件生成传统语法降级版本，而webpack的babel-loader方案更成熟。
面试官如果继续追问“Vite的依赖预构建解决了什么问题”，要答到两个数量级的问题：一个是将CommonJS/UMD格式的依赖转为ESM，解决浏览器只能加载ESM的限制；另一个是通过预构建把所有依赖打成一个或多个文件，减少浏览器在开发时发起的模块请求数量，避免每个npm包都成为独立请求导致开发页面卡顿。
这里我要多说一句，在真实项目里做技术选型时，并不能只看启动速度。webpack的插件生态和文档成熟度更高，很多老项目的自定义构建需求只能靠webpack顺利实现，Vite更偏向新项目快速起步。面试中如果能答出这个取舍逻辑，比单纯吹Vite多轮上手体验要好得多。
5.2 手写题实战：防抖节流、数组去重、深拷贝的完整实现
莉莉丝一面手写题通常会选两道基础题：防抖节流和数组扁平化或深拷贝。防抖的代码要按“标准思路+边界处理”来写，因为面试官会检查你对边界情况的处理。
javascript复制function debounce(fn, delay, immediate = false) {
let timer = null;
let isInvoked = false;
function debounced(...args) {
if (timer) {
clearTimeout(timer);
}
if (immediate && !isInvoked) {
fn.apply(this, args);
isInvoked = true;
return;
}
timer = setTimeout(() => {
fn.apply(this, args);
isInvoked = false;
timer = null;
}, delay);
}
debounced.cancel = function() {
if (timer) {
clearTimeout(timer);
}
timer = null;
isInvoked = false;
};
return debounced;
}
这里的加分点是：用了rest参数接收事件对象的参数，用apply绑定this保证内部拿到的this是实际调用者，并实现了cancel方法支持手动取消防抖。这三个细节缺一个都会被追求极致的面试官追问。
节流也是一样，时间戳方案和定时器方案各有优劣。时间戳方案执行点在前沿，也就是首次触发立即执行；定时器方案执行点在尾部，最后一次触发后delay毫秒才执行。实际项目中建议直接用leading + trailing双触发模式，用lodash/throttle即可，但面试要能讲清楚两者的差异。
深拷贝的完整实现要处理循环引用、Map/Set、Date、RegExp、函数等特殊类型。常见的错误是只处理了数组和普通对象，遇到循环引用直接栈溢出。我在面试中见过不少候选人写出的深拷贝只拷了JSON.parse(JSON.stringify())，虽然能用但无法处理undefined、函数、Symbol等值，这也是JSON方案的明确限制。能基于WeakMap处理循环引用的候选人在这一题上基本就是满分。
6. 一面实战复盘：候选人的翻车点与加分行为
6.1 高频翻车点：答非所问与知其然不知其所以然
我把莉莉丝一面的翻车点归纳成三类，第一类是回答过于简短，面试官问“什么是闭包”，候选人只答“函数里面返回函数”，完全没有提到内部函数引用了外部作用域变量、会导致外部变量常驻内存不被回收这两个核心特征。这个问题如果被面试官追问“那闭包会导致内存泄漏吗”，很多人只能答“会”，却说不清什么时候该手动把引用置为null，以及为什么现代V8引擎已经有了优化机制，普通闭包不一定造成泄漏。第二类是手写题没有考虑边界条件，比如写深拷贝忽略了循环引用，写防抖没有cancel方法，写Promise.all没有处理空数组和异常捕获。第三类是遇到不会的题目直接卡住不说话，这是面试官最不愿意看到的。
这里我特别提醒：如果真遇到不会的题，千万不要编概念。你可以先复述一遍问题，确认自己的理解是否正确，然后把自己知道的部分回答出来，最后坦诚说“这一块我目前只了解到这个程度，后续我会再深入补充”。这种处理方式至少能保住基本的沟通分，而且往往面试官会换一道相近但简单一点的问题给你。
6.2 加分行为：主动延伸与结构化表达
面经里逆袭的候选人通常都有一个共同点：回答问题时有意识地把知识点向外延伸。比如被问到Vite的特性，他会顺带提一句“Vite依赖预构建时使用了esbuild，所以比webpack的babel编译要快很多”，这就展示了他了解工具链底层的性能优势。延伸到相关知识点时，一定要保持准确，不要为了展示自己而强答，说错反而扣分更严重。
另一个加分点是结构化表达。我推荐一个固定话术：先结论后展开。“闭包是函数和声明该函数的词法环境的组合，它的核心特征有两个，第一内部函数能访问外部函数作用域的变量，第二这些变量不会在外部函数执行完后被立即回收，因此可以用来做私有变量或记忆化缓存。它的典型应用场景是防抖节流、柯里化和模块化模式。”这种表达在面试官听来就是“有产品思维的设计”，比东一句西一句强得多。
6.3 一面基础上的二面预测与准备方向
莉莉丝一面走到尾声时，面试官通常会问“你有什么想问我的”。这其实是候选人了解团队做技术栈和业务重点的好机会。我建议准备三到四个有质量的问题，比如：团队目前的前端技术栈是以React为主还是有Vue的存量项目？接近游戏发行的节点时，活动页和官网是怎么做性能压测的？团队对前端参与工程化建设和CI/CD流程的期望是什么？
二面大概率会往项目和场景题方向走，常见形式是给你一个实际业务场景，比如“玩家社区首页首屏优化你会怎么做”“运营后台大量表格数据的渲染性能如何优化”。面对这类场景题，我建议按三个维度回答：先做资源拆分和减少请求，再做组件层级的性能优化，最后做数据层与缓存策略的优化。三个维度递进，能显示出你有清晰的优化思维，而不是背了一堆API。
7. 面试后的复盘与小技巧
一面结束后的黄金24小时，一定要趁热打铁把被问到的所有题目记录下来，标注哪些答得好、哪些卡壳了。这里有个我长期坚持的小技巧：不要只记录题目和答案，要把“面试官追问了什么”也完整记下来。因为追问方向能反推出面试官真正关注的点。如果面试官只在闭包上追问了内存问题，说明他关心内存与性能的边界场景，那你下次准备时就要多强化这个方向的深层知识点。
莉莉丝一面整体给我的感觉是务实、直接，没有太多花哨的设计，但在每个问题上都会往上追问一层。建议基础扎实的同学在准备时把重心放在框架原理和性能优化这两块，尤其是React Hooks和浏览器渲染链路，几乎每一轮都会遇到。另一块容易被很多人忽略的是前端安全，如果你能自然地对XSS和CSRF给出项目实战级别的防御方案，面试官对你的好感度会明显提升。面试本身就是一场信息量的博弈，你把每一道题背后的原理链条都理清了，就不会紧张，也不会漏答，祝准备中的各位好运。