1. 一份笔试题背后的技术全景B站技术岗到底在考什么1.1 为什么2019年的卷子到现在还能当“练功房”先说个背景2019年的B站正处于业务高速扩张期视频、直播、社区三条业务线同时发力对技术同学的要求其实非常“业务导向”。这一点直接反映在笔试题里——它不是单纯的八股文默写而是把你在真实系统里一定会遇到的问题包装成题目丢给你。前端、后端、运维、移动端四个方向都被拉出来单独考察出题逻辑基本就是“这岗位进了公司第一年要干的事我提前用一套卷子验一验”。所以哪怕你现在去看这套题的年份已经过去几年但你拆开看里面的考点会发现大部分东西到现在依然是地基。比如前端的浏览器缓存策略、事件循环后端的并发模型、缓存设计移动端的列表优化、内存泄漏运维的Linux排查、网络问题定位——这些内容不会因为框架换了一轮就过时。反过来框架迭代得越快越说明底层原理重要。这套题真正适合的人不只是准备校招的同学。工作了两三年、想跳槽但不知道从哪里复习的团队里负责出招聘题的甚至带新人的技术组长都能从这套题里提炼出“技术自测清单”。它不是让你背答案而是让你看看自己哪块还没打通。1.2 四个岗位的考察底层逻辑业务场景驱动技术选型我在拆这套题的时候最大的感受是B站出题人非常清楚自己的业务长什么样所以每个岗位的考察侧重点都很鲜明。前端方向视频站的核心场景是“页面加载快不快、滚动顺不顺、弹幕卡不卡”所以JS基础、浏览器渲染机制、网络请求优化、框架原理这几块是重头。它不会只问你“闭包是什么”而是会给你一段代码让你说出输出顺序顺便把事件循环、微任务宏任务、作用域链全串起来。后端方向B站的后端以Java为主核心场景是“弹幕怎么写、评论百万并发怎么扛、视频元信息怎么缓存”所以并发编程、JVM、MySQL索引与事务、Redis、消息队列是考察重点。题目问法通常很直接比如“线程池参数怎么定”“缓存穿透怎么解决”“一条SQL为什么慢”但你要答好得有业务体量感。运维方向B站当时已经有了比较成熟的持续集成和容器化体系所以考察点不光是Linux命令、shell脚本还包括发布流程、监控告警、日志收集以及初步的Docker和Kubernetes概念。最简单的信号是如果只是“会敲几个命令”这套题你多半撑不过一半。移动端方向B站App的用户量大、机型分散所以性能优化是绝对主角。列表卡顿、启动速度、网络弱网体验、内存占用、包体积这些是高频考点。同时因为B站大量页面是WebView/Hybrid方案所以移动端工程师往往还需要懂一点前端知识题目里也会穿插RN、Flutter这类跨端方案的对比。这四块内容放一起就是一张完整的技术地图。前端和移动端管“用户看到的部分”后端管“业务逻辑和数据”运维管“系统稳定和交付效率”。这套题的本质是通过笔试筛选出“对系统有整体认知、而不只是会写局部代码”的人。2. 前端与移动端性能优化为什么是重头戏2.1 前端高频考点的出题套路与解答思路前端这套题我估计很多人拿到手第一反应是“怎么这么多场景题”。闭包、防抖节流、Promise、浏览器缓存、跨域这些基础考点都会出现但出题人一般会给你一个视频网站的真实场景让你去解决实际问题。举个例子弹幕渲染。B站的弹幕是高频写入、实时显示一秒钟可能有几百条弹幕数据从WebSocket推过来。如果每来一条就操作一次DOM页面必然卡死。所以题目会考察你“怎么用虚拟列表”“怎么批量插入DOM”“怎么用requestAnimationFrame控制弹幕位移”。这背后考察的是你对浏览器渲染管线的理解JavaScript执行、样式计算、布局、绘制、合成每一步都可能成为瓶颈。再比如浏览器缓存这是面试必问题。你必须把强缓存和协商缓存讲清楚Cache-Control里的max-age、no-cache、no-store分别代表什么ETag和Last-Modified的区别什么场景下用强缓存、什么场景下必须协商。对应到B站场景里视频封面、用户头像这类静态资源适合强缓存而评论区这种动态数据就不能缓存或者只能做短时间的CDN缓存。还有一个高频题是跨域。B站页面域名和接口域名往往不一样开发环境还要连本地服务这时候CORS怎么配、JSONP的原理是什么、代理服务器怎么解决开发环境跨域都是实打实会遇到的。做题的时候不要只背名词要能画出一条完整请求从浏览器发出到服务端返回的链路每一步涉及什么机制。2.2 移动端容易被忽略的性能细节移动端方向B站当年已经有几千万DAUApp性能直接影响留存。所以笔试题里很爱从这几个角度出题列表卡顿如何优化、App启动时间如何缩短、弱网环境下请求怎么处理。列表卡顿的本质是主线程被阻塞。常见优化手段ViewHolder复用、图片异步加载、分页加载、避免在onBindViewHolder里做耗时操作。但题目如果只答这些大概率不够。你要进一步说出“为什么RecyclerView的复用机制能减少卡顿”——因为减少了findViewById和item布局的重复inflate还要会算“FPS掉到多少用户会明显感知”——一般认为低于30帧就会觉得卡。启动优化是另一个高频题。冷启动流程里Application的onCreate如果做了太多初始化启动时间就会变长。你可以用Startup库做初始化任务排序和异步加载用TraceView或systrace定位耗时方法把非必要的SDK初始化扔到子线程或者按需加载。这里有个关键认知启动时间不是越短越好而是“用户感知到的首帧时间”越短越好所以要区分冷启动、热启动、温启动三种状态分别优化。弱网优化也常考。B站用户很多在移动网络下看视频弱网时请求超时、图片加载失败是常态。考点包括请求超时时间分级设置失败重试策略指数退避图片先用占位图再渐进加载视频播放器做码率自适应把清晰度切换做成无缝衔接。这些点不只要答方案还要能解释每个方案的取舍比如指数退避为什么比固定重试更合理——因为固定重试会在服务端异常时加重雪崩。2.3 调试工具与线上问题定位能力笔试题里还会出现一类题表面问“你平时怎么调试”实际考验你的工程素养。前端这边Chrome DevTools的Performance面板怎么分析长任务、Network面板怎么看请求耗时、Sources面板怎么断点调试这些是基本功。移动端这边adb logcat怎么看日志Android Studio Profiler怎么查内存泄漏Charles怎么抓包看接口返回。这里有个特别值得说的点vConsole。B站移动端页面很多内嵌在App的WebView里不能用电脑DevTools调试所以vConsole这类移动端调试工具几乎是刚需。你可以通过自定义protocol或者url参数注入vConsole脚本在真机上直接查看Console输出、Network请求和本地存储。这个技巧在笔试里可能只占一个小题但实际工作中能帮你省下大量排查时间。另外别忘了线上问题的排查思路。前端是埋点监控比如Sentry接一下把JS error、资源加载失败、接口异常全部上报移动端是崩溃日志崩溃堆栈需要符号化还原ANR要抓取主线程堆栈。考试不会让你写完整代码但你得把“发现问题→定位问题→修复问题→验证修复”这个链路说清楚。3. 后端核心考点从并发编程到高并发系统设计3.1 Java后端必考的并发与JVMB站后端技术栈以Java为主所以笔试题里Java并发和JVM是绝对主力。并发部分最常考的就是线程池。题目可能给你一段代码问线程池核心线程数、最大线程数、队列容量分别设多少、任务怎么拒绝。你得知道ThreadPoolExecutor的七个参数还要明白为什么核心线程数不能拍脑袋定。这里给一个实际参考口径CPU密集型任务核心线程数设为CPU核数1IO密集型任务可以设到CPU核数*2甚至更高因为IO等待时线程可以切换执行其他任务。但真实场景还要看队列容量和拒绝策略如果任务量波动大队列不能太长否则大量任务排队会让响应延迟飙升如果系统允许丢弃非核心任务可以选DiscardPolicy否则用CallerRunsPolicy让提交线程自己执行起到天然限流效果。JVM部分高频考点是内存区域划分、垃圾回收算法、GC日志分析。你需要能画出堆内存里的新生代、老年代、元空间布局说清楚Minor GC和Full GC的区别还要知道怎么用jstat、jmap、jstack这些命令排查线上问题。面试题里如果问“线上CPU飙高怎么排查”标准回答链是top找到高CPU进程→top -Hp找到高CPU线程→printf %x转十六进制→jstack抓线程栈→定位到业务代码哪一行。以及常被拿来当压轴题的是一个接口请求量突增你怎么保证系统不被打挂。这题考察的是综合能力你既要说业务侧限流Guava RateLimiter令牌桶算法、又要点出缓存的重要性、还要提消息队列消峰。B站的评论区、弹幕、点赞这类场景都是典型的读多写少把热点数据缓存起来能挡掉绝大多数流量。3.2 缓存、消息队列与数据库的三角关系后端笔试题里“缓存穿透、缓存击穿、缓存雪崩”是出题人最爱的一组概念。很多人只背结论但真到了场景题就露馅了。我用大白话重新捋一遍缓存穿透查询一个不存在的key请求绕过了缓存直击数据库。高并发下如果一个不存在的ID被疯狂请求数据库压力会很大。解决方法是缓存空值并设置短过期时间或者用布隆过滤器先把不存在的key挡掉。缓存击穿一个热点key在缓存过期的瞬间大量请求同时打到数据库。解决方法是加互斥锁只让一个线程去查数据库并重建缓存其他线程等待后直接读缓存。缓存雪崩大量key在同一时间过期或者Redis挂掉导致请求全部打到数据库。解决方法是在过期时间上加随机值错开过期时间Redis高可用部署时还要考虑主从切换的瞬断。数据库这块B站的业务场景决定了索引设计很重要。视频详情页按vid查询、评论列表按视频ID分页、用户动态按时间倒序每一条都对应一个索引设计题。你需要知道联合索引的最左前缀原则知道为什么不要对索引列做函数运算会让索引失效知道覆盖索引能减少回表查询。慢SQL优化也是一道经典题先EXPLAIN看执行计划看type是不是ALL全表扫描看rows扫了多少行再看有没有走索引最后才是考虑要不要改SQL或者加索引。消息队列在B站后端也有大量应用比如弹幕写入、评论异步通知、视频转码任务。笔试题会考察为什么用消息队列而不直接同步调用解耦、异步、削峰消息丢失怎么处理生产者确认、消费者手动ack消息重复消费怎么办消费方要做幂等。幂等这块容易答泛你要结合业务说比如评论点赞的记录表加唯一索引、处理订单时用状态机判重。3.3 从“前后端分离项目实战”推导出题方向还有一个很有意思的视角B站笔试题里很多后端题其实是从“前后端分离项目实战”的痛点里提炼出来的。前后端分离之后后端要提供RESTful API、做鉴权、解决跨域每一点都是时经常考的方向。RESTful接口设计会考URL怎么命名、HTTP方法怎么选、状态码怎么用、分页参数怎么设计。B站视频列表接口按分区、按时间排序、按播放量排序本质就是对GET方法和查询参数的合理规划。如果面试官再深挖一层会问你为什么GET请求不能带body做查询条件——因为缓存、幂等、历史遗留的代理层面都有坑。鉴权方案也很常考。早期很多项目用SessionCookie后来改成Token。Token方案里JWT特别流行因为它无状态、天然适合分布式环境。但你得知道JWT的缺点签发之后无法主动失效所以退出登录要靠维护黑名单payload不是加密的不能放敏感信息。B站这类大流量的场景更常见的是用网关做统一鉴权token校验和用户信息透传都在网关层完成。这套题里如果出现“你怎么设计一个视频上传接口”这种开放题你要马上切换到实战视角。需要考虑的点包括大文件分片上传、断点续传、服务端合并校验、调用转码服务、异步返回上传结果。对应到代码层面就是MultipartFile接收文件、Redis记录分片状态、Golang或Java起协程/线程池做合并且发送消息到MQ。这种题没有唯一答案但要展示出系统的思考层次存储→处理→通知→容错。4. 运维岗位考察点从Linux命令到容器化集群4.1 Linux常用命令与网络排查思路运维方向的第一道门槛就是Linux操作但笔试题很少直接让你默写命令而是给你一个故障场景让你现场排查。比如“线上某台服务器CPU使用率100%你怎么查”或者“用户反馈接口偶尔超时你怎么定位”这类题。CPU排查链路建议写成top看进程top -Hp pid看线程strace -p pid看系统调用如果发现线程栈都在执行同一段代码就去查代码里是不是有死循环或者锁竞争。如果是Java应用还要配合jstack抓线程dump看BLOCKED状态的线程。这里最容易被忽略的一步是先确认是CPU高还是IO等待高top里wa列数值大说明是IO瓶颈这时候盲目查CPU是浪费时间。网络排查是运维笔试题的另一座大山。常见命令要知道ping查连通性telnet或nc查端口traceroute看路由路径ss和netstat看连接状态curl -v看HTTP请求细节tcpdump抓包分析。我见过太多人连ss -tunlp都记不全但真实排障里这条命令查端口占用几乎是日常最高频操作。如果要考深一点会给你一个“Nginx返回502”的场景。502是网关错误意味着上游服务没响应。排查顺序是先看Nginx错误日志确认upstream是连不上还是超时再telnet测上游服务端口通不通通了就进到上游服务看它的访问日志和错误日志确认是不是本身处理太慢或者已经被打挂。笔试答题时能按这个链路一步步说基本就过了。4.2 持续集成与自动化部署流程2019年的B站已经不再靠手动打包传服务器了所以笔试题对CI/CD有明确考察。你要理解一条完整流水线代码提交到Git仓库→触发构建编译、单元测试、打包→部署到测试环境→跑自动化测试→构建Docker镜像→推送到镜像仓库→发布到预发环境→灰度发布→全量发布。Jenkins和GitLab CI是考察重点。GitLab CI用.gitlab-ci.yml定义pipeline包含stages、job、script、artifacts这些关键字Jenkins则是用Pipeline语法或者BlueOcean界面拖拽配置。Shell脚本也是必考比如要求你写一段脚本批量检查多台服务器的端口存活状态或者根据日期滚动清理日志文件。写的时候要注意加上set -e避免中间命令失败还继续往下走导致误判。容器化这块Docker的基本概念是绕不开的。你要能说清楚镜像和容器的区别镜像是只读模板容器是运行实例镜像分层存储每一层都是只读的容器层负责写入。Dockerfile的编写也有讲究比如要把依赖安装放前面、代码复制放后面充分利用层缓存基础镜像尽量选Alpine这类精简版减少体积和安全漏洞。CI里构建镜像之后还要关注镜像仓库的tag管理不能用latest要用Git commit号或者版本号标记。4.3 容器编排与Kubernetes的调用链路如果题目再进阶一点就会从Docker问到Kubernetes。考点通常是Pod、Deployment、Service、Ingress这几个核心资源分别解决什么问题以及一次请求从外部进来是怎么被转发到Pod里的。我举个实际例子B站这类视频网站很多服务已经跑在Kubernetes集群里。外部请求先到Ingress Controller通常是Nginx或TraefikIngress根据域名和路径路由到对应的ServiceService通过Label Selector找到一组Pod再通过kube-proxy维护的iptables或IPVS规则做负载均衡最终把请求转发到某个Pod里的容器端口。更深入一层面试官会问你“Kubernetes里的kubelet是怎么调用容器运行时创建Pod的”。这里的关键点是我们常说的容器运行时通过CRIContainer Runtime Interface标准对接containerd是当前最主流的实现之一。从原理到实体调用大概是kubelet通过CRI调用containerd的grpc接口containerd再通过containerd-shim启动并管理容器进程shim进程再实际调用runc去创建和运行容器。这套链路里的每个组件各司其职kubelet负责Pod生命周期containerd负责镜像管理和容器运行时的上层封装runc负责利用Linux内核的namespace和cgroup隔离进程。问到这里时能画出这条调用链再标出每层的作用面试官基本就满意了。4.4 监控告警与日志处理运维笔试里还有个很容易被忽略但实际特别重要的部分监控和日志。B站的系统规模决定了不能等用户投诉了才去修必须依赖监控提前发现异常。基础题会问你CPU、内存、磁盘、网络这些基础监控用什么工具Prometheus node_exporter Grafana是目前的主流组合业务监控指标怎么设计QPS、成功率、响应时间P99告警怎么避免轰炸分组、分级、静默、聚合。日志这块大流量下不能直接上服务器翻日志文件所以要搭集中式日志平台。早期的方案是ELKElasticsearch Logstash Kibana现在更多是Filebeat采集、Kafka缓冲、Logstash清洗、ES存储、Kibana展示。笔试题如果问“线上接口报错你怎么从日志里快速找到相关请求”考察的就是你懂不懂traceId贯穿全链路。解决方式是网关生成traceId通过threadLocal和HTTP header传递到各个微服务日志统一打印traceId日志平台上按traceId搜索整条调用链路一目了然。5. 实战模拟这套题我会怎么做5.1 四岗位通用基础题模拟不管考哪个岗位有些基础题几乎是必出。我按当年的风格整理了几类并给出了我的答题思路。第一类是网络基础典型如“从输入URL到页面展示发生了什么”。这题考察全链路理解答题时可以分四段DNS解析拿到IP→TCP三次握手建立连接→HTTP请求发送与服务器处理→浏览器解析HTML构建DOM树并渲染页面。后面还能扩展CDN命中、缓存判断、渲染过程中的重排重绘这样答既有广度又有深度。第二类是操作系统基础如“进程和线程的区别”。单独答概念很容易啰嗦更好的方式是结合场景进程是资源分配的最小单位线程是CPU调度的最小单位进程间内存相互隔离、线程共享进程内存。再举一个B站相关例子播放器进程和UI主线程分离即使解码卡顿也不至于让用户操作无响应这就是多进程结构的实际意义。第三类是HTTP状态码。206断点续传是B站视频播放、分片下载的核心基础301/302重定向在防盗链和CDN调度时经常出现429限流在高并发保护里很常见503则说明服务暂时不可用。你要能把状态码和业务场景对上而不是死记硬背。5.2 前端与移动端笔试题模拟前端题目我会押两道一道手写防抖节流一道设计一个页面性能监控方案。手写防抖节流不只是背模板。防抖的核心是“只执行最后一次”设置定时器每次触发都重置只有停止触发一段时间后才执行。适用于搜索框输入联想、窗口resize场景。节流的核心是“固定频率执行”设定间隔间隔内只执行第一次适用于滚动加载、按钮提交限制。我给你一个节流的实现思路记录上一次执行时间每次触发时比较当前时间和上次时间差超过阈值才执行并更新时间戳。页面性能监控方案则是开放性题目。你要能想到Performance APIperformance.getEntriesByType(navigation)拿导航计时observer监听资源加载要主动采集FP、FCP、LCP、CLS这些Web Vitals指标要把数据上报到监控平台并支持按页面、运营商、机型维度聚合。答题时体现出“采集、上报、分析、告警”闭环就会比只背概念高一个段位。移动端我会押一道“卡顿优化”题。答题框架可以这样展开先定位卡顿场景列表滑动、页面切换、动画播放用Systrace或者CPU Profiler看主线程耗时再根据结果针对性优化。列表类项目复用ViewHolder、把图片加载放到子线程并做三级缓存页面切换类项目减少主线程复杂的布局计算动画播放类项目用setLayerType开启硬件层加速避免动画过程中每帧都重新走measure/layout/draw流程。最后加上一句“用卡顿监控工具在线上持续观察”表明你是系统思维而不是临时补窟窿。5.3 后端笔试题模拟后端我会押一道“设计一个接口支撑高并发点赞/评论”的场景题。解题框架大概是先用缓存扛读请求点赞数量、用户状态这类热点数据放到Redis里用Hash或者String加过期时间保存写请求不直接落库先发到消息队列削峰再由消费任务批量写入数据库为了保证数据一致性Redis里只存增量定期全量刷到DB为了防止重复点赞用SETNX加分布式锁或者用数据库唯一索引兜底。这套流程里要把每个组件的角色说清楚Redis是快路径、MQ是缓冲路径、DB是最终一致性路径。还有一道很常见的“如何排查一个接口突然从100ms变成5s”的问题。我的排查顺序是先看监控平台确认是从哪个时间点开始变慢再看关联的慢SQL用EXPLAIN分析是否索引失效如果没有SQL问题看是否缓存命中率骤降比如Key批量过期导致打到DB再看下游服务是否异常比如调用的用户服务超时最后确认是不是流量突增导致线程池排队。笔试答题时把“先看监控、再看DB、再看缓存、再看下游、最后看自身”五步说全基本分就拿到了。5.4 运维笔试题模拟运维题目我预测会有一道“线上服务器负载突然飙高你怎么办”。我的回答路径是先用uptime看load average再用top看CPU和内存占用top里按P按CPU排序、按M按内存排序如果发现是某个Java进程CPU高用jstack抓线程栈并定位到具体代码如果是磁盘IO压力大用iostat看%util和await排查是不是日志刷太频繁如果是网络问题用iftop或者nload看流量趋势。整个过程要遵循“先看现象、再缩小范围、最后定位根因”的思路避免一上来就重启服务器。还有一类题会写一段YAML让你分析Kubernetes部署问题。例如Deployment定义了replicas3但实际Pod只有2个你会怎么排查。参考答案先kubectl get deployment看期望状态kubectl get pods看实际状态再用kubectl describe pod xxx看事件里的失败原因常见原因包括镜像拉取失败、资源配额不足、健康检查失败被反复重启。答这类题的关键是要有“描述describe一定是第一排查手段”的意识。6. 笔试翻车重灾区常见问题与避坑经验6.1 为什么你明明背了很多题笔试还是挂结合我自己看简历、出题、筛人的经验笔试翻车最常见的原因有三个。第一个原因是只会背概念不会用场景串联。比如问“TCP三次握手”很多人能背出SYN、ACK的流程但一旦问“为什么连接是三次、断开是四次”就答不上来。事实上三次握手是为了让双方都确认自己的发送和接收能力没问题而四次挥手是因为TCP是全双工两个方向要分别关闭。你在准备时每背一个概念都问自己一句“这个在B站什么场景会出现”这样知识才是活的。第二个原因是代码题写得太慢或者中看不中用。前端手写防抖节流不是把能把setTimeout写对就行你要是没考虑this绑定、没传参数、没做立即执行选项面试官一眼就能看出你是背的。后端手写单例模式双检锁版本如果不加volatile关键字指令重排可能导致拿到半初始化对象这又是经典的扣分点。我的建议是考前至少把高频手写题每种敲三遍敲到肌肉记忆为止。第三个原因是开放题没有结构。一旦遇到“你怎么设计一个XX系统”很多人想到哪说到哪完全没有层次感。好的答法一定是从底层到上层、从数据到接入层逐步展开。比如设计评论系统先说存储模型评论表、回复表怎么设计索引怎么建再说读链路先Redis缓存列表、再DB兜底然后说写链路先校验、再写DB、再删缓存/Delay双删最后说风控敏感词过滤、用户限评。有结构考官才能顺藤摸瓜给你加分。6.2 一套试卷的“以题带学”训练法我建议拿到这套题之后不要只看答案就完事而是把每道题当成一个学习地图的入口。比如你看到“慢SQL优化”就往深处挖索引为什么能加速查询、B树和跳表的区别、联合索引为什么最左匹配、EXPLAIN里每个字段怎么读。一个入口能带出十几个知识点比零散刷题高效得多。我自己带人的时候喜欢让他们把错题按主题归类。前端一张纸、后端一张纸、运维一张纸、移动端一张纸。每归类一次就逼着自己写一遍知识框架把相关内容补全。比如移动端性能优化这张纸上写完列表优化之后必然会牵出图片加载框架Glide/Fresco、内存缓存策略、磁盘缓存策略、生命周期管理。最后这张纸就是一版Mini Wiki面试前只翻这几张纸就够了。6.3 关于“答案”的一个提醒这套卷子的很多题并没有标准答案。出题人更在意的是你的推导过程而不是最终结论。比如线程池核心线程数设多少你直接说一个数不如说“我先估算接口的平均响应时间和QPS再反推线程数同时预留缓冲”。再比如缓存和数据库的一致性方案用Cache Aside Pattern还是延时双删取决于业务对一致性的容忍度如果允许秒级延迟Cache Aside配合过期时间就够了没必要上更复杂的方案。所以我的建议是做题时强迫自己写出“为什么要这样设计”的注释就算只是给自己看。它会逼迫你把每个决策背后的权衡想明白。笔试考的不只是知识储备更是一个人在技术取舍上的成熟度。这恰恰是校招笔试里最想筛出来的东西。个人经验是这套题我每年都会拿出来翻一遍每次重看都会有新的体会初看是知识点密集的考卷后来变成查漏补缺的工具再后来成了给团队出题的参考模板。技术岗位的底子拼到最后比拼的还是基础是否扎实、以及能不能把基础知识用业务语言讲清楚。这套题里的每个考点都是通向那个目标的好台阶。 B站技术岗笔试题深度解析：前端后端运维移动端考点全揭秘
1. 一份笔试题背后的技术全景B站技术岗到底在考什么1.1 为什么2019年的卷子到现在还能当“练功房”先说个背景2019年的B站正处于业务高速扩张期视频、直播、社区三条业务线同时发力对技术同学的要求其实非常“业务导向”。这一点直接反映在笔试题里——它不是单纯的八股文默写而是把你在真实系统里一定会遇到的问题包装成题目丢给你。前端、后端、运维、移动端四个方向都被拉出来单独考察出题逻辑基本就是“这岗位进了公司第一年要干的事我提前用一套卷子验一验”。所以哪怕你现在去看这套题的年份已经过去几年但你拆开看里面的考点会发现大部分东西到现在依然是地基。比如前端的浏览器缓存策略、事件循环后端的并发模型、缓存设计移动端的列表优化、内存泄漏运维的Linux排查、网络问题定位——这些内容不会因为框架换了一轮就过时。反过来框架迭代得越快越说明底层原理重要。这套题真正适合的人不只是准备校招的同学。工作了两三年、想跳槽但不知道从哪里复习的团队里负责出招聘题的甚至带新人的技术组长都能从这套题里提炼出“技术自测清单”。它不是让你背答案而是让你看看自己哪块还没打通。1.2 四个岗位的考察底层逻辑业务场景驱动技术选型我在拆这套题的时候最大的感受是B站出题人非常清楚自己的业务长什么样所以每个岗位的考察侧重点都很鲜明。前端方向视频站的核心场景是“页面加载快不快、滚动顺不顺、弹幕卡不卡”所以JS基础、浏览器渲染机制、网络请求优化、框架原理这几块是重头。它不会只问你“闭包是什么”而是会给你一段代码让你说出输出顺序顺便把事件循环、微任务宏任务、作用域链全串起来。后端方向B站的后端以Java为主核心场景是“弹幕怎么写、评论百万并发怎么扛、视频元信息怎么缓存”所以并发编程、JVM、MySQL索引与事务、Redis、消息队列是考察重点。题目问法通常很直接比如“线程池参数怎么定”“缓存穿透怎么解决”“一条SQL为什么慢”但你要答好得有业务体量感。运维方向B站当时已经有了比较成熟的持续集成和容器化体系所以考察点不光是Linux命令、shell脚本还包括发布流程、监控告警、日志收集以及初步的Docker和Kubernetes概念。最简单的信号是如果只是“会敲几个命令”这套题你多半撑不过一半。移动端方向B站App的用户量大、机型分散所以性能优化是绝对主角。列表卡顿、启动速度、网络弱网体验、内存占用、包体积这些是高频考点。同时因为B站大量页面是WebView/Hybrid方案所以移动端工程师往往还需要懂一点前端知识题目里也会穿插RN、Flutter这类跨端方案的对比。这四块内容放一起就是一张完整的技术地图。前端和移动端管“用户看到的部分”后端管“业务逻辑和数据”运维管“系统稳定和交付效率”。这套题的本质是通过笔试筛选出“对系统有整体认知、而不只是会写局部代码”的人。2. 前端与移动端性能优化为什么是重头戏2.1 前端高频考点的出题套路与解答思路前端这套题我估计很多人拿到手第一反应是“怎么这么多场景题”。闭包、防抖节流、Promise、浏览器缓存、跨域这些基础考点都会出现但出题人一般会给你一个视频网站的真实场景让你去解决实际问题。举个例子弹幕渲染。B站的弹幕是高频写入、实时显示一秒钟可能有几百条弹幕数据从WebSocket推过来。如果每来一条就操作一次DOM页面必然卡死。所以题目会考察你“怎么用虚拟列表”“怎么批量插入DOM”“怎么用requestAnimationFrame控制弹幕位移”。这背后考察的是你对浏览器渲染管线的理解JavaScript执行、样式计算、布局、绘制、合成每一步都可能成为瓶颈。再比如浏览器缓存这是面试必问题。你必须把强缓存和协商缓存讲清楚Cache-Control里的max-age、no-cache、no-store分别代表什么ETag和Last-Modified的区别什么场景下用强缓存、什么场景下必须协商。对应到B站场景里视频封面、用户头像这类静态资源适合强缓存而评论区这种动态数据就不能缓存或者只能做短时间的CDN缓存。还有一个高频题是跨域。B站页面域名和接口域名往往不一样开发环境还要连本地服务这时候CORS怎么配、JSONP的原理是什么、代理服务器怎么解决开发环境跨域都是实打实会遇到的。做题的时候不要只背名词要能画出一条完整请求从浏览器发出到服务端返回的链路每一步涉及什么机制。2.2 移动端容易被忽略的性能细节移动端方向B站当年已经有几千万DAUApp性能直接影响留存。所以笔试题里很爱从这几个角度出题列表卡顿如何优化、App启动时间如何缩短、弱网环境下请求怎么处理。列表卡顿的本质是主线程被阻塞。常见优化手段ViewHolder复用、图片异步加载、分页加载、避免在onBindViewHolder里做耗时操作。但题目如果只答这些大概率不够。你要进一步说出“为什么RecyclerView的复用机制能减少卡顿”——因为减少了findViewById和item布局的重复inflate还要会算“FPS掉到多少用户会明显感知”——一般认为低于30帧就会觉得卡。启动优化是另一个高频题。冷启动流程里Application的onCreate如果做了太多初始化启动时间就会变长。你可以用Startup库做初始化任务排序和异步加载用TraceView或systrace定位耗时方法把非必要的SDK初始化扔到子线程或者按需加载。这里有个关键认知启动时间不是越短越好而是“用户感知到的首帧时间”越短越好所以要区分冷启动、热启动、温启动三种状态分别优化。弱网优化也常考。B站用户很多在移动网络下看视频弱网时请求超时、图片加载失败是常态。考点包括请求超时时间分级设置失败重试策略指数退避图片先用占位图再渐进加载视频播放器做码率自适应把清晰度切换做成无缝衔接。这些点不只要答方案还要能解释每个方案的取舍比如指数退避为什么比固定重试更合理——因为固定重试会在服务端异常时加重雪崩。2.3 调试工具与线上问题定位能力笔试题里还会出现一类题表面问“你平时怎么调试”实际考验你的工程素养。前端这边Chrome DevTools的Performance面板怎么分析长任务、Network面板怎么看请求耗时、Sources面板怎么断点调试这些是基本功。移动端这边adb logcat怎么看日志Android Studio Profiler怎么查内存泄漏Charles怎么抓包看接口返回。这里有个特别值得说的点vConsole。B站移动端页面很多内嵌在App的WebView里不能用电脑DevTools调试所以vConsole这类移动端调试工具几乎是刚需。你可以通过自定义protocol或者url参数注入vConsole脚本在真机上直接查看Console输出、Network请求和本地存储。这个技巧在笔试里可能只占一个小题但实际工作中能帮你省下大量排查时间。另外别忘了线上问题的排查思路。前端是埋点监控比如Sentry接一下把JS error、资源加载失败、接口异常全部上报移动端是崩溃日志崩溃堆栈需要符号化还原ANR要抓取主线程堆栈。考试不会让你写完整代码但你得把“发现问题→定位问题→修复问题→验证修复”这个链路说清楚。3. 后端核心考点从并发编程到高并发系统设计3.1 Java后端必考的并发与JVMB站后端技术栈以Java为主所以笔试题里Java并发和JVM是绝对主力。并发部分最常考的就是线程池。题目可能给你一段代码问线程池核心线程数、最大线程数、队列容量分别设多少、任务怎么拒绝。你得知道ThreadPoolExecutor的七个参数还要明白为什么核心线程数不能拍脑袋定。这里给一个实际参考口径CPU密集型任务核心线程数设为CPU核数1IO密集型任务可以设到CPU核数*2甚至更高因为IO等待时线程可以切换执行其他任务。但真实场景还要看队列容量和拒绝策略如果任务量波动大队列不能太长否则大量任务排队会让响应延迟飙升如果系统允许丢弃非核心任务可以选DiscardPolicy否则用CallerRunsPolicy让提交线程自己执行起到天然限流效果。JVM部分高频考点是内存区域划分、垃圾回收算法、GC日志分析。你需要能画出堆内存里的新生代、老年代、元空间布局说清楚Minor GC和Full GC的区别还要知道怎么用jstat、jmap、jstack这些命令排查线上问题。面试题里如果问“线上CPU飙高怎么排查”标准回答链是top找到高CPU进程→top -Hp找到高CPU线程→printf %x转十六进制→jstack抓线程栈→定位到业务代码哪一行。以及常被拿来当压轴题的是一个接口请求量突增你怎么保证系统不被打挂。这题考察的是综合能力你既要说业务侧限流Guava RateLimiter令牌桶算法、又要点出缓存的重要性、还要提消息队列消峰。B站的评论区、弹幕、点赞这类场景都是典型的读多写少把热点数据缓存起来能挡掉绝大多数流量。3.2 缓存、消息队列与数据库的三角关系后端笔试题里“缓存穿透、缓存击穿、缓存雪崩”是出题人最爱的一组概念。很多人只背结论但真到了场景题就露馅了。我用大白话重新捋一遍缓存穿透查询一个不存在的key请求绕过了缓存直击数据库。高并发下如果一个不存在的ID被疯狂请求数据库压力会很大。解决方法是缓存空值并设置短过期时间或者用布隆过滤器先把不存在的key挡掉。缓存击穿一个热点key在缓存过期的瞬间大量请求同时打到数据库。解决方法是加互斥锁只让一个线程去查数据库并重建缓存其他线程等待后直接读缓存。缓存雪崩大量key在同一时间过期或者Redis挂掉导致请求全部打到数据库。解决方法是在过期时间上加随机值错开过期时间Redis高可用部署时还要考虑主从切换的瞬断。数据库这块B站的业务场景决定了索引设计很重要。视频详情页按vid查询、评论列表按视频ID分页、用户动态按时间倒序每一条都对应一个索引设计题。你需要知道联合索引的最左前缀原则知道为什么不要对索引列做函数运算会让索引失效知道覆盖索引能减少回表查询。慢SQL优化也是一道经典题先EXPLAIN看执行计划看type是不是ALL全表扫描看rows扫了多少行再看有没有走索引最后才是考虑要不要改SQL或者加索引。消息队列在B站后端也有大量应用比如弹幕写入、评论异步通知、视频转码任务。笔试题会考察为什么用消息队列而不直接同步调用解耦、异步、削峰消息丢失怎么处理生产者确认、消费者手动ack消息重复消费怎么办消费方要做幂等。幂等这块容易答泛你要结合业务说比如评论点赞的记录表加唯一索引、处理订单时用状态机判重。3.3 从“前后端分离项目实战”推导出题方向还有一个很有意思的视角B站笔试题里很多后端题其实是从“前后端分离项目实战”的痛点里提炼出来的。前后端分离之后后端要提供RESTful API、做鉴权、解决跨域每一点都是时经常考的方向。RESTful接口设计会考URL怎么命名、HTTP方法怎么选、状态码怎么用、分页参数怎么设计。B站视频列表接口按分区、按时间排序、按播放量排序本质就是对GET方法和查询参数的合理规划。如果面试官再深挖一层会问你为什么GET请求不能带body做查询条件——因为缓存、幂等、历史遗留的代理层面都有坑。鉴权方案也很常考。早期很多项目用SessionCookie后来改成Token。Token方案里JWT特别流行因为它无状态、天然适合分布式环境。但你得知道JWT的缺点签发之后无法主动失效所以退出登录要靠维护黑名单payload不是加密的不能放敏感信息。B站这类大流量的场景更常见的是用网关做统一鉴权token校验和用户信息透传都在网关层完成。这套题里如果出现“你怎么设计一个视频上传接口”这种开放题你要马上切换到实战视角。需要考虑的点包括大文件分片上传、断点续传、服务端合并校验、调用转码服务、异步返回上传结果。对应到代码层面就是MultipartFile接收文件、Redis记录分片状态、Golang或Java起协程/线程池做合并且发送消息到MQ。这种题没有唯一答案但要展示出系统的思考层次存储→处理→通知→容错。4. 运维岗位考察点从Linux命令到容器化集群4.1 Linux常用命令与网络排查思路运维方向的第一道门槛就是Linux操作但笔试题很少直接让你默写命令而是给你一个故障场景让你现场排查。比如“线上某台服务器CPU使用率100%你怎么查”或者“用户反馈接口偶尔超时你怎么定位”这类题。CPU排查链路建议写成top看进程top -Hp pid看线程strace -p pid看系统调用如果发现线程栈都在执行同一段代码就去查代码里是不是有死循环或者锁竞争。如果是Java应用还要配合jstack抓线程dump看BLOCKED状态的线程。这里最容易被忽略的一步是先确认是CPU高还是IO等待高top里wa列数值大说明是IO瓶颈这时候盲目查CPU是浪费时间。网络排查是运维笔试题的另一座大山。常见命令要知道ping查连通性telnet或nc查端口traceroute看路由路径ss和netstat看连接状态curl -v看HTTP请求细节tcpdump抓包分析。我见过太多人连ss -tunlp都记不全但真实排障里这条命令查端口占用几乎是日常最高频操作。如果要考深一点会给你一个“Nginx返回502”的场景。502是网关错误意味着上游服务没响应。排查顺序是先看Nginx错误日志确认upstream是连不上还是超时再telnet测上游服务端口通不通通了就进到上游服务看它的访问日志和错误日志确认是不是本身处理太慢或者已经被打挂。笔试答题时能按这个链路一步步说基本就过了。4.2 持续集成与自动化部署流程2019年的B站已经不再靠手动打包传服务器了所以笔试题对CI/CD有明确考察。你要理解一条完整流水线代码提交到Git仓库→触发构建编译、单元测试、打包→部署到测试环境→跑自动化测试→构建Docker镜像→推送到镜像仓库→发布到预发环境→灰度发布→全量发布。Jenkins和GitLab CI是考察重点。GitLab CI用.gitlab-ci.yml定义pipeline包含stages、job、script、artifacts这些关键字Jenkins则是用Pipeline语法或者BlueOcean界面拖拽配置。Shell脚本也是必考比如要求你写一段脚本批量检查多台服务器的端口存活状态或者根据日期滚动清理日志文件。写的时候要注意加上set -e避免中间命令失败还继续往下走导致误判。容器化这块Docker的基本概念是绕不开的。你要能说清楚镜像和容器的区别镜像是只读模板容器是运行实例镜像分层存储每一层都是只读的容器层负责写入。Dockerfile的编写也有讲究比如要把依赖安装放前面、代码复制放后面充分利用层缓存基础镜像尽量选Alpine这类精简版减少体积和安全漏洞。CI里构建镜像之后还要关注镜像仓库的tag管理不能用latest要用Git commit号或者版本号标记。4.3 容器编排与Kubernetes的调用链路如果题目再进阶一点就会从Docker问到Kubernetes。考点通常是Pod、Deployment、Service、Ingress这几个核心资源分别解决什么问题以及一次请求从外部进来是怎么被转发到Pod里的。我举个实际例子B站这类视频网站很多服务已经跑在Kubernetes集群里。外部请求先到Ingress Controller通常是Nginx或TraefikIngress根据域名和路径路由到对应的ServiceService通过Label Selector找到一组Pod再通过kube-proxy维护的iptables或IPVS规则做负载均衡最终把请求转发到某个Pod里的容器端口。更深入一层面试官会问你“Kubernetes里的kubelet是怎么调用容器运行时创建Pod的”。这里的关键点是我们常说的容器运行时通过CRIContainer Runtime Interface标准对接containerd是当前最主流的实现之一。从原理到实体调用大概是kubelet通过CRI调用containerd的grpc接口containerd再通过containerd-shim启动并管理容器进程shim进程再实际调用runc去创建和运行容器。这套链路里的每个组件各司其职kubelet负责Pod生命周期containerd负责镜像管理和容器运行时的上层封装runc负责利用Linux内核的namespace和cgroup隔离进程。问到这里时能画出这条调用链再标出每层的作用面试官基本就满意了。4.4 监控告警与日志处理运维笔试里还有个很容易被忽略但实际特别重要的部分监控和日志。B站的系统规模决定了不能等用户投诉了才去修必须依赖监控提前发现异常。基础题会问你CPU、内存、磁盘、网络这些基础监控用什么工具Prometheus node_exporter Grafana是目前的主流组合业务监控指标怎么设计QPS、成功率、响应时间P99告警怎么避免轰炸分组、分级、静默、聚合。日志这块大流量下不能直接上服务器翻日志文件所以要搭集中式日志平台。早期的方案是ELKElasticsearch Logstash Kibana现在更多是Filebeat采集、Kafka缓冲、Logstash清洗、ES存储、Kibana展示。笔试题如果问“线上接口报错你怎么从日志里快速找到相关请求”考察的就是你懂不懂traceId贯穿全链路。解决方式是网关生成traceId通过threadLocal和HTTP header传递到各个微服务日志统一打印traceId日志平台上按traceId搜索整条调用链路一目了然。5. 实战模拟这套题我会怎么做5.1 四岗位通用基础题模拟不管考哪个岗位有些基础题几乎是必出。我按当年的风格整理了几类并给出了我的答题思路。第一类是网络基础典型如“从输入URL到页面展示发生了什么”。这题考察全链路理解答题时可以分四段DNS解析拿到IP→TCP三次握手建立连接→HTTP请求发送与服务器处理→浏览器解析HTML构建DOM树并渲染页面。后面还能扩展CDN命中、缓存判断、渲染过程中的重排重绘这样答既有广度又有深度。第二类是操作系统基础如“进程和线程的区别”。单独答概念很容易啰嗦更好的方式是结合场景进程是资源分配的最小单位线程是CPU调度的最小单位进程间内存相互隔离、线程共享进程内存。再举一个B站相关例子播放器进程和UI主线程分离即使解码卡顿也不至于让用户操作无响应这就是多进程结构的实际意义。第三类是HTTP状态码。206断点续传是B站视频播放、分片下载的核心基础301/302重定向在防盗链和CDN调度时经常出现429限流在高并发保护里很常见503则说明服务暂时不可用。你要能把状态码和业务场景对上而不是死记硬背。5.2 前端与移动端笔试题模拟前端题目我会押两道一道手写防抖节流一道设计一个页面性能监控方案。手写防抖节流不只是背模板。防抖的核心是“只执行最后一次”设置定时器每次触发都重置只有停止触发一段时间后才执行。适用于搜索框输入联想、窗口resize场景。节流的核心是“固定频率执行”设定间隔间隔内只执行第一次适用于滚动加载、按钮提交限制。我给你一个节流的实现思路记录上一次执行时间每次触发时比较当前时间和上次时间差超过阈值才执行并更新时间戳。页面性能监控方案则是开放性题目。你要能想到Performance APIperformance.getEntriesByType(navigation)拿导航计时observer监听资源加载要主动采集FP、FCP、LCP、CLS这些Web Vitals指标要把数据上报到监控平台并支持按页面、运营商、机型维度聚合。答题时体现出“采集、上报、分析、告警”闭环就会比只背概念高一个段位。移动端我会押一道“卡顿优化”题。答题框架可以这样展开先定位卡顿场景列表滑动、页面切换、动画播放用Systrace或者CPU Profiler看主线程耗时再根据结果针对性优化。列表类项目复用ViewHolder、把图片加载放到子线程并做三级缓存页面切换类项目减少主线程复杂的布局计算动画播放类项目用setLayerType开启硬件层加速避免动画过程中每帧都重新走measure/layout/draw流程。最后加上一句“用卡顿监控工具在线上持续观察”表明你是系统思维而不是临时补窟窿。5.3 后端笔试题模拟后端我会押一道“设计一个接口支撑高并发点赞/评论”的场景题。解题框架大概是先用缓存扛读请求点赞数量、用户状态这类热点数据放到Redis里用Hash或者String加过期时间保存写请求不直接落库先发到消息队列削峰再由消费任务批量写入数据库为了保证数据一致性Redis里只存增量定期全量刷到DB为了防止重复点赞用SETNX加分布式锁或者用数据库唯一索引兜底。这套流程里要把每个组件的角色说清楚Redis是快路径、MQ是缓冲路径、DB是最终一致性路径。还有一道很常见的“如何排查一个接口突然从100ms变成5s”的问题。我的排查顺序是先看监控平台确认是从哪个时间点开始变慢再看关联的慢SQL用EXPLAIN分析是否索引失效如果没有SQL问题看是否缓存命中率骤降比如Key批量过期导致打到DB再看下游服务是否异常比如调用的用户服务超时最后确认是不是流量突增导致线程池排队。笔试答题时把“先看监控、再看DB、再看缓存、再看下游、最后看自身”五步说全基本分就拿到了。5.4 运维笔试题模拟运维题目我预测会有一道“线上服务器负载突然飙高你怎么办”。我的回答路径是先用uptime看load average再用top看CPU和内存占用top里按P按CPU排序、按M按内存排序如果发现是某个Java进程CPU高用jstack抓线程栈并定位到具体代码如果是磁盘IO压力大用iostat看%util和await排查是不是日志刷太频繁如果是网络问题用iftop或者nload看流量趋势。整个过程要遵循“先看现象、再缩小范围、最后定位根因”的思路避免一上来就重启服务器。还有一类题会写一段YAML让你分析Kubernetes部署问题。例如Deployment定义了replicas3但实际Pod只有2个你会怎么排查。参考答案先kubectl get deployment看期望状态kubectl get pods看实际状态再用kubectl describe pod xxx看事件里的失败原因常见原因包括镜像拉取失败、资源配额不足、健康检查失败被反复重启。答这类题的关键是要有“描述describe一定是第一排查手段”的意识。6. 笔试翻车重灾区常见问题与避坑经验6.1 为什么你明明背了很多题笔试还是挂结合我自己看简历、出题、筛人的经验笔试翻车最常见的原因有三个。第一个原因是只会背概念不会用场景串联。比如问“TCP三次握手”很多人能背出SYN、ACK的流程但一旦问“为什么连接是三次、断开是四次”就答不上来。事实上三次握手是为了让双方都确认自己的发送和接收能力没问题而四次挥手是因为TCP是全双工两个方向要分别关闭。你在准备时每背一个概念都问自己一句“这个在B站什么场景会出现”这样知识才是活的。第二个原因是代码题写得太慢或者中看不中用。前端手写防抖节流不是把能把setTimeout写对就行你要是没考虑this绑定、没传参数、没做立即执行选项面试官一眼就能看出你是背的。后端手写单例模式双检锁版本如果不加volatile关键字指令重排可能导致拿到半初始化对象这又是经典的扣分点。我的建议是考前至少把高频手写题每种敲三遍敲到肌肉记忆为止。第三个原因是开放题没有结构。一旦遇到“你怎么设计一个XX系统”很多人想到哪说到哪完全没有层次感。好的答法一定是从底层到上层、从数据到接入层逐步展开。比如设计评论系统先说存储模型评论表、回复表怎么设计索引怎么建再说读链路先Redis缓存列表、再DB兜底然后说写链路先校验、再写DB、再删缓存/Delay双删最后说风控敏感词过滤、用户限评。有结构考官才能顺藤摸瓜给你加分。6.2 一套试卷的“以题带学”训练法我建议拿到这套题之后不要只看答案就完事而是把每道题当成一个学习地图的入口。比如你看到“慢SQL优化”就往深处挖索引为什么能加速查询、B树和跳表的区别、联合索引为什么最左匹配、EXPLAIN里每个字段怎么读。一个入口能带出十几个知识点比零散刷题高效得多。我自己带人的时候喜欢让他们把错题按主题归类。前端一张纸、后端一张纸、运维一张纸、移动端一张纸。每归类一次就逼着自己写一遍知识框架把相关内容补全。比如移动端性能优化这张纸上写完列表优化之后必然会牵出图片加载框架Glide/Fresco、内存缓存策略、磁盘缓存策略、生命周期管理。最后这张纸就是一版Mini Wiki面试前只翻这几张纸就够了。6.3 关于“答案”的一个提醒这套卷子的很多题并没有标准答案。出题人更在意的是你的推导过程而不是最终结论。比如线程池核心线程数设多少你直接说一个数不如说“我先估算接口的平均响应时间和QPS再反推线程数同时预留缓冲”。再比如缓存和数据库的一致性方案用Cache Aside Pattern还是延时双删取决于业务对一致性的容忍度如果允许秒级延迟Cache Aside配合过期时间就够了没必要上更复杂的方案。所以我的建议是做题时强迫自己写出“为什么要这样设计”的注释就算只是给自己看。它会逼迫你把每个决策背后的权衡想明白。笔试考的不只是知识储备更是一个人在技术取舍上的成熟度。这恰恰是校招笔试里最想筛出来的东西。个人经验是这套题我每年都会拿出来翻一遍每次重看都会有新的体会初看是知识点密集的考卷后来变成查漏补缺的工具再后来成了给团队出题的参考模板。技术岗位的底子拼到最后比拼的还是基础是否扎实、以及能不能把基础知识用业务语言讲清楚。这套题里的每个考点都是通向那个目标的好台阶。