必须设为true：rust-analyzer.procMacro.enable开启宏展开支持，否则Leptos的view!、Serde的derive等过程宏无法解析，导致类型提示、跳转失效；同时需启用rust-analyzer.cargo.loadOutDirsFromCheck并确保前端crate声明[lib]且proc-macro=false。
rust-analyzer.procMacro.enable 必须设为 true
Leptos 的 view!、Serde 的 #[derive(Deserialize)]、SQLx 的 query_as! 这类宏，依赖过程宏（proc-macro）展开才能生成可分析的 AST。rust-analyzer 默认禁用 proc-macro 支持，否则会显著拖慢启动和响应速度。
不手动开启，所有宏体内变量、属性、表达式都不会被索引——表现为：hover 看不到类型、Ctrl+Click 跳转失败、let name = props.name; 中的 props.name 标红但编译通过。
- 打开 VSCode 设置（
Ctrl+,），搜索rust-analyzer procMacro - 确保
rust-analyzer.procMacro.enable选项已勾选（值为true） - 该设置必须作用于工作区（即写进项目根目录的
.vscode/settings.json），而非用户全局设置，避免干扰其他 Rust 项目
rust-analyzer.cargo.loadOutDirsFromCheck 必须启用
仅开 procMacro.enable 不够。rust-analyzer 需要知道宏展开后的实际输出路径（比如 target/debug/deps/xxx-proc-macro.so），而这些路径由 cargo check 运行时动态生成。默认情况下，rust-analyzer 只读取 Cargo.toml 和源码，不解析构建产物。
典型症状：宏能展开，但展开后的新类型（如 MyComponentProps）无法跳转、补全缺失、hover 显示 unknown type。
- 在项目根目录的
.vscode/settings.json中添加：{ "rust-analyzer.cargo.loadOutDirsFromCheck": true } - 保存后，按
Ctrl+Shift+P→ 输入Rust Analyzer: Reload Workspace强制重建索引 - 首次 reload 后需等待右下角状态栏显示
rust-analyzer (ready)，且有Loaded X crates提示，才算生效
删 target/ 后必须 reload workspace，不能只重启 VSCode
很多人遇到“昨天还好，今天 macro 全标红”，其实是手动执行了 rm -rf target/ 或 cargo clean。rust-analyzer 的语义索引严重依赖 target/ 下的 rustc 产物（尤其是 deps/ 和 incremental/）。清空后，旧缓存仍被插件持有，但对应文件已不存在，导致符号解析断裂。
错误做法：关掉 VSCode 再重开 —— rust-analyzer 会复用损坏的内存索引，问题照旧。
- 删完
target/后，**不要关闭窗口**，直接Ctrl+Shift+P→Rust Analyzer: Reload Workspace - 观察状态栏：从
(loading)到(ready)，期间会自动触发一次cargo check - 若卡在 loading 超过 45 秒，检查终端是否能跑通
cargo check --workspace --all-targets；失败则先解决编译问题
Leptos 前端 crate 必须声明 [lib]，否则 rust-analyzer 不扫描
Leptos 全栈项目常把前端逻辑放在独立 crate（如 frontend/Cargo.toml），但若该 crate 只有 [[bin]] 没有 [lib]，rust-analyzer 默认跳过它——因为只有 [lib] 才会被当作可导出模块参与跨 crate 分析。
结果是：frontend/src/lib.rs 里的 view! 完全不被识别，连语法高亮都失效，但 cargo build --release 仍能成功。
- 检查前端 crate 的
Cargo.toml，确保包含：[lib]<br>proc-macro = false
-
proc-macro = false是关键：Leptos 组件不是过程宏，设为true反而会让 rust-analyzer 尝试加载错误的 ABI - 如果项目是 workspace，确认根
Cargo.toml的[workspace].members明确列出了该 crate 路径（如["frontend"]）
view! 里永远是一片灰。 
