服务端2月19日 13:58
Yew 事件处理怎么写，什么时候该用 target_unchecked_into？Yew 的事件处理看起来像 JSX：在元素上写 `onclick`、`oninput`、`onsubmit`，传一个 `Callback`。真正的差异在 Rust 类型系统里：每个事件都有明确类型，事件目标也需要显式转换。好处是很多错误能在编译期被挡住，代价是输入框、表单和键盘事件会比 JavaScript 写法啰嗦一些。
## 基本事件怎么写？
最简单的点击事件只需要 `Callback::from`。如果回调里要更新状态，就 clone 一份状态句柄进闭包；如果不更新状态，只做日志或发送消息，闭包可以很短。事件类型可以让编译器推断，但复杂场景建议写出来，后面维护的人更容易判断你处...
乐闻
服务端2月19日 13:59
Yew Hooks 怎么用，use_state 和 use_effect 该如何取舍？Yew 的 Hooks 不是把 React API 换成 Rust 语法那么简单。它解决的是函数组件里状态、生命周期和副作用怎么组织的问题，但同时也把 Rust 的所有权、闭包捕获和依赖比较带进了前端开发。写得顺时，组件会很短；写得随意时，最常见的坑是闭包拿到旧值、依赖写错导致重复请求，或者把本该抽出去的业务状态塞进一个组件里。
## 常用 Hook 该怎么理解？
`use_state` 适合保存简单值，比如输入框文本、开关状态、当前页码。它返回的 `UseStateHandle<T>` 可以 clone 到事件闭包里，读取时用 `*handle` 解引用，更新时用 `set`。如果...服务端2月19日 14:00
Yew 和 WebAssembly 集成时性能瓶颈通常在哪里？Yew 应用最终运行在 WebAssembly 里，但性能不一定天然比 JavaScript 快。Wasm 擅长密集计算、类型明确的逻辑和可复用 Rust 代码；页面更新、DOM 操作、网络请求仍然要经过浏览器 Web API。也就是说，Yew 的性能优化重点不是“把一切改成 Rust”，而是减少无意义渲染、控制 Wasm 与 JS 的边界调用，并把大计算放到合适的位置。
## 集成链路先保持简单
新项目通常用 Trunk 最省心，`Cargo.toml` 配好 `yew`、`wasm-bindgen`、`web-sys`，HTML 里留一个挂载点即可。`wasm-bindgen` ...服务端2月19日 14:00
Yew Router 怎么做参数路由、跳转和权限控制？Yew 做路由管理，核心是 `yew-router` 的 `Routable` 枚举。你把 URL 规则写成 Rust 类型，再用 `BrowserRouter` 和 `Switch` 把不同路由映射到组件。它比手写 `window.location` 安全得多：参数解析、404、导航链接都能在编译期获得一部分保障。真正容易出问题的地方不在“怎么配路由”，而在路由粒度、权限检查、查询参数和浏览器刷新后的状态恢复。
## 先把路由当成公开接口设计
路由不是组件文件名的翻译，它是用户会收藏、分享、刷新进入的地址。列表页、详情页、设置页可以成为路由；弹窗开关、局部 tab 是否进 URL，...服务端2月19日 14:01
Yew 里异步数据该用 spawn_local 还是 use_effect_with？Yew 里处理异步数据，先记住一个边界：组件渲染本身不能 `await`，异步任务必须被放到浏览器事件循环里执行，再把结果写回状态。最常见的选择是 `spawn_local`、`use_effect_with`、`use_async` 或自己封装状态机。它们没有绝对高低，关键看异步任务是由用户动作触发，还是由组件生命周期和参数变化触发。
## 点击触发的请求适合 spawn_local
按钮提交、刷新列表、重试失败请求这类动作，用 `spawn_local` 最直观。它的优点是写法接近普通 Rust async，缺点是任务一旦启动就不会因为组件卸载自动取消，所以回调里要避免闭包持有过...服务端2月19日 14:25
Scrapy 中间件有什么作用？适合哪些场景？Scrapy 中间件可以理解为爬虫流程里的拦截层：请求发出去之前能改，响应回来之后能查，异常发生时也能兜底。它主要分为下载器中间件和爬虫中间件，前者夹在引擎和下载器之间，常用来处理请求头、代理、重试、Cookie、响应状态；后者夹在引擎和 Spider 之间，更适合处理输入给 Spider 的响应和 Spider 产出的请求。中间件的价值是把通用逻辑从 Spider 里抽走，但边界也明显：业务字段解析不要塞进中间件，否则后面排查时会分不清数据到底在哪一步被改掉。判断一个逻辑要不要做成中间件，可以看它是否能被多个 Spider 复用，以及是否只依赖请求、响应、异常这些通用对象。
## 追...服务端2月19日 14:25
Scrapy 如何用选择器解析网页内容？Scrapy 解析网页内容主要靠 Selector，它把响应内容包装成可以用 CSS、XPath 和正则提取的对象。选择器写得好，爬虫会很稳定；选择器写得太依赖页面样式，前端一改 class 名就会全线失效。实际开发里不要纠结“CSS 一定比 XPath 简单”或者“XPath 一定更强”，更重要的是看页面结构、字段稳定性和后续维护成本。写选择器前先在 Scrapy shell 里试几条真实页面，比直接在代码里盲改更省时间，也能提前发现编码、重定向和空页面问题。列表页、详情页、分页、隐藏字段都可能需要不同写法，边界是：如果数据来自异步接口而不是 HTML，优先抓接口，别硬从渲染后的 DO...服务端2月19日 14:25
Scrapy 如何应对反爬虫机制？Scrapy 处理反爬，不是简单地把 User-Agent 换成浏览器就结束了。更稳的做法是先判断网站的限制来自哪里：是请求频率过高、Cookie 会话缺失、IP 被限流，还是前端渲染和验证码把页面内容挡住了。Scrapy 能做的是把请求行为变得更接近正常访问，并把失败、限速、代理、登录态这些环节放进可维护的配置和中间件里。上线前最好先用小样本跑通完整链路，确认列表页、详情页、翻页和异常页都能被识别，否则反爬策略还没生效，解析层就已经把脏页面当成正常数据了。真正的边界也要说清楚：遇到强验证码、设备指纹、复杂 JS 加密时，Scrapy 本身不是万能钥匙，继续硬撞通常只会浪费代理和时间。
...服务端2月19日 14:25
Scrapy 数据流从请求到入库是如何运转的？Scrapy 的数据流可以理解成一条异步流水线：Spider 产生请求，Engine 负责协调，Scheduler 排队和去重，Downloader 取回响应，Spider 再解析响应并产出新的请求或 Item，最后 Item 进入 Pipeline。真正的核心不是某一个组件，而是 Engine 在这些组件之间来回转发数据。
启动爬虫后，Engine 会向 Spider 索要初始请求，并交给 Scheduler。Scheduler 保存请求，Downloader Middleware 可以在下载前改请求头、代理或 cookie，Downloader 拿到响应后再经过 Middlewar...服务端2月19日 14:25
Scrapy Pipeline 管道如何清洗、去重并入库？Scrapy Pipeline 是 Item 离开 spider 后进入存储系统前的处理链。它适合做数据清洗、字段校验、去重、补全、入库、发送消息等工作。和 spider 相比，Pipeline 更靠近数据出口，所以它不应该关心页面怎么解析，而应该关心“这条数据是否可信、如何保存、失败后怎么办”。
Pipeline 可以配置多个，Scrapy 会按优先级从小到大依次执行。每个 `process_item` 要么返回 item 交给下一个管道，要么抛出 `DropItem` 丢弃数据。这里的取舍很实际：把所有逻辑写进一个 Pipeline 简单，但后期很难复用；拆得太细又会增加配置和排查...