分页解析
第 9 页面试题
筛选题目 公司、岗位、知识点
公司
公司岗位
岗位
标签
Linux查询在一个目录下的特定文件，是怎么查询的？
在 Linux 目录下查询特定文件，首选命令通常是 find，因为它按目录树实时遍历，能同时限定文件名、类型、层级、时间、大小、权限，并能对结果继续执行操作。locate 更适合基于索引的快速模糊查找，grep 更适合在已找到的文件内容中检索文本，三者边界不同，不能混用。
LRU 算法在操作系统中如何使用？
LRU 的核心思想是淘汰最近最少被访问的数据，在操作系统里主要用于页面置换、页缓存回收和内存压力下的缓存管理。但真正的系统通常不会实现严格 LRU，而是借助访问位、脏页状态、Clock、二次机会、活跃/非活跃链表等机制近似判断冷热，以降低维护成本并兼顾吞吐、延迟和写回开销。
在Linux里删除当前目录下七天前创建的所有文件会用到哪些命令？
核心命令通常是 find，用它限定当前目录、文件类型和时间条件，再用 -delete 或 -exec rm 执行删除。面试时要特别说明：Linux 中常用的 find -mtime 判断的是“修改时间”，不是严格意义上的“创建时间”；如果题目口语里说“七天前创建”，生产环境通常需要先确认到底是按创建时间、修改时间，还是业务生成时间清理。
知道如何查看线程的cpu内存等资源使用情况吗？
查看线程级 CPU、内存等资源使用情况，核心思路是先确认进程 PID，再进入线程维度观察。Linux 中线程本质上是轻量级进程，每个线程都有自己的 TID，因此可以用 top -H、ps -L、pidstat -t、/proc/<pid>/task/<tid>/ 等方式查看线程级 CPU、调度状态、上下文切换和栈。CPU 通常能定位到线程，但内存大多是进程级共享资源，不能简单拆给单个线程。
分表规则中，跨表查询+分页该怎么做？
跨表查询和分页的核心不是把单表 limit offset 原样套到每个分表，而是先判断能否命中分片键；能命中就路由到单表或少量表，不能命中才考虑广播查询、局部排序、全局归并。深分页会被分片数放大，工程上更推荐游标分页、二级索引表、异步宽表或搜索服务承接全局查询。
fork发生复制的时候子进程会复制什么？
fork 的本质不是把父进程的一切都物理复制一份，而是创建一个几乎相同的子进程执行上下文：内核为子进程建立新的进程描述符、PID、虚拟地址空间视图和资源引用关系；用户态内存通常通过写时复制延迟分裂；文件描述符表被复制但底层打开文件对象常被共享。因此面试回答要区分“逻辑复制”“引用共享”和“写时复制后才真正复制”。
线程最大数量和什么有关？
Linux 下线程最大数量不是一个固定常量，而是由多层约束共同决定：系统级的 threads-max 和 pid_max、用户级的 RLIMIT_NPROC、服务或容器的 pids 限制、单进程可用地址空间、物理内存与 overcommit 策略、每个线程的用户栈和内核对象开销，以及语言运行时的栈配置共同取最小值。能创建多少线程是一回事，系统能否高效调度这些线程又是另一回事。
消息队列如何保证消息不丢失？
消息队列不丢失不能只回答“开持久化、开确认、消费后再 ack”。更好的回答是把消息链路拆成 producer、broker、consumer 三段，逐段说明消息丢失产生的位置、对应可靠性机制、机制代价，以及至少一次、至多一次、恰好一次之间的取舍。
Mq-Bus 数据量太大延迟怎么办？
消息总线数据量过大导致延迟时，不能只回答加消费者，而要按生产端、broker、消费者三段定位瓶颈，再做止血和长期治理。核心思路是看 TPS、lag、分区倾斜、消费耗时、失败重试、资源水位；再用扩分区、提升消费并行度、批量处理、限流削峰、幂等、死信和容量规划形成闭环。
Kafka 为什么吞吐量高？
Kafka 的高吞吐不是单点优化，而是围绕日志追加模型构建的一整套链路设计：生产端批量发送和压缩降低请求次数与网络字节数，Broker 端用顺序写和 Page Cache 减少随机磁盘 IO，发送文件时利用零拷贝降低用户态与内核态拷贝成本，Topic 分区让读写并行扩展，消费者拉取模型让消费端按自身能力批量读取。同时，ISR、acks、副本数、刷盘策略等可靠性配置会影响吞吐，面试中要讲清这些设计如何共同减少 IO、网络、CPU 和锁竞争开销。
Token的安全怎么保护？
Token 安全的核心不是只把 Token 加密，而是从传输、存储、签发、使用、续期、撤销、审计全链路降低泄露、伪造、重放和越权风险。回答应先说明 HTTPS 是底线，再比较 Cookie 与本地存储风险，重点展开 HttpOnly、Secure、SameSite、短有效期、Refresh Token 轮换、权限范围、服务端撤销、重放防护和日志脱敏。
计算机网络知识体系面试中应该如何展开？
这类问题不是在考背诵协议名，而是在考候选人能否把计算机网络讲成一个有层次、有主线、能落到排障和工程实践的知识体系。高质量回答应先给出分层框架，再围绕 HTTP/HTTPS、TCP/UDP、DNS、连接生命周期、拥塞控制、流量控制和常见问题定位展开，避免想到哪里说到哪里。
session的原理？
Session 的核心是用服务端状态弥补 HTTP 无状态。服务端生成随机 session id 并保存会话数据，客户端通常用 Cookie 携带这个 id，后续请求由服务端查会话存储恢复用户身份、权限和临时状态。
卷积神经网络原理？
卷积神经网络的核心思想，是利用局部感受野和权重共享，从图像或网格数据中逐层提取特征。卷积核在空间上滑动，对局部区域做加权求和，生成特征图；不同卷积核学习不同模式，浅层常捕捉边缘、纹理和颜色变化，深层逐渐组合成部件、形状和语义概念。CNN 并不是简单记住像素，而是学习从局部到整体的层次化表示。
Http 报文里有什么？
HTTP 报文是客户端和服务端交换应用层数据的基本格式。HTTP/1.x 报文由起始行、请求头或响应头、空行、消息体组成。请求报文的起始行叫请求行，包含方法、请求目标和协议版本；响应报文的起始行叫状态行，包含协议版本、状态码和原因短语。头部字段描述元信息，空行分隔头部和消息体，消息体承载实际业务数据。
http 协议 转 dubbo 协议怎么做的？
HTTP 转 Dubbo 的本质不是协议字节直接翻译，而是在网关或适配层把一个 HTTP 请求解析成一次 Dubbo RPC 调用。核心流程是：接收 HTTP 请求，按路由规则定位 Dubbo 接口、方法和版本，完成参数绑定和类型转换，通过注册中心或本地配置找到服务提供者，使用 Dubbo 客户端按 Dubbo 协议编码、序列化并发起调用，再把 Dubbo 响应、异常和超时结果转换成 HTTP 状态码与响应体。回答要围绕映射、发现、调用、治理和观测展开，而不是只说用网关转发。
TCP断开时有4次交互，而连接时有3次交互，多出来的一次是在做什么事情呢？
TCP 连接建立只需要双方确认彼此的发送能力和接收能力，因此三次握手即可完成双向能力确认；TCP 连接断开面对的是全双工连接的两个方向分别关闭，FIN 只表示一端不再发送数据，对端必须先 ACK 确认，等自己也没有数据要发送后再发 FIN。
有了解过debug的时候设置断点后程序会停下来的底层原理吗？
断点能让程序停下来，本质是调试器借助操作系统或运行时的调试接口接管目标进程，在指定位置制造 CPU、内核或虚拟机能识别的停顿事件。native 程序常见是软件断点、硬件断点和单步陷阱；JVM 等托管运行时还要通过 JDWP/JVMTI、字节码位置和线程栈帧模型来完成源码级调试。
一个单向链表，奇数节点是升序、偶数节点是降序，怎么样将链表转变成降序的链表？
这道题的关键不是排序整个链表，而是利用题目已经给出的局部有序性：按位置拆出奇数位链表和偶数位链表。奇数位本身升序，反转后变成降序；偶数位本身已经降序；最后对两条降序链表做一次归并即可。
进程与线程区别？
进程是操作系统进行资源分配、隔离和保护的基本单位，线程是进程内部的执行流，通常是 CPU 调度的基本单位。进程之间默认拥有独立虚拟地址空间和资源边界，隔离更强；同一进程内多个线程共享地址空间、堆、代码段、打开文件等资源，但各自拥有独立寄存器上下文、栈、线程局部存储和调度状态。
https，客户端拿到服务端的证书后是怎么验证证书的合法性？
HTTPS 证书合法性验证的本质，是确认服务端公钥可信地属于当前访问的域名。客户端会构建证书链、逐级验证签名、确认根 CA 受信任，再检查域名、有效期、用途、吊销状态和握手签名绑定。
TCP如何识别断开？
TCP 识别断开依赖报文、应用读写行为和超时机制共同完成。正常关闭通常通过 FIN 体现，应用读到 0；异常关闭常见为 RST，读写报错；静默断链不会立刻被发现，需要 keepalive、应用层心跳和业务超时兜底。
考核某个运营活动的数据指标是哪些？
考核运营活动不能只盯成交额或参与人数，而要先明确活动目标，再按目标指标、过程漏斗、商业结果、用户沉淀、成本效率、增量效果、风险护栏、数据可信度的框架拆解。优秀回答应体现指标分层、前中后评估、对照组思维和归因意识，说明哪些指标用于判断活动是否达成目标，哪些指标用于定位问题，哪些指标用于判断是否值得复用。
供应链运营重点关注哪些指标？
供应链运营指标不能只报一串名词，核心是围绕客户拿得到、拿得快、库存不浪费、履约成本可控、资金周转健康建立指标体系。回答时应先分层说明服务、时效、库存、预测、采购、物流、财务和异常管理，再说明不同业务阶段如何选择最重要的北极星指标，并把具体动作与指标变化挂钩。
如何把相对宏观的指标拆解成一个过程指标，拟合成最终结果作为团队目标，同时搭建类似于数据化的产品，去支撑业务的场景？
这类题考察的不是单纯会不会搭指标体系，而是能否把一个宏观、滞后的业务结果，拆成可理解、可控制、可监控、可复盘的过程系统。高质量回答应围绕先定义北极星指标和结果口径，再用驱动树找到关键杠杆，选择可控过程指标，通过历史数据建模拟合结果，拆解目标到团队动作，并把指标、诊断、预警、实验和复盘产品化展开，体现数据分析既服务目标制定，也服务业务经营。
有什么运营指标？
回答“有什么运营指标”时，核心不是罗列 DAU、转化率、留存率，而是说明指标如何服务经营目标：先明确北极星目标，再按“获取、激活、留存、活跃、转化、收入、成本效率、质量风险”拆解，最后用分群、分渠道、分周期和队列视角判断问题发生在哪里。
如何说明自己对一个业务指标负责？
这道题考察的不是“你有没有做过很多事”，而是你能否把一段运营、采购或数据分析经历讲成清晰的指标经营闭环。高质量回答要说明指标是什么、为什么归你负责、你能影响哪些杠杆、做了哪些动作、如何衡量效果，以及结果中哪些可以合理归因于你。
电商业务分析应该关注哪些核心指标？
电商业务分析的核心不是罗列 GMV、订单量、转化率，而是建立一套从流量获取、用户行为、交易转化、商品供给、履约体验到长期利润的指标体系。分析时要先明确业务目标，再把指标拆成可定位问题的树状结构：规模看 GMV 和订单，效率看转化率和客单价，健康度看复购、留存和退款，经营质量看毛利、补贴效率和库存周转。真正有价值的分析，应能回答增长来自哪里、损失发生在哪一环、应该优先优化什么。
做过最酷的事情是什么，然后延伸扩展一些问题？
这是一道行为面试题，核心不是让候选人讲一个听起来很酷的故事，而是考察你是否能识别高价值问题、主动推进、用数据或用户反馈验证结果，并完成复盘。产品/数据分析方向最适合选择一个真实的业务改进、分析洞察、流程优化、用户增长、实验验证或跨团队推动案例，而不是泛泛讲兴趣爱好或个人挑战。
数据分析时如何看待短期数据和长期数据？
短期数据反映近期变化和即时反馈，长期数据反映趋势、周期和结构性规律。优秀的数据分析不会简单地说短期数据不可靠、长期数据更重要，而是根据问题类型、业务周期、样本量、指标口径和决策场景，把两类数据结合起来判断：用短期数据发现异常和验证动作，用长期数据校准方向和识别真实趋势。
如何定位慢sql，怎么优化？
定位慢 SQL 的核心不是只看执行时间，而是建立从发现、归因、验证到优化的闭环：先通过监控、慢查询日志、数据库性能视图确认慢 SQL；再结合执行计划、索引、扫描行数、锁等待、事务、数据量和业务访问模式判断瓶颈；最后用索引、SQL 改写、分页优化、表结构调整、缓存或架构拆分降低扫描量、排序量、回表量和锁竞争。
ORACLE中的SQL如何进行优化，都有哪些方式？
Oracle SQL 优化不是单纯加索引，而是先定位慢在哪里，再用执行计划、统计信息、访问路径、连接方式、SQL 改写和运行期指标形成闭环。面试中应强调以真实执行计划为依据，以业务过滤条件和数据分布为基础，以响应时间、逻辑读、物理读、CPU、等待事件等指标证明优化效果。
SQL 分析题应该如何拆解指标口径和查询逻辑？
回答这类问题不能只说加索引或看执行计划。高质量拆解应先把查询要回答的业务问题讲清楚：指标是什么、统计哪段数据、以什么粒度统计、哪些记录应被纳入或排除；再把 SQL 的逻辑链路拆成数据源、JOIN 关系、过滤条件、聚合口径、排序分页；最后进入性能定位，从慢查询日志、执行计划、索引命中、扫描行数、临时表、排序、锁等待和数据倾斜等角度判断慢在哪里。核心思路是先证明结果口径正确，再证明执行路径高效。
nosql和关系型数据库的区别？
NoSQL 和关系型数据库的核心区别不是新旧，也不是是否支持事务，而是数据模型、结构约束、查询能力、扩展路径和一致性取舍不同。关系型数据库以关系模型、固定 schema、SQL、事务和复杂查询见长，适合结构稳定、关联清晰、强一致要求高的业务；NoSQL 包括 key-value、document、column-family、graph 等类型，更强调灵活 schema、水平扩展、高吞吐和面向访问模式的数据建模。大型系统中二者经常组合使用，而不是互相替代。
怎么选取合适的线程数？
选取合适线程数的核心不是背一个固定数字，而是先判断任务是 CPU 密集、IO 密集还是混合型，再结合机器核数、阻塞比例、线程池队列、延迟目标、吞吐目标和资源上限做估算，最后通过压测观察 CPU 利用率、上下文切换、队列堆积和响应时间来迭代调优。
设计朋友圈功能时，数据库表如何从简单到复杂演进？
朋友圈数据库设计可以按复杂度分层回答：最小可用版本先有用户、好友关系、动态、媒体、评论和点赞；进阶版本补可见范围、权限校验和删除模型；高并发版本再讨论时间线、读扩散与写扩散、冷热数据、索引、分库分表、幂等与一致性。面试时不要一上来就堆表，而是先说明业务读写路径：发动态、刷列表、看详情、评论点赞、删除和权限变化。
React/Vue 列表渲染中 key 的作用是什么？
key 的核心作用是在虚拟 DOM diff 或 reconciliation 过程中，为同一父节点下的一组子节点提供稳定身份标识。它帮助框架判断哪些节点是同一个、哪些需要移动、插入、删除或重新创建，从而减少错误复用和不必要的 DOM 操作，同时影响组件实例与内部 state 的保留或重置。
后端慢 SQL 会如何影响前端体验？
后端慢 SQL 不只是后端问题，它会沿着请求链路放大为前端可感知的卡顿、白屏、加载时间过长、按钮无响应、接口超时、重复提交和数据不一致。核心机制是数据库读写占用锁、CPU、IO 和连接，进一步拖慢应用线程、连接池、网关队列与浏览器请求队列，最终影响页面渲染、交互反馈和业务流程完成率。
前端构建工具如何优化构建速度和产物体积？
前端构建优化要同时回答构建速度和产物体积两个目标。速度侧关注开发冷启动、热更新、全量打包、CI 构建是否少做重复工作；体积侧关注未使用代码、重复依赖、静态资源、拆包和浏览器缓存。高质量回答不只是背 Vite 或 Webpack 配置名，而是能解释每个手段解决了构建链路里的哪一段瓶颈。
跨域请求需要携带 Cookie 时，前端该怎么设置？
前端请求不一定必须携带 Cookie。是否携带取决于业务是否依赖 Cookie 做登录态、会话、灰度、风控等状态识别，以及浏览器、前端请求配置、Cookie 属性和服务端 CORS 配置是否同时满足条件。跨域场景下，前端单独设置不够，必须前后端配合：前端开启 credentials，服务端允许带凭证，并返回精确的 Access-Control-Allow-Origin 和 Access-Control-Allow-Credentials。
写完代码后，如何回答还有哪些可以改进？
这类追问考察的不是候选人是否能临场再写一个完美版本，而是能否在完成代码后进行工程化复盘：先确认核心逻辑正确，再有层次地说明边界、复杂度、可读性、可维护性、前端运行环境和测试保障上的可改进空间，同时避免把已有答案说成完全不可用。
如果absolute外面再包一个absolute，是什么效果？
absolute 外面再包一个 absolute，本质上是两层脱离普通文档流的定位关系：外层 absolute 先相对自己的包含块定位，内层 absolute 再相对最近的已定位祖先定位。由于外层本身就是 position:absolute，它通常会成为内层 absolute 的包含块，所以内层的 top、left、right、bottom、百分比尺寸等都会以外层盒子的 padding box 为参照，而不是直接以页面或更外层容器为参照。
怎么学习前端的？
这道题考察的不是学过哪些技术名词，而是候选人是否有稳定、系统、可验证的学习方法。回答要体现：先打基础，再用项目验证，再从文档和源码补齐原理，最后通过复盘、输出和指标证明学习有效。
前端监控系统应该如何实现？
前端监控的核心不是简单收集日志，而是建设一套从 SDK 采集、数据清洗、可靠上报、服务端聚合、指标分析、告警响应到问题复盘的闭环体系。它通常覆盖错误监控、性能监控、用户行为埋点、接口质量、业务转化、环境信息和隐私合规。面试回答时要强调：监控目标先于技术实现，数据质量先于数据规模，告警闭环先于报表展示。
Rem 和 em的区别？
rem 和 em 都是 CSS 中的相对长度单位，核心区别在于参照对象不同：em 通常相对于当前元素或其父级继承后的 font-size，rem 始终相对于根元素 html 的 font-size。面试回答时要讲清楚参照基准、继承影响、适用场景和移动端适配实践。
面向对象和面向过程？
面向过程强调“按步骤解决问题”，核心是过程、函数和控制流；面向对象强调“围绕对象建模问题”，核心是对象、状态、行为和协作。两者不是绝对优劣关系，而是适合不同复杂度、变化方向和性能要求的设计范式。前端开发中，组件化、状态封装、事件响应、接口抽象都体现了面向对象思想，但具体实现常常会混合函数式、声明式和面向过程写法。
Array.sort的实现原理？
Array.prototype.sort 的核心不是某一个固定算法，而是 ECMAScript 规定排序语义，各 JavaScript 引擎自行选择实现。面试回答要区分三层：默认比较规则是转字符串后按 UTF-16 码元排序；传入 compareFn 后按返回值正负决定顺序；ES2019 之后规范要求稳定排序，但时间、空间复杂度仍由实现决定。以 V8 为代表的现代实现采用稳定排序方案，并需要处理 undefined、空槽、访问器、原型链、副作用等 JavaScript 动态特性。
有考虑过什么情况下服务器压力会过大？
服务器压力过大本质上不是“访问量大”这一件事，而是系统在当前容量下无法稳定满足目标延迟、吞吐和错误率要求。常见原因包括流量突增、请求复杂度升高、CPU 或内存耗尽、磁盘和网络 IO 瓶颈、数据库慢查询与锁等待、缓存失效、线程池或连接池耗尽、下游依赖变慢、重试放大以及缺少限流降级和弹性扩容能力。面试回答时应从“压力来源、瓶颈位置、观测指标、保护手段、扩容治理”几个层次展开。