需启用rust-analyzer.procmacro.enable和loadoutdirsfromcheck，并执行reload workspace；同时确保trunk serve监听正确路径且项目根目录含cargo.toml。
VSCode 对 Dioxus 的支持不是开箱即用的，核心问题在于 rust-analyzer 默认不展开 rsx! 和 html! 这类过程宏，导致组件内属性无提示、跳转失效、类型推导中断——这不是 Dioxus 独有，而是所有 Rust 宏驱动前端框架（Leptos、Percy）共有的配置盲区。
rust-analyzer 要开启 proc-macro 支持才能解析 Dioxus 宏
Dioxus 组件大量依赖 rsx!、html!、component 属性宏和 derive 宏（如 #[derive(Props)]），这些都属于过程宏（proc-macro）。rust-analyzer 默认为性能关闭 proc-macro 展开，结果就是：rsx! 块里写 class="btn" 没补全、onclick 事件签名看不到、Props 结构体字段点不进去。
- 打开 VSCode 设置（
Ctrl+,），搜索rust-analyzer.procMacro.enable，设为true - 同时启用
rust-analyzer.cargo.loadOutDirsFromCheck（否则宏展开路径无法被索引） - 如果项目含
build.rs或自定义构建逻辑，还需确认rust-analyzer.cargo.runBuildScripts为true - 改完设置后，执行命令面板（
Ctrl+Shift+P）→Rust Analyzer: Reload Workspace，等状态栏显示Ready
Dioxus 热重载不触发？检查 trunk 监听路径和 crate 类型
trunk serve 默认只监听 src/ 和 Cargo.toml，但 Dioxus 项目常把入口放在 src/bin/main.rs 或 examples/ 下。改了组件代码却没重新编译，大概率是 trunk 根本没看到文件变动。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 运行
trunk serve --watch src/ src/bin/ Cargo.toml显式声明监听路径（路径必须真实存在） - 确认
Cargo.toml中二进制 crate 正确声明：例如[[bin]] name = "main" path = "src/bin/main.rs" - 如果用了 workspace，确保
trunk serve是在 workspace 根目录下运行，而非某个子 crate 目录 - 避免在
dist/或target/目录中打开 VSCode —— rust-analyzer 会误判项目结构
组件跳转/补全仍失效？先验证 rust-analyzer 是否真加载了项目
很多问题根本不在 Dioxus 配置，而在 rust-analyzer 压根没识别出这是个 Rust 项目。常见假象是：装了插件、写了代码、也能 cargo run，但编辑器里全是标红和灰色提示。
- 打开任意
.rs文件，看右下角状态栏是否有rust-analyzer字样 + “Loaded X crates” - 没有？说明它没找到
Cargo.toml—— 用终端进入项目根目录，执行code .打开（别双击文件夹） - 有但长期卡在 “Loading…”？检查
cargo metadata --no-deps --format-version 1是否能成功执行（失败常因Cargo.toml语法错误或 workspace 引用路径错） - 曾手动删过
target/？rust-analyzer 依赖其中的rmeta文件重建索引，删了就得Reload Workspace并等几分钟重新分析
真正卡住的地方往往不是 Dioxus 本身，而是 rust-analyzer 对宏展开的容忍度和对项目边界的判断——它不会主动告诉你“我漏看了 build.rs”，只会安静地标红一切。每次改动配置后，务必用 Rust Analyzer: Reload Workspace 触发一次完整重载，再观察状态栏输出，比反复重启 VSCode 有效得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
