Yew 事件处理怎么写，什么时候该用 target_unchecked_into？

Yew 的事件处理看起来像 JSX：在元素上写 onclick、oninput、onsubmit，传一个 Callback。真正的差异在 Rust 类型系统里：每个事件都有明确类型，事件目标也需要显式转换。好处是很多错误能在编译期被挡住，代价是输入框、表单和键盘事件会比 JavaScript 写法啰嗦一些。

基本事件怎么写？

最简单的点击事件只需要 Callback::from。如果回调里要更新状态，就 clone 一份状态句柄进闭包；如果不更新状态，只做日志或发送消息，闭包可以很短。事件类型可以让编译器推断，但复杂场景建议写出来，后面维护的人更容易判断你处理的是鼠标、键盘还是输入事件。

rust
use yew::prelude::*;

#[function_component(ClickDemo)]
fn click_demo() -> Html {
    let count = use_state(|| 0);
    let onclick = {
        let count = count.clone();
        Callback::from(move |_e: MouseEvent| count.set(*count + 1))
    };

    html! { <button {onclick}>{ format!("点击 {} 次", *count) }</button> }
}

输入事件通常要从事件目标里取 DOM 元素。Yew 常见写法是 target_unchecked_into::<HtmlInputElement>()，意思是告诉编译器“我确认这个事件来自 input”。它方便，但不是魔法；如果回调被挂到了错误元素上，运行时就可能出问题。更稳妥的做法是让回调和元素靠近，别把一个输入回调到处复用。

rust
use web_sys::HtmlInputElement;
use yew::prelude::*;

#[function_component(NameInput)]
fn name_input() -> Html {
    let name = use_state(String::new);
    let oninput = {
        let name = name.clone();
        Callback::from(move |e: InputEvent| {
            let input: HtmlInputElement = e.target_unchecked_into();
            name.set(input.value());
        })
    };

    html! {
        <>
            <input value={(*name).clone()} {oninput} />
            <p>{ format!("当前输入：{}", *name) }</p>
        </>
    }
}

表单事件要特别注意默认行为。浏览器会在 submit 后刷新页面，Yew 单页应用里通常需要 prevent_default()。如果你忘了这一步，看起来像状态丢了，其实是页面被重新加载了。

rust
let onsubmit = Callback::from(move |e: SubmitEvent| {
    e.prevent_default();
    // 校验表单并发送请求
});

支持哪些事件？

Yew 基本覆盖浏览器常用事件：鼠标事件、键盘事件、输入事件、表单事件、焦点事件、拖拽事件、触摸事件等。对应类型大多来自 web_sys，比如 MouseEvent、KeyboardEvent、InputEvent、SubmitEvent。如果需要底层浏览器能力，通常也是通过 web_sys 继续往下拿。边界在于：不是所有 Web API 都有非常顺滑的封装，有些场景要自己处理类型转换和 feature 开关。

事件回调还要考虑冒泡和默认行为。比如按钮放在表单里，点击按钮可能触发表单提交；子元素和父元素都绑定点击时，父元素也会收到事件。需要阻止时可以调用 stop_propagation() 或 prevent_default()，但不要把它们当成万能保险。过度阻止事件会破坏键盘操作、可访问性和浏览器原生交互。

追问

target_unchecked_into 安全吗？

它是方便但带前提的写法，前提是事件目标一定是你声明的 DOM 类型。把它放在 <input> 的 oninput 上通常没问题，但如果回调被复用到 <textarea> 或外层 <div>，假设就变了。取舍是：为了简洁可以用它，但要让回调和元素绑定关系清晰。对公共组件库来说，最好多做一层封装或检查，不要把 unchecked 转换暴露给使用者。

事件回调里为什么经常要 clone 状态？

因为 Rust 闭包需要拥有它捕获的值，而组件渲染函数本身还要继续使用状态句柄。clone 句柄不是复制完整状态，通常成本很低。踩坑点是新手会试图直接 move 原变量，结果后面的 html! 又要读它，编译器就报所有权错误。理解这一点后，clone 反而是更清楚的写法：一份给回调，一份留给视图。

oninput 和 onchange 应该选哪个？

oninput 在用户每次输入时触发，适合实时搜索、字符计数、即时校验。onchange 更接近“值提交变化”，常用于选择框、失焦后再处理的输入。取舍取决于你是否需要实时反馈：实时反馈体验好，但可能带来频繁请求或频繁渲染。做搜索框时通常会搭配 debounce，否则输入一个词就打出多次请求。

如何处理键盘快捷键？

组件内快捷键可以用 onkeydown 绑定到具体输入区域，全局快捷键则要通过 use_effect_with 给 window 或 document 注册监听。边界是全局监听必须清理，否则组件卸载后仍然响应按键。另一个坑是输入框聚焦时快捷键可能误触，比如用户打字按下 / 却触发搜索面板。实际项目里要判断事件目标，必要时避开 input、textarea 和 contenteditable。

事件处理适合写很多业务逻辑吗？

不适合。事件回调最好只做取值、阻止默认行为、派发动作这几件事，复杂业务放进 reducer、service 或异步函数里。否则一个 onclick 里混着校验、请求、状态更新和错误提示，后面很难测试。Yew 的类型系统能帮你挡住类型错误，但挡不住业务逻辑变成一团。

小结

Yew 事件处理的关键不是记住所有事件名，而是把事件类型、目标转换和状态更新边界写清楚。普通交互用 Callback 足够，表单记得阻止默认提交，输入事件谨慎使用 target_unchecked_into。当事件回调开始变长，就说明业务逻辑该从视图层抽走了。