欢聚时代校招PHP笔试C卷解析：PHP 7、MySQL与Redis核心考点全覆盖

1. 先聊聊这份卷子的出题思路说说欢聚时代。当年这家公司在直播、游戏、社交赛道都铺得很开技术团队里PHP的占比非常高尤其是业务层几乎全是PHP的天下。所以校招笔试C卷能非常直观地反映出一线互联网公司对一个准PHP工程师的底层要求——不考花架子考的都是你天天写业务代码时会碰到的硬功夫。这份C卷的题型设置是典型的大厂校招风格先来一轮选择题快速筛基础再用简答题看你的原理理解深度接着是编程题验手上功夫最后用一道业务设计题看你的工程思维。整体题量不算夸张但覆盖面很广从语言语法、网络协议、数据结构到MySQL、Redis、Linux、系统设计都有涉及。如果你当时只抱着《PHP从入门到精通》啃基本会在选择题后半段就开始发懵反过来如果你平时写代码时愿意多问几个“为什么”这套卷子做起来会顺手得多。还要提醒一点2017年这个时间节点很关键。那会儿PHP 7刚大规模普及很多公司还在5.6到7.0的升级阵痛期所以卷子里专门安排了PHP 7新特性的考查。现在回头看这些考点依然没过时只是从“新特性”变成了“基础常识”。我按记忆整理了一份接近当年题量和风格的还原版每一题都补全了解析和答案下面按模块逐个拆。2. 选择题模块八道题筛掉基础不牢的人选择题是整套卷子的第一关卡考察点非常散但有明显的侧重。我把能回忆起来的考点做了个分类分布大概是下面这个样子考察方向大致题数核心知识点PHP语言基础3题输出函数区别、PHP 7新特性、数组遍历网络与协议2题HTTP状态码、TCP握手数据结构与算法2题排序复杂度、数组查找面向对象1题static/self/parent区别2.1 PHP语言基础echo、print、print_r、var_dump到底差在哪第一题基本就是送分题问你以下哪个语句不能用于输出字符串。选项里有echo、print、print_r和var_dump。很多人栽在print_r上因为日常调试习惯了print_r打印数组但题目问的是“输出字符串”print_r是专门用来打印人类可读信息的虽然也能输出字符串但语义上它不是纯输出语言结构。这里的核心考点是echo和print的区别。echo是语言结构可以一次输出多个参数不需要括号也没有返回值print也是语言结构但它只能接受一个参数而且总是返回1。print_r和var_dump是函数print_r输出格式更简洁var_dump会带上数据类型和长度信息适合调试。如果我是面试官我还会在下一轮追问一句“为什么echo比print快一点点”答案就是print有返回值多了一步赋值操作。2.2 PHP 7新特性那一年的必考热点C卷里有一道明确的PHP 7新特性题大概问法是以下哪个特性是PHP 7引入的。选项有标量类型声明、匿名类、太空船操作符、yield。四个选项看起来很接近但只有yield是PHP 5.5就有的其余三个才是PHP 7的新东西。这道题有意思的地方在于它不只考你知道不知道还考你用得熟不熟。标量类型声明在PHP 7里分强制模式和严格模式两种严格模式需要在文件头部写declare(strict_types1)不写的话默认走强制模式1会被转成1传入。太空船操作符是用于比较两个值的大小左边大返回1右边大返回-1相等返回0写排序逻辑时非常省事。匿名类是PHP 7引入的说白了就是一个没有类名的完整类定义可以new出来直接用。这几个特性到现在都是日常开发高频使用的属于必会内容。顺带说一个容易漏的点PHP 7里define()可以定义数组常量了这在PHP 5.6之前是不允许的。当年这道题有个干扰项就有人真的在define里传数组然后报错半天找不出原因。2.3 HTTP状态码301、302、304、503之间的爱恨情仇网络协议部分的考题很经典给一个场景让你选状态码用户请求了一个静态资源服务器告诉浏览器“你本地缓存的版本还能用”该返回哪个状态码。答案是304 Not Modified这个场景本质上是HTTP缓存协商机制。30x家族的区分是这里的高频考点。301是永久重定向浏览器和搜索引擎都会记住新地址302是临时重定向每次请求都还是会访问旧地址304不属于重定向它专门用来告知客户端可以使用本地缓存不返回body体。503是服务不可用一般出现在服务器过载或维护中和502 Bad Gateway网关收到无效响应要区分开。我在复习时总结过一个土办法从最终结果看301和302浏览器都会自动跳转区别只在于“是不是永久的”304页面看不到变化因为压根没下载新内容503页面能看到但一般是服务器的错误页。这套记忆方法当年帮我省了不少事。2.4 TCP三次握手为什么不是两次TCP相关题目在PHP笔试里出现频率极高因为PHP工程师迟早要跟网络协议打交道。C卷的考法是选择题形式TCP建立连接为什么需要三次握手。选项里有一个“确认双方收发能力”的答案这就是对的。三次握手本质上是四次信息交换客户端发SYN服务端回SYNACK客户端再回ACK。关键是第二次握手把服务端的SYN和ACK合并了所以变成三次。为什么不用两次因为两次握手只能确认客户端的发送能力和服务端的接收能力服务端发出去的SYN包得不到确认万一丢失服务端就会一直以为连接建立成功白白占用资源。生活化的理解就是两个人打电话A说“你能听到吗”B说“我能听到你能听到我吗”A说“我能听到”。只有这个“我能听到”确认完通信才算建立。2.5 排序复杂度快排和归并的区别数据结构题考了一道排序复杂度对比问的是平均时间复杂度为O(n log n)的稳定排序算法是哪个。选项里有快速排序和归并排序。快排的平均复杂度确实是O(n log n)但它不稳定归并排序同样是O(n log n)而且稳定。如果只是背答案这道题很容易丢分因为面试官后续追问一定会让你解释“稳定”是什么意思。稳定排序指的是相等元素的相对顺序在排序前后保持不变。举个业务场景先按时间排序再按用户ID排序如果排序算法不稳定第二次排序可能把第一次的时间顺序打乱。归并排序稳定在合并两个有序数组时遇到相等元素优先取左边的快速排序不稳定在分区交换时相等元素可能被换到另一边。3. 简答题模块从会用代码到懂原理的分水岭简答题是C卷拉开分数的关键环节。选择题还能靠刷题碰运气简答题真的就是平时积累的照妖镜。这个模块一共四道每一道都能写出一篇小作文但笔试时间有限要求的是你“用最短的话展现最深的功底”。3.1 一次PHP请求的完整生命周期这道题是PHP笔试的钉子户C卷里出现了我后来面试其他公司也遇到了。完整答案要从Nginx收到请求开始讲Nginx把请求转给PHP-FPMPHP-FPM的master进程调度一个worker进程来处理worker加载PHP解释器读取php.ini配置然后按顺序执行auto_prepend_file、框架入口文件、业务代码最后把响应返回给Nginx再由Nginx回传给浏览器最后执行shutdown函数并回收资源。核心考点在PHP-FPM的工作模式上。PHP-FPM是FastCGI的进程管理器master只负责监听端口和管理worker不参与具体业务。每个worker处理完一个请求后不会退出而是复用进程继续处理下一个请求这就是常驻进程模式省去了频繁创建销毁进程的开销。但PHP本身是单线程的一个worker同一时刻只能处理一个请求所以worker数量决定了并发处理能力。这里我建议答题时补一句“worker进程数一般设置为CPU核心数的1-2倍配多了反而会因为上下文切换导致性能下降”这是面试官很爱听的工程经验。还有一个隐藏分点PHP每次请求结束会把所有变量销毁这就是PHP“共享什么都不方便”的根源。你要在答题里点出“PHP的变量生命周期只在单次请求内”才能证明你理解为什么Session要落到Redis、为什么全局变量不能跨请求保留。3.2 Session跨域共享的三种主流方案这道题的切入场景是公司有多个子域名用户在A站点登录后B站点需要同步登录状态。最直接的方案是把Session存在Cookie里把Cookie的domain设置成顶级域名比如“.example.com”这样所有子域名都能读到同一个Cookie。这个方案实现简单但Cookie有4KB大小限制Session数据一旦膨胀就装不下而且所有数据暴露在客户端安全隐患明显。第二种方案是把Session存到Redis里。客户端还是持有session_id但session_id对应的数据统一存在Redis集群中。用户访问哪个子域名服务端只要拿着session_id去Redis里查就行。这样Session数据不落磁盘读取速度快还天然支持水平扩展。缺点是引入了一个新组件Redis万一挂掉会影响所有登录用户所以实际部署要用主从加哨兵。第三种方案是放弃原生Session改用Token机制也就是现在最主流的JWT。服务端签发一个包含用户身份信息和过期时间的签名Token客户端每次请求带上服务端验签通过就认你这个用户。Token天然支持跨域因为主动权完全在客户端但也正因如此Token一旦泄露就相当于把用户身份给了别人所以必须设置合理过期时间并且一定要用HTTPS传输。我当年答题时把三种方案都写了面试官最后点评说“能对比着写还给每个方案都点出缺陷的基本就是真写过多端登录的”。3.3 MySQL慢查询排查的完整思路后端笔试几乎必考MySQL优化C卷这题的问法是“线上接口突然变慢你怎么排查”。标准的排查链路是先开慢查询日志定位问题SQL再用EXPLAIN分析执行计划然后针对索引做优化。慢查询日志默认是关闭的临时开启可以用set global slow_query_logON配合long_query_time设置阈值一般线上设为1秒比较合理。EXPLAIN出来以后重点看几个字段。type列是访问类型的体检指标从好到差依次是system、const、eq_ref、ref、range、index、ALL看到ALL就是全表扫描属于必须优化的对象。key列表示实际用到的索引rows列是预估扫描行数这两个数字差距太大说明索引选择有问题。还有一个容易忽略的字段是Extra如果出现Using filesort或者Using temporary意味着排序和去重没有走索引要检查ORDER BY和GROUP BY的字段是否在联合索引里。索引优化的核心原则是“最左前缀”。联合索引(a, b, c)在查询时只有遵循a、ab、abc的顺序才能命中直接查b或者c是走不了这个索引的。我踩过一个很经典的坑表里建了(uid, create_time)联合索引但查询条件是create_time BETWEEN xx AND xx索引直接失效排查半天才意识到少查了uid。后来我在设计索引前都会先列出业务的所有查询模式再倒推索引组合。3.4 Redis五种数据类型怎么选型这道简答题考核的是Redis的熟练度C卷的晋级版会加上“结合业务场景说说你的选择”。五种类型里String是最通用的适合做缓存、计数器、分布式锁底层是SDS动态字符串支持INCR/DECR原子操作。Hash适合存对象比如用户信息字段多但每次只需要读写其中几个时比整个序列化成String再反序列化高效得多。List适合做简单的消息队列和时间线LPUSHBRPOP组合可以实现可靠消费但BRPOP会阻塞连接生产环境要设置超时时间。Set适合做去重和集合运算点赞、关注关系、共同好友都用它。ZSet比Set多了score排序排行榜、延迟队列、滑动窗口限流都是典型场景。我印象里这道题的高分答卷都会举自己的真实业务例子比如“我们直播间的热门礼物排行用的就是ZSetscore存礼物价值member存主播ID实时Top100就是一条ZREVRANGE的事”。4. 编程题模块手写代码暴露真实水平笔试的编程题环节没有任何IDE提示纯手写纸面代码。C卷一共三道题难度从一颗星到三颗星递增。代码不要求能直接跑通但逻辑要清晰边界条件要覆盖完整函数命名要规范。这个环节最能看出平时写码习惯。4.1 找出数组中出现次数超过一半的数字这道题是算法界的经典题很多公司校招都在用。题目描述很简单给定一个数组其中某个数字出现次数超过数组长度的一半找出这个数字。常规思路是排序后取中间值时间复杂度O(n log n)但最优解法是摩尔投票法时间复杂度O(n)空间复杂度O(1)。摩尔投票法的核心思想是“同归于尽”不同数字两两抵消最后剩下的就是候选众数。具体做法是维护一个候选值和一个计数器遍历数组计数器为0时把当前元素设为候选值并计数为1后续元素与候选值相同则计数加1不同则计数减1。因为目标数字出现次数超过一半所以抵消到最后一定能剩下目标。function majorityElement(array $nums) { $candidate null; $count 0; foreach ($nums as $num) { if ($count 0) { $candidate $num; $count 1; } elseif ($num $candidate) { $count; } else { $count--; } } return $candidate; }这里有一个隐藏考点摩尔投票法得到的候选值不一定是真正的众数它只是“最有可能是众数”的那个。如果题目没有保证一定存在众数拿到候选人之后还需要再遍历一次数组确认它的出现次数确实超过一半。C卷这道题给了“一定存在”的前提条件所以不用二次校验但我建议答题时主动提一句“如果题目没保证需要加一次O(n)的验证”这是加分项。4.2 手写一个LRU缓存类LRULeast Recently Used缓存在面试中出现频率极高因为它能同时考察数据结构和工程思维。核心要求是get和put操作的平均时间复杂度都是O(1)。经典的实现是哈希表加双向链表哈希表保证O(1)找到节点双向链表保证O(1)删除和移动节点。在PHP里有个取巧但完全合理的做法利用PHP数组本身是有序哈希表这个特性来实现。PHP的数组底层是HashTable加双向链表天然保持了插入顺序所以可以直接用数组模拟LRU的访问顺序class LRUCache { private $capacity 0; private $map []; public function __construct(int $capacity) { $this-capacity $capacity; } public function get($key) { if (!array_key_exists($key, $this-map)) { return -1; } $value $this-map[$key]; unset($this-map[$key]); $this-map[$key] $value; return $value; } public function put($key, $value) { if (array_key_exists($key, $this-map)) { unset($this-map[$key]); } elseif (count($this-map) $this-capacity) { array_shift($this-map); } $this-map[$key] $value; } }这里的原理是每次get或put都把对应key先unset再重新赋值这样这个key就移动到了数组末尾数组头部永远是最久未访问的key。溢出时array_shift弹出头部元素即可。顺手体现PHP数组底层功底的写法比硬套双向链表的版本更贴合PHP工程师的身份。4.3 字符串反转函数与中文兼容这道题考的是基础API的边界处理。题目让你实现一个字符串反转函数如果是纯英文字符串strrev直接搞定。但面试官故意会把字符串里塞进中文这时候strrev就会把中文按字节反转输出乱码。原因在于PHP的strrev是按字节操作的而UTF-8编码的中文一个字符占3个字节逐字节反转自然会把UTF-8字符的编码顺序打乱。正确的做法是先按字符切分再反转合并。PHP 7.4以下没有mb_str_split函数可以用正则配合u修饰符按UTF-8字符切分function mbStrRev(string $str): string { preg_match_all(/./us, $str, $matches); if (empty($matches[0])) { return ; } return implode(, array_reverse($matches[0])); } // 测试 echo mbStrRev(Hello PHP 你好); // 输出好你 PHP olleH正则里的u修饰符是核心它让模式以UTF-8模式匹配.就能匹配一个完整的多字节字符。这个题目告诉我一个道理写PHP函数前一定要想清楚编码问题尤其是涉及字符串截取、反转、长度计算的场景array_slice、substr这类函数对中文都不友好。我在实际项目中封装字符串工具类凡是可能处理中文的方法一律从写第一行代码就按多字节处理走后面省了无数排查乱码的精力。5. 数据库与系统设计题直播间送礼日志表怎么设计最后一道大题是典型的业务设计题场景直接用了欢聚时代自家的业务设计一个直播间的送礼日志表需要支持按用户查询历史送礼记录、按直播间查询礼物流水、后台运营按时间维度对账。这道题考查的不仅是你会不会建表更是你会不会根据业务选型方案。5.1 表结构设计的核心字段与索引先给一份最基础的核心表结构CREATE TABLE gift_log ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, room_id INT UNSIGNED NOT NULL COMMENT 直播间ID, user_id INT UNSIGNED NOT NULL COMMENT 送礼用户ID, anchor_id INT UNSIGNED NOT NULL COMMENT 主播ID, gift_id INT UNSIGNED NOT NULL COMMENT 礼物ID, gift_num INT UNSIGNED NOT NULL DEFAULT 1 COMMENT 礼物数量, total_price DECIMAL(10, 2) NOT NULL COMMENT 礼物总价值, create_time DATETIME NOT NULL COMMENT 送礼时间, KEY idx_user_time (user_id, create_time), KEY idx_room_time (room_id, create_time), KEY idx_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意几个细节。一是所有金额字段用DECIMAL而不是FLOATFLOAT有精度丢失问题涉及钱一定要用定点数。二是字符集用utf8mb4不用utf8因为utf8在MySQL里最多存3字节存不了emoji表情而直播间用户昵称、礼物名称里经常出现emoji。三是create_time用DATETIME还是TIMESTAMP2017年这个时间点DATETIME的默认值处理很麻烦但DATETIME范围更大也不会受时区影响导致数据错乱我倾向于DATETIME。索引设计是这道题的核心。按用户查历史记录建议(uid, create_time)联合索引因为查询条件是uid时间范围按直播间查流水用(room_id, create_time)联合索引。这里要特别注意如果业务经常是“查某个用户最近30天的送礼记录”联合索引(uid, create_time)可以让时间排序直接在索引内完成避免Using filesort。要是只给uid建了单列索引MySQL需要先按uid查出全部记录再排序数据量大时性能差距非常明显。5.2 高并发写入与分表策略直播间送礼的写入量很大尤其是大型活动期间。单表存储必然扛不住笔试里要答出分表方案。分表策略有两种主流方案各有适应场景。按时间分表比如每季度一张表逻辑是create_time在前缀。优点是实现简单查询时间范围时直接定位到对应表缺点是单表数据量还是可能很大而且某个时间段的数据会集中写入同一张表容易形成写入热点。按room_id做哈希分表比如分成64张表tbl_gift_log_0到tbl_gift_log_63写入时通过CRC32(room_id) % 64确定表名。优点是写入均匀分散到多张表支持按直播间查询是直接路由到对应表缺点是按用户查历史记录时请求会广播到所有分表再合并查起来麻烦。实际业务中通常两种方案结合先按room_id哈希分表再配合时间维度做冷热数据分离近期数据放热表历史数据归档到冷表。答题时建议补充一个方案用消息队列异步写入。送礼这个动作对实时性要求不高客户端发送成功后先把数据投递到消息队列消费者批量写入数据库。这样能把高并发写入削峰填谷数据库压力瞬间降下来。当年欢聚的直播业务里这种模式已经比较成熟了。这道题的完整高分答案应该包含建表SQL、索引设计理由、分表策略对比、最终选型的权衡说明。光写“分表”两个字拿不到分把取舍逻辑写清楚才是面试官想看到的工程思维。6. 当年答题的坑与复盘建议写到这里我对这套题目的还原和分析基本告一段落。最后想分享一些当年实际笔试时的经验以及在辅导新人准备这类笔试时反复强调的几个点。时间分配上选择题要控制在15分钟内不会的先标跳过不要恋战。简答题每道控制在10分钟先写结论再补细节避免写得过长影响后面编程题的时间。编程题留40分钟先花3分钟想清楚思路再动笔一定要把边界条件写上比如空数组、只有一个元素、负数等。最后那道设计题至少要留20分钟这类题没有标准答案考察的是你的思考完整性多写一个索引、多写一个容灾方案都是加分项。我当年踩过的最大的坑是简答题写得太贪心。以为自己懂得多每道简答都恨不得写成小论文结果最后编程题只剩20分钟代码写得潦草边界条件没覆盖被扣了不少分。后来我总结出一个经验简答题是“列点得分”不是“字数得分”。每个点用一两句话讲清楚技术名词准确就够了写多了面试官反而抓不住你的重点。还有一个很实用的复习建议刷题不要只刷PHP题要配套刷计算机网络、MySQL、Redis的基础题。欢聚时代C卷这类大厂PHP笔试题的特色就是“以PHP为入口考整个计算机基础”。只准备PHP语言本身等于带着一把钥匙去开十扇门。另外如果今天是你在准备类似的笔试我再多送你一个建议——工具链要提前搭好。PHP 7的语法特性、PSR标准、Composer用法、PDO预处理、设计模式的常见写法这些都是大厂笔试的高频考点。把这些平时写业务时“用过但没总结过”的东西沉淀成自己的知识体系比你考前突击刷一百道题管用得多。这套卷子说到底考的不是记忆力而是你写代码这几年到底积累了多少真东西。技术这一行来不得半点虚的。