服务端2月19日 13:33
Redis 底层为什么这么快？核心数据结构如何支撑？Redis 底层之所以快，主要靠三件事：数据大多在内存里，命令执行路径足够短，核心数据结构针对常见操作做了大量取舍。它不是简单的“单线程所以快”，而是 SDS、dict、skiplist、quicklist、intset、事件循环、I/O 多路复用和内存分配共同配合的结果。面试里回答这个问题，最好从数据结构讲到网络模型，再落到性能边界。
## 字符串和哈希表是基础
Redis 的 String 底层不是直接使用 C 字符串，而是 SDS。SDS 记录了长度和容量，获取长度是 O(1)，扩容时有预分配策略，还能安全存储二进制数据。它的取舍是多占一点元数据空间，换来更安全的修改和更少的内...
乐闻
服务端2月19日 13:49
Redis 常见应用场景有哪些？项目里该怎么选？Redis 最常见的应用场景不是“把数据放进内存”这么简单，而是用它的低延迟、原子命令和多种数据结构，去补数据库、应用进程和消息系统的短板。项目里常见用法包括缓存、分布式锁、排行榜、计数器、限流、会话存储、轻量消息队列、地理位置和集合关系计算。真正要答好这个问题，重点不是背场景清单，而是说清楚每个场景为什么适合 Redis，以及什么时候不该用。
## 缓存是最高频场景
缓存通常用 Cache-Aside 模式：读请求先查 Redis，未命中再查数据库并写回缓存；写请求先更新数据库，再删除缓存。这个模式简单，但边界很多：不存在的数据要防缓存穿透，热点 key 过期要防击穿，大量 key...服务端2月19日 13:50
Redis 常见问题怎么排查？大 Key、热点和一致性如何处理？Redis 常见问题不要按概念清单排查，线上通常先看现象：延迟升高、内存暴涨、从库追不上、数据库被打穿、某个接口 QPS 异常。高频原因包括大 Key、热点 Key、慢命令、缓存一致性、分布式锁误用和限流算法选错。Redis 很快，但单个大对象、阻塞命令、网络抖动和错误过期策略，都会把系统拖慢。
## 追问
### Redis 为什么快，慢请求先看什么？
Redis 快在内存访问、单线程命令执行避免锁竞争、I/O 多路复用处理连接，以及高效数据结构。Redis 6 之后网络 I/O 可以多线程，但命令执行仍是核心单线程路径，一个慢命令会拖住后面的请求。排查先看 `SLOWLOG GE...服务端2月19日 13:56
Yew 框架是什么？适合用 WebAssembly 写前端吗？Yew 是一个用 Rust 编写前端界面的 WebAssembly 框架，写法接近 React：有组件、属性、状态、回调和虚拟 DOM。它的优势不是“所有页面都更快”，而是把 Rust 的类型系统、所有权检查和计算能力带到浏览器里。适合 Yew 的项目通常有两个特征：团队能接受 Rust 工程成本，页面里确实有复杂计算、强类型约束或 Rust 逻辑复用需求。
## 追问
### Yew 和 React 最大的区别是什么？
两者都用组件化和声明式 UI，但 Yew 的组件逻辑用 Rust 写，最终编译成 Wasm，React 主要运行在 JavaScript 引擎里。Yew 的 pro...服务端2月19日 13:56
Yew 组件生命周期有哪些方法？各自适合做什么？Yew 组件生命周期主要对应 `Component` trait 的几个方法：`create` 初始化，`update` 处理消息，`changed` 响应 props 变化，`view` 生成虚拟 DOM，`rendered` 处理真实 DOM 之后的副作用，`destroy` 清理资源。面试里只背方法名不够，关键要说清楚每个阶段适合放什么、不适合放什么。最容易出问题的是把副作用塞进 `view`，或者忘记在卸载时释放监听器和定时器。
## 追问
### `create` 和 `view` 分别适合做什么？
`create` 在组件实例创建时调用，适合根据 props 初始化字段、...服务端2月19日 14:02
Yew 应用性能优化应该从哪些地方入手？Yew 的性能优化不要一上来就盯着 WebAssembly。很多 Yew 应用变慢，不是 Rust 算不动，而是组件重复渲染、状态放得太高、列表没有 key、Wasm 包太大、JS 和 Wasm 之间传了太多数据。先用浏览器 Performance 面板和日志确认瓶颈，再决定优化手段，通常比凭感觉改代码有效得多。
一个实用顺序是：先减少不必要渲染，再优化列表和状态，再看包体积，最后处理 JS/Wasm 边界和网络请求。过早优化会让组件变复杂，尤其是到处加 memo、callback 和手写比较逻辑，后面维护成本会很高。
## Yew 性能问题通常出在哪里？
组件渲染是最常见的入口。...服务端2月19日 14:03
Yew 应用应该如何设计测试策略？Yew 应用的测试要分两层看：纯 Rust 逻辑尽量放在普通单元测试里跑，涉及组件渲染、浏览器 API、事件交互的部分再放到 Wasm 或端到端测试里。这样做的原因很现实：浏览器测试慢、依赖环境多，而业务函数、状态 reducer、数据转换逻辑其实不需要浏览器。
比较稳的策略是“底层多测、上层少测、关键路径必测”。底层用 `cargo test` 覆盖解析、状态流转和工具函数；组件层用 `wasm-bindgen-test` 或 SSR 渲染验证输出；真正依赖点击、输入、路由和网络的流程交给 Playwright 这类 E2E 工具。
## Yew 测试从哪里开始？
先把可测试逻辑...服务端2月19日 14:25
Scrapy 框架的核心组件是如何协同工作的？Scrapy 是 Python 生态里的爬虫框架，解决“怎么稳定抓取一批页面”。如果只是抓一两个静态页面，`requests + BeautifulSoup` 足够；一旦涉及队列、并发、重试和导出，Scrapy 的价值就明显了。
核心链路可以简化成一句话：Spider 产生请求，Scheduler 排队，Downloader 下载页面，Spider 解析响应，Item Pipeline 处理数据，Engine 调度全局。理解链路比背组件名更重要，因为很多问题都发生在边界上。
## Scrapy 的核心组件怎么分工？
Scrapy Engine 是中控层，负责让请求、响应和数据在各组...服务端2月19日 13:57
Yew 状态管理怎么选，use_state、reducer 和全局状态各适合什么场景？Yew 状态管理最容易走两个极端：要么所有东西都塞进组件里的 `use_state`，要么一上来就找全局状态库。前者前期快，后期回调互相影响；后者结构看似专业，却可能让一个简单页面背上过重的抽象。更稳的思路是先看状态的“作用范围”：只影响一个组件、影响一组组件，还是影响整个应用。
## 本地状态：先从最小范围开始
组件内部状态适合输入框、弹窗开关、当前 tab、局部加载状态这类只在当前组件使用的值。函数组件里通常用 `use_state`，类组件里可以放在 struct 字段中。它的优点是直接、可读、改动小；边界是当多个兄弟组件都需要同一份数据时，继续往下传回调会很快变乱。
```...服务端2月19日 13:57
Yew 和 React 有什么区别，什么项目更适合选 Yew？Yew 和 React 都能写组件化前端，但它们解决问题的方式差得很远。React 站在 JavaScript/TypeScript 生态上，追求开发效率、生态完整和团队协作成本可控；Yew 站在 Rust 和 WebAssembly 上，更看重类型安全、内存安全以及复用 Rust 代码的能力。选哪个不是“谁更先进”的问题，而是你的项目到底在为哪种成本买单。
## 核心差异在哪里？
React 的运行环境是 JavaScript，组件写法、构建工具、调试体验都非常成熟。Yew 编译到 WebAssembly，组件宏和 `html!` 语法接近 JSX，但状态、事件和生命周期都受 Ru...