1. 第三批笔试的整体印象：网申通过后的第一盆冷水
收到阿里云2025年春招研发岗第三批笔试通知时，我正在出租屋里刷着LeetCode题单。说实话，能走到笔试这一步心里挺高兴的，毕竟阿里云研发岗的简历关出了名的难通过。但真正点开赛码网的笔试链接，看到考卷的那一刻，我才意识到自己之前的准备方向有一半都是偏的——这套卷子不是单纯考算法，而是把“工程基本功”和“云产品理解”揉在一起考，满分150分，算法只占其中一小部分。
1.1 从网申到笔试：流程上需要注意的几个点
第三批笔试的邮件一般会提前三天左右发到邮箱，同时短信跟上。邮件里会写清楚考试时间、赛码网考试链接、设备要求和注意事项。这里我踩了一个小坑：邮件里的链接直接点进去，选手机会跳动到一个“等待开考”的页面，看起来啥也没有，其实这是在下载监控插件。如果你用的是公司电脑或者极度受限的网络环境，插件可能装不上，建议提前半小时进场把环境搞定，不要等到开考时间才开始折腾。
笔试时间是120分钟，题量不算特别夸张，但想从容答完并不容易。开考前需要在赛码网页面完成人脸识别验证，系统会随机拍照并开启摄像头监控，切屏超过三次会记录异常，严重的话可能被判作弊。我建议考试前把手机放到远处、聊天软件全部退出，浏览器只保留一个标签页。
1.2 试卷结构：三种题型各考什么
这一批笔试的题型可以分成三大块：单选多选混合的选择题、两道算法编程题、以及两三道简答/设计题。选择题大概占了40分，编程题50分左右，简答设计题60分左右。也就是说，编程题并不是绝对的大头，简答题的权重反而很高，很多同学容易忽略这一点。
选择题覆盖范围比较广，包括数据结构、操作系统、网络、数据库、Linux命令、Java/C++语言基础，以及阿里云产品相关的题目。印象比较深的是有两道题涉及RAM访问控制和OSS权限配置，如果没有实际用过阿里云，看到这种题会有点懵。编程题是标准的ACM风格，用牛客或力扣的方式输入输出，题目难度中等偏上，一道是拓扑排序变种，一道是大数据TopK问题。简答题则是给一个真实的工程场景，让你设计架构或排查问题，比如“线上服务偶发超时，你怎么排查”或者“如何设计一个短链服务”。
1.3 这场笔试和一般互联网大厂笔试的区别
我秋招的时候也参加过几家头部互联网公司的笔试，大部分是纯算法题+选择题，考察的面相对窄一些。阿里云这次笔试最大的区别在于：它把阿里云的产品和技术栈直接嵌入到考题里，默认你具备一定的云原生开发经验。比如选择题里出现“STS临时凭证的有效期最长可配置为多少”“CDN回源失败可能的原因”这种问题，没碰过云产品的同学只能靠蒙。
所以我后来复盘时得出一个结论：准备阿里云研发岗笔试，光刷算法题是不够的，必须把阿里云核心产品（ECS、OSS、CDN、RAM、云效Codeup、消息队列等）的基本原理和使用姿势过一遍，至少要知道这些产品是干什么的、底层用到了哪些基础技术、常见问题有哪些排查思路。下面我按题型和考点逐块拆解，把还能回忆起来的题目和解题思路写下来。
2. 题型拆解：哪些题在筛选基础，哪些题在筛选工程能力
2.1 选择题：基础知识覆盖面很广，但很“实在”
选择题一共大概二十道，考察内容大致可以分成计算机基础和云产品知识两类。计算机基础部分出现的高频考点包括：进程与线程的区别、死锁的四个必要条件、TCP三次握手与四次挥手、HTTP状态码含义、B+树与哈希索引的区别、事务的ACID特性、MySQL隔离级别、Java的HashMap原理和并发容器、C++的智能指针、Linux常用命令等。这些题目本身不难，但因为覆盖面太广，如果平时某个方向长期没碰，很容易卡壳。
我印象里有一道题是这样的：某Linux进程的CPU使用率很高，用哪个命令可以快速定位到对应线程？A.top -H，B.ps -ef，C.free -m，D.netstat -an。答案是A。这道题看似简单，但很多同学平时只见过top，不知道有-H参数可以显示线程级负载。类似的细节题还有很多，比如“查看某个端口是否被占用”应该用ss -lntp或netstat -lntp，而不是ps。
云产品部分的选择题更有业务色彩。有一道题问：RAM用户是否可以同时拥有多个权限策略？答案是肯定的，一个RAM用户可以被加入多个用户组，也可以直接附加多个自定义策略。还有一道题考了对象存储OSS的存储类型，问低频访问型（Infrequent Access）适合什么场景，答案是“访问频率低但数据需要实时读取”。这类题只要用过产品基本都能答对，但没用过的话，选项之间的细微差别很难判断。
2.2 编程题：两道题都不算偏门，但很考验思路
第一道编程题是“课程表”的变体：给定课程数量n和依赖关系列表 prerequisites，要求判断是否可以完成所有课程。这题核心就是拓扑排序+环检测，可以用Kahn算法或者DFS染色两种方式实现。我个人更推荐Kahn算法，因为它写起来不容易出错，而且天然适合处理“入度为0”的点作为起点。写完记得处理极端情况，比如n=0、prerequisites为空数组。
第二道题是经典的大数据场景：“给定一个非常大的日志文件，每行是一条用户访问记录，找出访问次数最多的前K个IP。”如果内存足够，直接HashMap计数后排序就能做，但题目暗示文件非常大，不能一次性读入内存。稳妥的做法是哈希分片+小顶堆：先把大文件按IP哈希分到多个小文件里，对每个小文件单独统计IP次数，再用大小为K的小顶堆求全局TopK。这题考察的其实不是某个冷门算法，而是“面对海量数据如何用有限资源解决问题”的工程思维。
我在这里有一个不小的教训：写第一道拓扑排序时，我习惯性地用邻接矩阵存图，结果数据范围n可以到10^5，直接内存越界又超时。正确的做法是用邻接表ArrayList []或者List<List >。所以笔试前一定要养成看数据范围的习惯，邻接矩阵只适用于点数几百以内的情况。
2.3 简答/设计题：真正拉分的地方在这里
简答设计题一共三道，每题大概20分。我回忆到的题目方向：一是“线上服务偶发超时，请给出排查思路”；二是“如果让你在阿里云上设计一个支持高并发的短链服务，你会怎么设计”；三是“为什么说重启能解决很多线上问题，谈谈你的理解”。
第一道题，我总结的排查思路是：先确认是单机问题还是集群问题，再看网络链路（SLB、安全组、带宽）、应用层（线程池是否打满、GC是否频繁）、数据库层（慢查询、连接池满）、依赖服务（下游接口变慢）。答题时最好按照“现象→定位→根因→解决方案”的逻辑展开，并且把顺手能用的工具写出来，比如top、jstack、arthas、慢日志查询等。这种题没有标准答案，但考察的是你遇到生产故障时的第一反应和排查习惯。
第二道短链服务的设计题，核心点在于：发号器如何生成唯一短码、短码与原始URL如何存储、跳转时如何做302/301重定向、如何支撑高并发读。当时我画了一个简单的结构：发号器用Redis自增或雪花算法生成ID，再通过Base62编码成短码；存储层用Redis缓存热点映射，MySQL做持久化；跳转请求先查缓存，未命中再查数据库并回填。如果面试官想看细节，还会追问“短码过期怎么处理”“如何统计点击量”，这其实对应了阿里云上消息队列加离线分析的使用场景。
第三道题很多人会觉得是送分题，其实考的是运维功底。重启能解决的问题大多是“不可恢复的状态异常”，比如内存泄漏导致OOM前兆、线程死锁、连接池耗尽、句柄泄漏。如果连根因都没定位就盲目重启，问题很快会复现。答题时我侧重说了“重启只是应急手段，必须配合监控和日志把根因找出来”。
3. 技术考点深挖：阿里云自己的产品就是天然题库
3.1 RAM访问控制：身份管理与临时凭证，笔试比想象中爱考
这次笔试里有好几道题都和RAM有关，这不算偶然。RAM是阿里云IAM体系的基石，研发岗日常操作库表、操作OSS、操作K8s集群，全都是通过RAM来做鉴权的。如果你不清楚RAM用户、RAM角色、权限策略、STS临时凭证之间的关系，做云上开发会寸步难行。
简单梳理一下RAM的底层逻辑：根账号拥有资源全部权限，但日常使用应当创建RAM用户并分配最小权限。权限策略（Policy）本质上是一段JSON，里面定义了Action、Resource和Effect。Effect有Allow和Deny两种，当策略合并评估时，显式Deny的优先级高于任何Allow。这一点笔试里直接出了一道题：某个RAM用户附加了“AliyunOSSFullAccess”系统策略，同时Bucket Policy里显式Deny了该用户对某个Object的GetObject操作，最终该用户能否读取这个Object？答案是不能，因为Deny优先。
另外，STS临时凭证的机制也很重要。长期AccessKey泄露风险高，正确的做法是通过STS的AssumeRole接口换取临时凭证，临时凭证里包含的SecurityToken有效期可以配置，范围为900秒到3600秒（默认3600秒）。我在笔试时遇到一道判断题问“STS临时凭证的有效期可以配置为7天吗”，正确答案是：不能再高，上限就是3600秒。这个细节如果你没实际看过官方文档，很容易凭感觉答错。
3.2 OSS与CDN：存储分发链路中的高频坑
OSS这块，我认为最值得关注的知识点是权限与数据一致性。选择题里有一道是说“如何让私有空间的某个文件临时授权给外部用户下载”，正确方案是用OSS签名URL，而不是修改Bucket ACL。签名URL把AccessKey和有效时间绑定到一个链接上，外部用户拿到链接后可以在一段时间内下载，不需要暴露密钥。这个方案的底层原理是HMAC签名，与STS配合时可以对下载行为做更细粒度的控制。
CDN相关的题则偏重架构理解。有一道是一段SPA单页应用部署到CDN后，用户在浏览器直接刷新 /user/123 这个地址变成404，问原因和解决方案。这其实是很经典的CDN SPA fallback配置问题：CDN节点没有 /user/123 这个目录，回源时源站也没有对应路由，所以返回404。解决方案是在CDN的“回源配置”里设置自定义404页面为 index.html，或者在控制台开启“单页应用回退”，让所有路径都回源到入口文件。这个细节在阿里云CDN控制台里有现成配置项，但很多开发同学没有接触过，笔试时只能干瞪眼。
另外，CDN的回源HOST配置也值得提一下。如果你配置了CDN加速域名，但回源HOST填错了，会导致回源时源站收到的Host头不对，后端Nginx可能返回404或者错误证书。这类问题在真实业务里非常常见，笔试虽然没有直接考，但简答题“CDN命中率低如何排查”就和它有关。
3.3 代码托管与DevOps：云效Codeup + Git工作流
热搜词里出现“vscode + 阿里云codeup + git”，说明很多人关注阿里云自研的代码托管平台。事实上，阿里云研发岗日常开发基本都在云效Codeup上完成，笔试不给定性考这题，但问了一些Git高危操作的正确姿势。比如“不小心把密钥文件提交到Git仓库了怎么办”，这题其实考的是：先用git rm --cached把文件从版本库移出并更新.gitignore，然后必须改写历史（filter-branch或者BFG）把那个文件从提交历史里剔除，最后还要提醒相关人等立即轮换密钥。
从我的经验看，把Codeup和本地VSCode协同使用，主要走这么几步：先在云效Codeup创建一个代码库，拿到Git地址，本地clone之后创建自己的feature分支，开发完提交并创建Merge Request，在Codeup页面上做代码评审和CI检查，通过后合入主干。Codeup的MR页面支持直接查看代码差异、发表评论、自动触发流水线，这个工作流和GitHub/GitLab基本一致，但因为是阿里云生态，权限体系天然与RAM账号打通，所以登录时用的是阿里云RAM账号而不是单独注册一个账号。
如果你准备阿里云笔试，建议至少把“Git分支管理”“MR流程”“回滚历史提交”这三个操作在本地亲手做一遍。笔试中即便不考具体命令，选择题里也很有可能考到“git revert和git reset的区别”“如何撤销已经push的提交”这类问题。
3.4 镜像站与开发者生态：为什么笔试里会问源配置
笔试里有一道选择题问“Maven项目下载依赖很慢，应该怎么优化”，选项中有一个是“在settings.xml里配置阿里云公共仓库镜像”。如果你只是背过答案，可能不知道背后的原因：Maven中央仓库默认在国外，国内网络访问延迟和失败率都很高。阿里云镜像站（maven.aliyun.com/repository/public）会把中央仓库的内容同步到国内节点，配置后依赖下载速度能提升一个量级。
和它类似的还有Linux系统源配置。我秋招时自己配过CentOS 7的yum源，把默认的repo文件指向mirrors.aliyun.com，再清缓存重试，安装软件秒下。笔试虽然不会让你现场敲命令，但会以“如何给CentOS换源”这种简答题形式出现。你至少要能说出：备份原repo文件、下载或修改为阿里云base源和epel源、执行yum clean all和yum makecache。如果连这些都不知道，说明日常开发的系统维护经验不足。
这些题目放在一起看，逻辑很清晰：阿里云笔试不是想招一个纯粹的LeetCode选手，而是希望招一个能直接在云上干活的研发。会用镜像站、会配yum源、会看RAM权限、会部署OSS和CDN，这些“基本功”在笔试中占的分量远比想象中高。
4. 配置类实操题的真实面貌：会答和拿分是两回事
4.1 Maven仓库镜像配置：从settings.xml开始
选择题里有一道关于Maven镜像的问题，但简答题也没有完全放过这一块。我的回忆是有一道“如何把Maven依赖下载切换到阿里云镜像”的简述题。答题时我写了标准的三步：在Maven的conf/settings.xml（或用户级~/.m2/settings.xml）的 节点下添加阿里云公共仓库镜像；检查 中的ID至少有一个为central；然后执行mvn clean compile验证依赖是否能正常下载。
一个容易忽略的细节是：settings.xml的 写法中，<mirrorOf>的值一定要写成central或*。如果只写一个别名，可能导致部分依赖还是从中央仓库下载。下面是我实际用的一份配置片段，可以直接参考：
<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>笔试虽然不会考这么细的XML字段，但理解这个配置能帮你在选择题里快速排除错误项。另外，除了Maven，镜像站还覆盖了npm、PyPI、Docker Hub等，思路都是一样的：把国外源换成国内同步节点，解决访问延迟。
4.2 Linux软件源替换：CentOS和Ubuntu的差异
运维向的选择题考过“CentOS 7.9默认yum源访问缓慢，如何切换到阿里云镜像”，我在试卷里写了两个关键命令：替换Base源和epel源，然后清理缓存。
实际操作时，我一般会先备份原始repo文件：
mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo curl -o /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-7.repo yum clean all && yum makecache如果是Ubuntu 22.04，则要把/etc/apt/sources.list里的archive.ubuntu.com替换为mirrors.aliyun.com，然后执行apt update。这里有个坑：Ubuntu的源文件可能是.list或.list.d格式，新版Ubuntu还引入了sources.list.d目录，修改时要先看清楚自己系统的版本。笔试里用CentOS出题的概率更高，但你在个人学习时最好把两种都折腾一遍，才不容易混淆。
4.3 SSL证书免费续期与部署：看似简单，细节不少
笔试选择题里出现过“SSL证书快到期如何处理”的讨论，题干是“阿里云免费SSL证书有效期是多久、如何续期”。这道题的答案是：免费证书有效期目前是3个月，到期前需要重新申请并部署，不能直接续费同一张证书。
真实操作中，我建议盯紧证书有效期。可以在云监控里配置到期提醒，或者提前一个月重新申请证书，再在Nginx里替换证书文件并reload：
# 把新证书放到指定目录后，检查配置再重载 nginx -t nginx -s reload一个常见的坑是：很多人以为替换证书后浏览器会自动生效，实际上如果使用了CDN，则源站和CDN节点都需要更新证书，甚至要等CDN缓存过期。笔试中问“证书部署后仍然告警不安全”，可以从证书链不完整、CDN节点缓存旧证书、部署的域名和证书不匹配三个方向排查。把这些写进答题里，会比只写一句“重新部署”拿分多。
5. 错题回忆与复盘：笔试里丢分最多的几个地方
5.1 RAM权限判断题：显式Deny优先，别被“拥有FullAccess”带偏
错题复盘是我最喜欢的环节。先说一道我纠结了很久的题：RAM用户A被授予了“AliyunOSSFullAccess”，同时某个Bucket的Bucket Policy中显式Deny了A的GetObject操作，问A是否可以读取该Bucket下的Object。我一开始想，“FullAccess”可是所有权限，Deny应该被覆盖才对，结果错了。正确答案是拒绝，因为阿里云的权限判断逻辑会先合并所有策略，然后检查是否存在显式Deny，只要有显式Deny，直接拒绝，无论Allow的权限范围多大。
这个知识点对做云上开发的工程师来说非常关键。生产环境中，安全团队经常会用Deny策略做“熔断”，强制限制某个高危操作，比如禁止删除生产环境重要Bucket、禁止在特定地域创建ECS实例。就算运维人员本地配置了Allow类权限，也不能突破Deny限制。笔试里的这道题其实是在提醒我们：理解云上权限模型不能只看“授权”，还得看“拒绝”的优先级。
5.2 网络基础题：TCP和UDP在真实业务里的选择，别再靠蒙
有一道选择题是“视频直播场景优先选择TCP还是UDP”，选项里还包括“QUIC”。我当时选了TCP，理由是直播要可靠传输，但实际上直播更看重低延迟，UDP可以容忍一定丢包，配合FEC前向纠错能获得更好的体验。而现代音视频服务里，很多已经升级到基于UDP的QUIC协议，所以答案是UDP或QUIC，而不是TCP。
这种题单独看是送分题，但在“阿里云笔试”的语境下，它暗示的是云上产品选型逻辑：ECS、OSS、CDN、直播服务，不同产品面对的网络需求不同，采用的传输层方案也不同。如果你把云产品里面的“低延时直播”和QUIC加速搞清楚，再回头做这道题就很容易。笔试结束后我把阿里云官方文档里关于CDN QUIC加速、RTS低延时直播的部分翻了一遍，才知道当时选错的原因。
5.3 第二道编程题的时间复杂度：优化思路写出来也有分
编程题如果完全AC不了，把自己的优化思路写在注释里，其实有可能拿到部分分。这次第二道TopK题，我只写了哈希分片思路的伪代码，核心的小顶堆实现没有完全跑通，但我在注释里写了“先分片统计再局部TopK再全局TopK”的流程。交卷后回忆起来，这题的隐藏考察点就是“map-reduce思想”，我分片的方向对了，代码细节差一点，估计能拿到一半的分。
建议大家在笔试时即使代码运行超时或编译不过，也要把思路用注释写清楚。笔试判题系统一般来说只会根据测试用例判断对错，但后续人工复核简历时，可能会有人眼查看代码，思路清晰的注释会让你在主观评价上加分。另外，不要在一道题上死磕超过30分钟，第二题如果卡住了，可以先跳到简答题把框架分拿到，再回来补代码。
6. 给准备后续批次和来年笔试的同学的建议
6.1 时间分配：算法、基础、云产品三块缺一不可
如果按照“第二周系统准备”的节奏来规划，我会建议这样分配：40%的时间刷高频算法题（拓扑排序、TopK、滑动窗口、二分、DFS/BFS、并查集），30%的时间复习八股基础（操作系统、网络、数据库、Linux命令），剩余30%专门过阿里云产品知识。产品知识不求你会用控制台点一遍所有功能，但至少要把核心产品的使用场景、权限模型、常见报错和排查思路梳理成自己的笔记。
我在笔试后把云产品相关的知识点整理成一个清单：RAM（用户、角色、策略、STS）、OSS（Bucket、ACL、生命周期、签名URL）、CDN（加速域名、回源配置、HTTPS、缓存刷新）、云效Codeup（仓库管理、MR流程）、SLB/ECS（安全组、负载均衡）、消息队列（RocketMQ/Kafka的适用场景）。这个清单面试阶段同样用得上。
6.2 这几件动手操作的事，建议笔试前完成
第一，用你自己的阿里云账号创建一个RAM子用户，给它只读权限，然后用子用户密钥调用一次OpenAPI，体验一下鉴权流程。第二，开一台按量付费的ECS（记得用完释放），从零配置yum源并部署一个Nginx页面，顺带把免费SSL证书申请和部署走一遍。第三，把Maven的settings.xml换成阿里云镜像，体会一下仓库镜像对构建速度的影响。第四，用OSS上传一个文件并生成签名URL，再用浏览器测试时效性。
这些操作在笔试里不一定以原题出现，但做了之后，你对云产品的基础概念会有一个具象的认知。比如你操作一次SSL证书部署，就知道证书链和Nginx配置的关系了，选择题里再出现“证书部署后不生效”的题，至少能猜到排查方向。
6.3 心态与策略：笔试不是终点，是模拟线上的开始
经历过这一批笔试之后，我最大的感受是：阿里云研发岗的笔试更像一次“真实工作的小规模预演”。它没有堆砌特别冷门的算法，而是把日常开发和云上运维中最常见的问题，拆成了一道道题目。你不需要成为算法竞赛选手，但需要具备扎实的计算机基础、对云原生技术栈的熟悉度，以及遇到问题“先定位再解决”的思维习惯。
如果你准备后续批次的笔试，建议把心态从“刷题交差”调整为“用笔试补齐自己的技术拼图”。每做错一道题，就顺手把背后的知识点展开看一下。比如那道RAM的Deny优先级题，我查完文档后顺带了解了权限评估的完整链路；那道直播协议题，让我把QUIC和CDN加速的关系补了一遍。这些知识面试的时候还会用到，一次笔试的收获其实可以延续很久。
最后再分享一个实用的小技巧：笔试前一定要去赛码网熟悉一下在线编程环境，尤其是输入输出模板。赛码网的调试面板和力扣不一样，先用它练习两道输入输出比较复杂的题，能极大减少正式笔试时的紧张感。祝接下来参加笔试的同学都顺利进入面试环节。
